What skills do you need to develop to get a PhD?

Reading

• 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.

Doing

• 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
• Prototyping
  • 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.)

Writing

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.)

Presenting

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.

Networking

• 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

Supervision

The best way to learn is to teach others.

• (Co-)supervise master's students.

Self-help

• Add to this note. Include links to these and other topics from the research tips page.