How to complete your PhD

Shane Lindsay writes about how to complete your PhD (or any large project) which is to use hard deadlines (externally determined), soft deadlines (your own) and the Martini method (write at least X words per day, e.g. between 500 and 1000)

My take on how to complete a PhD (in Computer Science):

1. Learn and use a version control system for everything you do (code, datasets, text etc.)
   
• Useful for backup
• Useful for versioning
2. Learn statistics and experimental method (e.g. factorial design)
   
• Universally useful, and makes you critical to what you read
  
• T-tests seems to popular in CS-papers :)
• Prefer confidence intervals over "significantly different" and p-values
  
• Be aware that the difference between significant and not significant is not statistically significant :)
  
• It isn't embarrassing to read the cartoon guide to statistics!
3. Learn scientific writing, take a course!
• Always, and I do mean always support your claims when writing (e.g. with references proofs, empirical support or good rhetoric writing). Consider dangling claims in papers as paper-eating bugs, if you don't feed them with support they will eat your paper. And argumenting why the research you are presenting is important doesn't hurt.
  
4. Submit papers early and often (to conferences, workshops and journals)
   
• The likelihood that external reviewers provide complementary input on your work compared to your advisor and grad student colleagues is probably significantly close to 100%
• Demand to be a "slave" co-author for your advisor on the first paper, e.g. do all ground work (experiments etc.), but you learn the skill of writing and review process.
• As my father advised me half-seriously: "even write on the toilet"
• Figure out the most important research events in your field
  
• Do at least 1 unlikely-to-get-accepted submission in order to get a reject early just to get heat. It is way better to get a reject (with explanation why it was rejected) from a great conference or journal the first year, than getting it for the first time from a medium quality conference a few months before you are going to defend your thesis.
  
5. Submit code early and often.
• Writing code keeps you sharpened. Spending several years developing some kind of framework, model or algorithm sketch (without any implementation) and then try to implement it in order to evaluate is likely to cause trouble. By then your coding skills are about as sharp as a spoon, and the model or whatever you are trying to evaluate with implementation is probably way too abstract and requires a lot of massage in order to be implementable. And if that isn't enough, you probably are about to run out of funding.
• You are way more marketable when you are finished than if you don't write code
  
• Learn at least 1 new language that is not too close to those you know during your PhD
• The fundamentals of Computer Science is still software (and hardware).
  
6. Least Publishable Unit papers are not bad because:
• It is like code, concise and and shorter methods that do one thing well are preferred over longer methods that try to a lot of stuff, don't get me started on testing.
  
7. Try to get involved in the research community as a reviewer (probably not the first year)
• You'll be surprised how unpolished submitted papers actually are, and how different the first submit and the final polished,.. eh published paper actually is.
8. Learn at least 1 drawing, 1 presentation, 1 word processor and 1 statistics tool
   
• Leslie Lamport knew what he was doing..
• Google Docs&spreadsheets for notes and calculations
9. Teach!
• Being thrown in front of hundreds of students with the expectancy that you are going to teach them something useful and interesting is an extremely valuable lesson (and quite scary too I must admit). And this can save your career if you forgot to code (read 5.) ;-)
  
10. Oh wait, create interesting MSc topics and get MSc students
• The payoff can be great (e.g. get you more productive by helping you concretize your ideas into code and get them to do experiements).
• There is usual an at least linear (probably exponential) relationship on the PhD relevant output you get and the input/support you provide the MSc students.
11. My experience is that "doers" are more likely to finish their PhD than "smarties".
    
• Thinking doesn't create your thesis, but writing might!
• Hopefully you are both a "doer" and a "smartie" :)

Hm, can't think of anything else, and no guarantees about that you will manage to complete your PhD if you follow these advice :)

Note: I don't think these approaches will help you complete any large project (as Shane Lindsay's recipe claims to), but it probably won't hurt either.