I've been going through a period recently of attempted self improvement. Trying new things to make myself a better more effective code monkey — iterative code reviews, todo lists, time management, pair programming, TDD, BDD, la dee dee....
My old strategy was simple — get given or discover a piece of work, usually pretty large, and start coding. Once done do a bit of exploratory testing, read the spec to check I've covered everything, commit the code and submit a bit of a code review. These sessions tend to last a number of days which leads to an eventual short term burnout. Now because I always write 100% flawless code first attempt that's generally fine but it doesn't really allow other people to learn from my excellence. Also being the smartest person on any project I am generally being pulled left and right answering queries and explaining my very clever designs — this creates regular context shifts and makes it harder for me to get my focus back on creating all the awesome!
One of the techniques I have found quite successful recently was the Pomodoro Technique. The name comes from the original kitchen timer used by the creator and the focus is squarely on a low tech approach. The premise behind it is simple but effective. You focus on your task for a 25 minute period (a pomodoro) ignoring all external interruptions (or you forfeit the pom), take 5 minute break, repeat. After 4 pomodoros you take a longer break (15-30 minutes). The rules are as follows,
- A Pomodoro Consists of 25 minutes Plus a Five-Minute Break.
- After Every Four Pomodoros Comes a 15-30 Minute Break.
- The Pomodoro Is Indivisible. There are no half or quarter Pomodoros.
- If a Pomodoro Begins, It Has to Ring:
- If a Pomodoro is interrupted definitively – i.e. the interruption isn't handled it's considered void, never begun, and it can't be recorded with an X.
- If an activity is completed once a Pomodoro has already begun, continue reviewing the same activity until the Pomodoro rings.
- Protect the Pomodoro. Inform effectively, negotiate quickly to reschedule the interruption, call back the person who interrupted you as agreed.
- If It Lasts More Than 5-7 Pomodoros, Break It Down. Complex
- activities should be divided into several activities.
- If It Lasts Less Than One Pomodoro, Add It Up. Simple tasks can be combined.
My Honest Opinion
My previous development strategy was all kinds of broken. It worked provided I wasn't disturbed and I didn't really have a point at which I could turn round to someone and say
“give me 5 minutes and I'll get back to you”
The pom gives me that excuse and with the use of a simple widget I am able to know when I'll next be free (and so are other people). The hardest thing for me to accept was actually taking the 5 minute break post-pom. Initially (and sometimes still) I'd just work over the 5 minutes — just one more line of code, just test it once more — excuses, excuses, excuses. Breaking old habits is hard! Some of the other benefits from the technique is that,
- it really helps you visualise your task up front and break it down much better
- it helps you track work that you have done and how long tasks take.
- some pomodoro software even integrates into popular task lists and calendars
Resources
The Pomodoro Technique website is by far the best resource for this stuff and even has a free ebook on the technique and its background
- The site: http://www.pomodorotechnique.com/
- The book: http://www.pomodorotechnique.com/products.html#pomodoropdf
Personally it's going to take me while longer to get into the right mentality 100% but I think the benefits will be worth it. One day I'll be so efficient the code will just stream out of my brain and into my IDE - but for now I'll stick the mortals way of doing things.