What work intervals are more productive: short or long?

Question

Which sessions of work are more productive for programming: short (<= 30 minutes), mid-length or long (>= 2 hours)? In which cases? (Consider coding new functionality, doing small modifications, tweaking UI, refactoring, debugging, learning API, trying to understand other's code).

What can you tell from your experiences? Information from studies and best practices are also very welcome. Though it would be nice to see links or references.

Reliable information is prefered over complete answer.

---

Valuable takeaways:

• Focused thinking is the ultimate target here
• Generally uninterrupted work > 2-3 hours yields loosing focus and foggy thoughts
• When you are in flow, it's better to let yourself to work for 1-2 hours
• It worth to try practicing Pomodoro Technique, for helping to overcome thinking inertia and procrastination, to get better feeling of time. Especially it can help to start doing things that you don't like doing that much
• When using 'break management' software, you can allow yourself to be more flexible, e.g. to skip 1 break but not more. This allows you to adopt to the situation: be in flow, when there is a flow, stay manageable when are not in flow
• Fresh air, relaxing and excercises during break can help to get involved right hemisphere to get new ideas and solutions

Try software tools for 'break management':

• Pomodairo - it additionally tracks list of tasks and has pice UI
• WorkRave - provides more flexibility in configuring. also usable without speakers

Answer 1

I believe the most important thing is to really focus. Focused 5 minutes can be more productive than unfocused 5 hours tinkering, surfing at stack exchange sites, chatting, etc.

If you're really focused, you can't go on for hours continuously (if you can, then you're not really focused). Your brain will just run out of fuel. Indeed, most productivity / time management techniques, such as the Pomodoro Technique, are all about:

1. Breaking your goals into small, accomplishable tasks.
2. Taking one task at a time, focusing on it and only on it, for a timeboxed amount of time.
3. Taking at least a short break.

When doing something difficult, the warm-up time - loading all the information into your brain and understanding the problem - can be fairly long, so arbitrarily short periods aren't productive and the optimum uninterrupted period depends on the difficulty level of the task. But anything >> 2 hours is just stupid. Getting up from your chair for 5 minutes and getting some fresh air will save hours, as you'll come up with the solution that you've been trying to figure out for the last 2 hours.

---

More about Pomodoro Technique, as requested by Alexey: I have tried it, actually it's the only formalized time-management method I've ever tried as is. It was a beneficial experiment which helped me to value timeboxing, and I could still use it especially if I have trouble in "starting up". However, when in flow, I found pure Pomodoro - pause every 25 minutes - too stiff. Pausing just because of some precise, predefined time is up feels waste. The ringing timer is a distraction, and it does make the mental pieces fall down, and re-building your "brain cache" after the break takes time.

So nowadays I'm mostly working just according to the current situation. If I have trouble starting to do something, then I might set a strict goal, for example "do this for the next 30 minutes, period", or "complete this before getting more coffee". Such simple rules make self-discipline easier. But if I'm full of energy, doing some fine code, then I might do it for almost 2 hours straight, without interruptions. After such a sprint my brain runs out of energy, so pausing for a while happens of necessity anyway.

But just to be clear, I think my ability to work "according to the current situation" is largely because I have tried timeboxing, even though I rarely do strict timeboxing any more. Thanks to the trial, I know that when I'm procrastinating, then I'll make some kind of timebox - one box is often enough - and soon I'm in the flow again. So I highly recommend trying such techniques. Even if you don't end up using it all the time, you'll likely learn some useful tools to control yourself when needed.

Answer 2

I take 10 minutes pause every 45 minutes.

But when I'm in the flow, programming, I give myself the right to skip one, but only one.

It's important to pause to reset your mind. See it as a fresh reboot of your system. It will be faster.

During the pause, stop thinking about work. If you don't stop thinking about work, you are not pausing from it.

I don't skip pauses for tasks where focus is not important as in programming.

Answer 3

Long time intervals are typically more productive as most coding task have an overhead at the begin to get into the "flow".

Answer 4

I say strike when the iron is hot. Once you feel you're just trudging along, you need to stop and rest so you can be more productive in the long run.

The tough part about answering this question is measuring programming production. I'm not sure anyone has figured this out yet, so you'd have to rely on the developer's opinion. You could work on a complex problem for several hours only staring at the screen and if you come up with the answer, you may see this as productive. Do it for 45 minutes and come up with nothing, you may think you're unproductive. Try two more 45 minute sessions until you solve it. Now how do you score your sessions? Two 45 minute unproductive and one productive when previously you thought your two and a half hour long session was entirely productive since you solved the problem.

Answer 5

It depends on the nature of the task. Usually (as @Joonas noted) one can break down tasks into smaller chunks, each of which can be handled by 5 minutes to 1 hours of focused work. Sometimes one faces a more complex task which requires a longer time to immerse into, such as

• understanding a complex piece of code / algorithm (or the math theory behind it),
• designing a complex system.

In these cases longer work interval(s) are required - one simply can't make any reasonable progress during repeated short bursts. However, one's ability to really focus is limited to a couple of hours at most, so breaks are needed in between.

Another aspect is that with really tough problems, you need to engage your whole brain to get a solution - not just the logical/analytical left hemisphere, but the holistic right one too. Often, facing a tough problem, your left brain may simple get stuck, rolling around in the same mental rut over and over again, without any advance. This not only tires you but completely locks off any possibility for your other, creative brain hemisphere to engage into the process and to communicate any insights / results it may have found. So often, in such cases, having fully understood the problem and its context, and stated the relevant questions, the best approach may be to "relax", to do something completely different to engage your logical brain with, thus allowing your creative brain to work freely.

Answer 6

There is probably no universal correct answer to this question. Different people will find different regimes work for them, and, as also noted above, different tasks may make different demands.

If your programming work is entirely screen based, then for eyesight health grounds it is advisable to take a break every 50 minutes or so. However, that consideration aside, I think you need to recognise that different people have different practices. Not only that, regardless of your preferred option, the ability to avoid disruption is often seriously limited in an office environment.

I have to confess I am wondering why you would ask this sort of question.

Answer 7

To be productive it's not about taking breaks at fixed intervals. Take breaks when ever you feel you need a break to focus better.

Answer 8

I take break whenever I feel like having one. So far, in the worst of the days, the sum of these breaks has never been longer than an hour and a half. How long, and how many, in my case, depend on how interesting the task at hand is. Roughly, fewer and shorter breaks when the task at hand is more interesting. Longer and more number of breaks if the task at hand is less interesting.

That is, when the task at hand is more interesting, the pain in the hands, or tiredness in thoughts never occurs, or occurs only after the task is done. In the case of less interesting task, those things occur fairly often and fairly soon.

Could be the Theory of Relativity is at play here. :)