21 Sep 2004, Lynda, Jacco, Lloyd
This note is to try to explain why doing a PhD requires constant supervision. There is so much to learn and students are so different that you can't "teach" these things in a structured way. You have to build on the strengths of the individual and then concentrate on strengthening "the gaps". Doing a PhD is much like going through an apprenticeship. It is not like attending a "How to do a PhD" course.
Based purely on observation, you only get good PhD students out of good (those that publish in high quality international conferences and are recognised by peers in their field = serving on committees of top conferences) groups. So there is something "magic" that you need to absorb while in a good group that cannot be learned by talking to people who work in good groups, or working in a less good group. Similarly, just being in a good group doesn't mean you will do a good PhD. There are also characteristics of the student that are fundamental to the process.
Having said all this, four years is barely enough time for even good students to carry out their research and complete their PhD. This document is meant to help explain why this is so.
Research is not about creating a small, fiercely-guarded world containing your precious ideas which you water and nurture and when they grow up you harvest and put in your thesis. It is a much more outward-looking and dynamic process. You have to have a long term direction (to limit the literature you need to keep up with), but ideas should be generated fast and furiously and many rejected (quickly) and others built on and nurtured. If no-one else comes up with any of your ideas then you are working in a solitary field, which means it will be difficult to find places to publish. If your ideas keep appearing in other places (first) then you need to read more and faster to build on them and generate new ideas.
What follows is a list of skills that students need to develop. Feel free to add to these lists.
- Read a paper and be able to summarise it. (Easy - masters students can do this)
- Read a paper and be able to pick out ideas relevant to own topic. (Easy)
- Read a paper and understand what is missing from the paper. (Difficult to learn or be taught. Need to acquire skill around year 2.)
- Read a whole bunch of papers and realise what is missing from the field. (Very difficult. Should be able to do this by last year of PhD.)
- Remember - any new idea you think you have, someone else has already had before. So find the paper, refer to it and build on it. This should accelerate your work and avoid reviewer frustration.
Work out concrete examples of:
- scenarios or use cases that combine all of the above into a specific context (describe user, her task, situation, goal etc., describe potential interactions)
- output your future system might produce
- input your future system needs to produce this output
- algorithms, rules etc. the system may use to turn input into output
- use the above to illustrate and explain the ideas in your papers
- combine ideas above into a "working" proof of concept (note the quotes around "working": that is working with a quick and dirty, throw-away coding style, all tricks are allowed, system may crash on all inputs except one). The proof of concept is mainly a sanity check for your own ideas, a potential source of further inspiration and a concrete deliverable you can discuss with your colleagues/supervisors.
- rework proof of concept into a prototype. The prototype should be able to handle sufficient different inputs that you can use it to convey to a wider audience about what your system can do. It should be sufficiently stable (that is: unlikely to crash during your talk/demonstration). There should be a web version we can put up on our public web site and you can add to your own web page.
- use the lessons learned from the above to illustrate the ideas in your papers (note: strictly speaking, you really should do some formal kind of evaluation (performance tests, or, in our case, user testing). Since this is often really hard or not practical, a "lessons learned" is often the best we can do.
- Be aware of what *not* to program. What technical details are best not to waste time on? Programing takes a lot of time. How can you focus your precious programming time on results that are meaningful, or to maximize their research meaningfulness for time spent? You can too easily spiral down into trivial details in demos simply because the programmer's puzzle-solving monkey gets into your head. Focus on the research topic to validate -- that's exciting enough.
Experimenting and Experiencing
- Often (but not always) we should use our own systems to gain intuitive insights into their use.
- Anecdotes are a good publishable initial result from this phase.
- Even this level of empirical analysis helps validate that the resulting system does something that is actually useful and with which typical users can identify.
- A related principle is how to best use other systems. Not just to save time, but to use other ideas and concepts as well as code as part of validating your ideas and putting them in the context of others. Of course, such reuse must be very carefully selected.
- Bear in mind TBL's viral principle: that programs should be small and easily spread and integrated, conceptually as well as technically. (Viral: My friend sees it, wants one. My competitor sees it, needs one.)
Once every two years, CWI offers a course on Academic Writing.
- Write a trip report of a workshop/conference. (Basic summary is easy. Writing about the consequences is harder.)
- Review a conference paper. (Moderately hard. Should be able to after 18 months.)
- Write up what you have done (fairly easy).
- Write up what you have done and put it in the context of previous work (more difficult).
- Write conclusions/own contribution (very difficult).
- Write short notes on what are going to do (more difficult than Lynda realises).
- Write good blue note = uncertain ideas and trying to sketch what the scope of the problem is and the potential direction for a solution. (Much harder than Lynda realises.)
- Decide on new research directions. (This is probably a post doc skill, certainly given the 4 year PhD timescale, but final year PhD students need to be able to do this to at least write the future research directions in the thesis conclusions.)
Once every two years, CWI offers a course on English Presentation.
- You need to be able to create slides explaining your work for presentation at a workshop or conference. These should be "advertisements" for your work, be a concise story and not try to replicate all the details of the paper.
- Talk to interesting people from your field during conferences/workshops (think about how they might be able to help you with your current research and your future career).
- invite interesting people to visit CWI
- invite yourself to visits at interesting institutes/groups
The best way to learn is to teach others.
- (Co-)supervise master's students.
- Add to this note. Include links to these and other topics from the research tips page.