Awesome blogger engtech, has a very good summary on programmer productivity tips. The beauty of this blog post is that, it is a great summary of a lot of things, that everyone knows, but cannot find in a single place. Since GTD is all about lissts, getting-to-deadline (another gtd) is also a long list.
Some tips I really liked:
Understand the problem. It is very easy to avoid work you do not understand well enough to solve.
Go for a walk. Can’t focus? Get away from your desk and stimulate the blood flow to your brain. A change of scenery can unplug a mental block.
Hydration. Have a bottle/cup of water on your desk that you can sip from throughout the day. The short term gains made from drinking coffee isn’t worth the long term loses on memory, dehydration, and the productivity lose from caffeine crashes. Non-caffeinated herbal teas such as peppermint can be useful for weaning yourself from coffee.
Accurate Estimations. Develop your estimation skills so that when you say ‘task X will take Y to do’ they believe you.
Under commit and over deliver. Realistic schedules give room to do a better job instead of fighting to keep your head above water.
Only code what is needed. If a feature ‘might be useful’ then code it later when it is necessary.
Simplest solution is the best solution. K.I.S.S. Every line coded is a line that potentially has to be debugged. Focus your debugging effort on solving the problem, not on debugging bells and whistles that don’t contribute to the deadline. More time is lost in debugging an unnecessarily complex feature then in designing it.
Tracking. Keep a piece of paper (or use your engineering lab book) beside your desk to write down reminders of where you left off in the parallel problems.
Don’t fire and forget. When you switch to working on the next task in the pipeline, periodically check the status on the first task to make sure that it is running properly.
Always run something. The goal is to always have something running in the background while you develop during the cycles where you would instead be waiting for results. It could be as simple as seeing if what you are working on compiles properly while you’re working on something else.
These are some of the tips that I liked.
(source: http://engtech.wordpress.com/2006/07/14/getting-to-deadline-programmer-productivity-tips-at-work-getting-to-done/)