Productivity and concentration are two very important words to someone who writes code for a living. There is a wide variety of tools, methodologies, tricks and “hacks” out there that claim to help one improve in these areas. One such technique that I’ve adopted over the past couple of months is known as the “Pomodoro”.
The Pomodoro Technique was developed by Francesco Cirillo in the 1980’s and is easily summed up in a few simple rules. It encourages you to accomplish more in a short intensely focused sprint called a “pomodoro”. Between these sprints you take short breaks to avoid mental fatigue and maintain creative freshness. A full pomodoro cycle goes like this
There is more you can do with it as well like marking the beginning of each pomodoro in your list so you get better estimating how much you can accomplish in each cycle but that is the technique in a nutshell. 25 minutes is the default if you feel you stay in the groove longer, you certainly could tailor the sprint and break periods to fit your creative workflow. Just don’t go too long. The point of the pomodoro is to reduce mental fatigue.
In my practice of the technique I’ve been using the standard 25/5-minute pomodoro/break periods for 3 or 4 cycles between the longer breaks. Breaking the task at hand down to a granular level with a strict path I feel has really boosted my focus and productivity. For many professions and for programming in particular it is fairly easy to be actively working for extended periods of time but still not accomplish what you set out to do.
While working on a feature you may notice a small bug in a nearby piece of the application. Once that bug is dealt with you receive an urgent email about another project or feature. By the time those are dealt with you’ve lost the half-implemented solution you were playing around with in your head for that initial problem. The pomodoro technique encourages you to stay on the path you set out on. When a work-related “distraction” comes up (like the bug or email mentioned above), make note of it but return to the list once it is written down. That way when you are done with the pomodoro you can prioritize it and put it into the queue for the next pomodoro. The goal is to have accomplished the most important tasks you needed to do by the end of the day, versus touching upon multiple issues that ultimately remain incomplete.
This technique is definitely not for everyone. I think that it is best utilized when you are working independently (solo or as a pair) for 2-4 hour blocks of the day. If your task at hand or work environment is highly collaborative it can actually hinder the team as a whole. If a team member is at a roadblock it does more harm than good if you are constantly telling them “Please sit on your hands for 17 minutes while I finish this pomodoro.” Also, for some people the underlying principles that make the pomodoro technique useful just seem to come naturally. So I do not think that this should be enforced upon an entire organization or used strictly for 100% of someone’s work week.
Many programmers, myself included, are intrigued by problems and feel a strong urge to instantly dive into them as they appear. I think the Pomodoro Technique is a great way to help channel our innate curiosity and solve the most important problems of our work day.
More Pomodoro Links:
Origninally posted on TechHui
© 2013 Lupine Software Development