Has it ever happened to you that you got so much into the work that hours were passing by as if they were just minutes? I’ve been there countless times while developing software. I’ve heard about it from other developers. It was called by various names – being in the zone, the state of flow, etc. Working like this without any distractions might seem as a very productive time, but in my experience, it often isn’t.
What can go wrong? There were times when I spent the whole afternoon investigating a bug without any progress. Only after going home, a new idea suddenly came to my mind, and I solved the problem in 10 minutes. Other times, I found myself spending hours on refactoring some code, just to make it slightly nicer to read.
The solution that helped me with these problems is the Pomodoro technique. The basic idea is pretty simple: Chunking your work into high-focus blocks (called Pomodoros) of 25 minutes, which are followed by a 5-minute break. Each block is focused on one task. After 4 blocks, you should take a longer break (15-30 minutes). While the basic rules are as simple as that, putting them into practice means going through several obstacles, to which I’ll get back later.
The original author was using a tomato-shaped kitchen timer (Pomodoro is an expression for tomato). These days you can choose from many Pomodoro apps on all platforms (I’am currently using https://gnomepomodoro.org/ on Ubuntu).
Why is it so great?
Pomodoro brings checks at regular intervals, which enable you to stop and evaluate what you’ve done in the past 25 minutes. It gives you a chance to reflect if you’re still working on what you planned to work on, and also to think about what makes sense to do next. This technique allows me to detect if I’m off track much sooner
Another point is that it allows me to switch between multiple tasks without unproductive multitasking. I think it’s often productive to alternate between two tasks – one more challenging and one less. Pomodoro proved to be very efficient for me years ago when I was writing my master’s thesis and studying for the state exams. Learning for the exams was the more challenging task which I could do only for so long before my brain capacity to absorb new information was exhausted. Then was the right time to switch to writing the thesis, which was just putting down what already existed in my head.
Similarly, I find that software development also consists of these two types of tasks. The first type is learning/choosing a new tool/technique/library that I know will be needed for the next task in the backlog. It can also be doing a code review of your colleague’s pull request. The second one is, of course, writing code for the current in-progress task.
This is a great tool for fighting procrastination. Procrastination is often about putting off a task because you’re afraid of how big it is and how much time it will take. With Pomodoro, you just commit yourself to spending 25 minutes on it and see where you are afterwards.
Which problems did I run into?
The first problem is distractions during the 25-minute block. Distractions in the office environment are the reason I gave up on using Pomodoro when working in an office for the past couple of years. Only in recent weeks, because of working full time from home, I gave it another try. Thanks to the coronavirus it might be a good time for you to try it as well.
The second problem is that I often keep working after Pomodoro ends. I’m so deep in the problem that I think it would be a waste to stop. So I promise myself to work just a few more minutes, but I can get lost in the zone, and suddenly it’s tens of minutes. This usually shows me that I didn’t break the problem into small enough chunks for the 25-minute Pomodoro. Breaking down problems into smaller ones is also something which has proved very useful for me. Sometimes it’s hard, sometimes maybe even not possible, but in my opinion it’s always worth trying to do small incremental changes, commit every 10-20 minutes after unit tests pass.
The last problem I sometimes experience is how to switch to another branch when I have some changes on the current branch that are not yet ready for a commit. Sometimes I can stash them, other times I do a “WIP” commit. But my ultimate solution is cloning the git repository twice, running two local instances of the project on two different ports. This way I can quickly switch from the branch I’m writing code on to my colleague’s branch I want to review, or to my pending-review branch after it got changes requested. Having two instances is also useful for comparing two branches to see if a bug is only on the development branch or already in the production branch.
In this blog post, I tried to describe how I tried to improve my productivity and what worked for me. I cannot guarantee that the same will work for you. I share my experience as an inspiration, as ideas you can try and see if it works for you. If you decide to give it a try, I’m eager to hear how it turned out for you. If you have some other techniques that have proven useful to you, I’m interested to know as well.