In your experience, what is the best length of a single coding session before taking a break? For example, are you the most productive if you code for 2-3 hours, take a break, and return to it, or when you keep going for 5-6 hours or longer without a break?
For me its more about when I start and momentum than how long. I do best early in the morning, and if it's 'clicking' I may notice it's 4pm and wonder where the time went. So I don't have set time-periods where breaks are needed. Plus it depends on what I'm working on.
When I get in the zone ... I don't stop.
EDIT: There are a lot of great answers to another question What tricks do you use to get yourself “in the zone”?. Specifically, this answer by CMPalmer is pretty good. Beyond that, getting in the zone is more about setting up the right conditions; having a task that meets your maximum skill level, having total clarity with regards to the end result, and eliminating all resistance (interuptions, distractions, slow computer, etc...).
Six hours without a single break?? Maybe I am not a VERY experienced (meaning, aged) programmer, but I never coded more than 30 minutes without a break. That means not "going out for a walk" or "taking coffee". That means just sit back for 30 seconds and relax thinking something else... or answer a question on SO... or listen to a song...
But then, I can go on like this for hours :)
Depends what I'm doing.
The last few nights I can trivially work for 6 hours, no stopping, and be productive. But sometimes, if I hit something I'm stuck on, or is confusing me, I'll take a break, and then come back in a bit, after thinking about some other things, and solve it very easily.
There is no real number. It relates only to what I'm doing, and if I am engrossed enough, I'd probably forget to eat dinner (actually, that happened to me tonight).
For me it depends on the work I am doing. If I don't have a very high interest in what I am doing I usually need at least a two minute break every hour. If I am really interested in the work I am doing I end up realizing it is 4am and I need to go to bed.
I prefer to do about 10 to 30 minutes of writing code before I start to rest and think again. Writing code isn't the important part of developing software.
During the rest, I'm actually thinking ahead about the next steps that need to be coded. These "moments of rest" can be just a few minutes or half an hour or more.
If you include "Thinking about the problem" to the coding session then it would easily be 40 hours and longer. :-) I just continue to think about the code long after I stopped typing. I even caught myself thinking about code while asleep. However, when I'm not coding, I also allow small distractions to enter my head, like "what's for lunch" or "Wonder what my girlfriend will be wearing tonight". But in general, the coding problem will often stay the main focus in my head until it's done, tested and stamped with [OK].
When doing something else, like driving, having lunch or looking at what my girlfriend is wearing, I just can't help it but the coding project will keep popping up it's hear over and over again. Can't explain why that is, but it just appears as if one part of my brain is always working 24/7 at such projects.
I'm trying to avoid working at two projects at the same time unless they're closely related or extremely different. (In the latter case, I switch between them, but always keep one of them in my mind.)
I continually find that there are no guidelines. If I'm in a groove, I keep going.
If I stop to take a break, it's entirely possible that I'll lose my train of thought and my productivity is shot.
This can mean anything from 1-2 hours to get something quick down all the way up to 8-9 hours if I'm working on something big and really complex.
See Pomodoro Technique.
I break roughly every half hour for a minute to stand up, get some water, etc.
It depends on:
- Complexity of what you're working on
- How interesting/fun it is
- How well you slept the night before
- How much coffee you had
Well, from there on it branches to life the universe and everything really, but the most solid advice here is to recognize when you're no longer above 80% capable (of doing what you should be doing, but where is the fun in not generalizing). At some point you'll notice you're slipping, and need some time away from the keyboard to come up with a solution to a problem or new ideas on how to tackle a nasty wall you've been hitting.
You should trust your feelings about it.
If I get in the flow, I will work for a long time (some hours) without a break, usually until I solve the ticket or I get stuck. If I solve a ticket I give myself a break, a little chat, a short surf-session or e-Mail-reading as reward for the achievement, before starting the next. If I have difficulties to get into the flow, I take more breaks, drink coffee or so until it works.
I break down my coding sessions into units of logical work, e.g., #1 fix this bug, #2 refactor this code, #3 implement this new interface, etc. After each of those, if I feel like it, I take a break, get a coffee, whatever for about 10 minutes. I find this is enough of a context switch that I can wrap up for the day or move to non-coding responsibilities if need be, but not so much that I can't get right back into things otherwise.
I'm in my early forties, and have been programming for over 25 years. I find that all of the following hold true:
- The important part is not the coding and typing, but the thinking.
- Coding/typing/thinking are sometimes interleaved, and can often happen in very quick cycles (think a bit, write tests, write code, commit; then start over). The whole things happens in "the zone", or "flow", or "hack mode".
- Sitting versus standing up versus walking around is irrelevant. What happens inside your head(s) is relevant.
- Sitting too long at a time is seriously bad for your back, even with a really good chair. Get up and do some stretches or excercises every once in a while. This need not stop your thinking.
- People are different. Some people work best in short, very efficient bursts; others labor less intensively for longer.
- Very few people can handle long days for extended periods of time. Even fewer can be productive that way.
I've been coding for a while as well, and suffer from the usual developer afflictions: bad, back, bad eyesight, etc. ;-)
Personally, I find I get up and wander if I need some thinking time (increased oxygen flow to the brain?), other times (like the other day), I'm sitting down for three hours solidly working, no food, no drink - definitely "in the zone".
Always go out for lunch tho', never eat at your desk, and do some stretches for your back...
The most important thing for me to be productive is to be isolated from outside disturbances. Be it people who address me directly, or background noise. Like sound from a television or a radio in the background.
Music is OK, I can work with music, but if there is the sound of people talking in the background, I cannot help but focus on what they say, and that effects my concentration.
Apart from that, I take a break when my brain feels like it's been filled up ;)
About 45-min to an hour is right for me ... just from the physical point of view. You need to get up, walk around. I often go for a restroom break, get a drink, etc.
However, as another poster has said, it's what's happening in your head that is important. I often find that I find a solution, or a better solution, to the problem that I have been working on (usually at a low level - a small subproblem of the overall problem) by the time I have walked back to my computer.
Extended breaks - i.e. 1/2 hour to an hour - depends on the reason, but usually when you get stuck or start fading out of the zone is a good time for a more extended break.
You might find this interesting: http://stackoverflow.com/questions/92159/how-do-you-vent-stress-as-a-programmer/92528#92528
It's a pretty long write-up about how I finally found a sustainable, sane, productive state. And, more broadly, lifestyle.
2-3 hours, with noise canceling headphones. Check out the little book of flow for more on this and why.