ShareYourGroupShareYourGroupPomodoro

Pomodoro for coding and programmers

Programming punishes interruption more than most work. A little structure around each round protects the thread and stops rabbit holes.

Define the round by a result

"Work on the login feature" is a direction, not a task. Before pressing Start, name something that will be true at the end of the round:

A result gives the round an end you can recognise. If it turns out to be too large, you find out in 25 minutes instead of at the end of the afternoon.

Learning to code

For students working through a course or a book, a round is best spent typing, not watching. A useful pattern: watch or read for one round at most, then spend the next round writing the code yourself without looking, then a third round changing it: a different input, an extra feature, a deliberate error to see the message. Code you only watched is forgotten quickly; code you fought with stays.

The rabbit hole rule

Every programmer knows the afternoon lost to a side problem: a configuration that will not load, a library version, a warning that is not even related to the task. Use the bell as a checkpoint. At each ring ask one question: "Am I still working on what this round was for?" If you have been off the path for a whole round, stop and choose openly: is the side problem worth another round, or is there a way round it? Asking a colleague, or searching the exact error message, often beats a third round of guessing.

Leave a note at the bell

When the timer rings in the middle of a thought, write one comment or one line in your notes: what you were about to try and why. "Next: check whether the token expires before the retry." It costs twenty seconds and lets you resume in one minute instead of ten. The same habit at the end of the day makes tomorrow's first round easy to begin.

Builds, tests and waiting

Long builds and test runs invite a "quick look" at something else, which becomes a lost quarter of an hour. Keep a short list of in-task things to do while waiting: read the code you just wrote, write the next test, update the notes, rename the unclear variable. If the wait is longer than a few minutes every time, it may be worth a round of its own to make the tests faster.

Debugging in rounds

  1. Round one: reproduce the bug reliably and write down the exact steps.
  2. Round two: narrow down where it happens, by halving the suspect area.
  3. Round three: form one guess, test it, and write what you learned.

Writing down what you have ruled out stops you from checking the same thing three times, which is the commonest waste in debugging.

Longer rounds

Many programmers prefer 50 minutes with a 10 minute break, because loading a large piece of code into the mind takes time. That is fine. Keep the break real: stand up and look away from the screen. The answer to a stubborn bug has a habit of arriving on the way to the water cooler. For more on long concentration see deep work and flow.

Chat, reviews and meetings

Team chat is the main breaker of coding rounds. Set a status during rounds and read messages in breaks. Group code reviews into one or two rounds a day so that colleagues are not blocked, instead of answering each request the moment it arrives. If stand-up is at 10:30, plan one solid round before it and start the deep block after it.

Count and learn

Note the rounds each ticket or exercise takes. Over a month you will estimate your own work much better, and you will see which kinds of task run over: usually the ones that began without a clear result. The page on estimating tasks shows how to use the record.

Questions people ask

Is 25 minutes too short for programming?

For small, well-defined tasks it is fine. For work that needs a lot of context, try 50 and 10, or two linked rounds with a quiet pause between them.

What do I do with ideas for other parts of the code?

Write them in a notes file or a TODO list in a few words and continue. Fixing them now is how a round loses its purpose.

Can I pair program in rounds?

Yes. Many pairs change who types at each bell and use the break to step back and discuss direction.

Open the timer

More guides

An independent site. The method described here was created by Francesco Cirillo, and Pomodoro Technique is his registered trademark. This site is not connected with him or his company. The timer is free, needs no login and keeps your settings and counts only in your own browser.