Take the 2-minute tour ×

I've read/heard that interruptions are bad for programmers. I've also read/heard that getting into 'the zone' is good. I don't doubt these assertions, but I'd like to educate colleagues (managers, mainly) and family members (for when I work from home) about the perils of interruptions and the productivity gains to be had from 'the zone'.

So could anyone point me to articles and/or books that make the arguments well? Feel free to make those arguments here in an answer if you like. It would be helpful if there were some in there that were aimed at managers and non-programming colleagues.

share|improve this question

marked as duplicate by Jim G., Robert Harvey, gnat, Martijn Pieters, thorsten müller Apr 9 '13 at 7:21


The psychological term for being in the zone is "Flow" en.wikipedia.org/wiki/Flow_%28psychology%29 –  StuperUser Sep 5 '11 at 8:43
@StuperUser Good one, I'd say that link deserves it's own answer. –  Charles Roper Sep 5 '11 at 8:54
The occasional interruption is OK. My boss is in my office with questions so often that last week I finally told him "Look, I don't mind, as long as you don't expect me to produce anything." He's perfectly aware, but I don't think anything's gonna stop the interruptions. sigh Had to get this off my chest. :) –  MetalMikester Sep 5 '11 at 14:29
The whole reason I posted the question is to get this thing off my chest. I just needed some good hard info as backup. :) –  Charles Roper Sep 8 '11 at 14:11
Joel Spolsky: Human Task Switches Considered Harmful –  user16764 Apr 8 '13 at 16:29

8 Answers 8

The classic on this topic (and many more) is Peopleware: Productive Projects and Teams. One chapter deals with the devastating effect of interruptions on programmer productivity.

Chapters 10 through 12 of the second edition of Peopleware are focused on dealing with interruptions and "flow", which is when you are "in the zone". Here are some passages that might be most relevant:

...for anyone involved in engineering, design, development, or like tasks, flow is a must. These are high-momentum tasks. It's only when you're in flow that the work goes well.

...requiring fifteen minutes or more of concentration before the state is locked in. During this immersion period, you are particularly sensitive to noise and interruption.

If the average incoming phone call takes five minutes and your reimmersion period is fifteen minutes, the total cost of that call in flow time (work time) is twenty minutes.

I think from here, you can probably do the math as to how costly an interruption is to the organization as a whole, if you know the approximate time to get into flow and how long your interruptions are. That also leads into the next section...

A discussion of what the author's call the E-Factor, which is a metric that describes the work environment in terms of uninterrupted hours (time in flow) and time spent in the working environment. Low E-Factors suggest poor working conditions that don't allow workers to function at peak efficiency.

share|improve this answer
Could you add some relevant quotes from Peopleware? Or would you object if I went through my copy and added a few that I thought were relevant? Peopleware is a fantastic book, but a couple of short passages as a teaser would be nice and helpful to the author in making sure it's what he's looking for. –  Thomas Owens Sep 5 '11 at 14:17
@Thomas, I can't spend much time on this now, so I appreciate if you add some quotes :-) –  Péter Török Sep 5 '11 at 15:18
I added a few things. I think it's pretty much in line with what you were referencing, without significantly "spoiling" the work of the authors. –  Thomas Owens Sep 5 '11 at 15:34

One of the classic arguments that people will pose against interruptions comes from "Do programmers have quiet working conditions?" number 8 on the seminal: The Joel Test: http://www.joelonsoftware.com/articles/fog0000000043.html

The psychological term for being in the zone is "Flow" en.wikipedia.org/wiki/Flow_%28psychology%29, which would be useful for researching more details on its effect on productivity.

share|improve this answer

Paul Graham's article, aptly title Makers's Schedule, Managers' Schedule describes how interruptions actually affect productivity, in a very pithy manner that both managers and engineers can understand.

Here's a particular paragraph that sums it up nicely:


share|improve this answer

There's a good article at 37Signals ("The science of interruptions") which seems relevant.

I'm pretty sure McConnell talks about it in Rapid Development or the Survival Guide, but I don't have my copies handy to check. He is worth reading anyway.

Edit: Actually, it might be Code Complete I'm thinking of (thanks to MarkJ for comment).

share|improve this answer
McConnell cites a study from Peopleware on this question in Code Complete 2 (section 28.5 physical environment). I can't find any direct discussion of it in Rapid Development. But, all his books are definitely well worth reading! –  MarkJ Sep 5 '11 at 12:30
thanks - I'll edit. –  Steve Haigh Sep 5 '11 at 14:09

There's two sides to this: educating the rest of the organization as to the cost of interrupting programmers, and educating programmers on how to avoid being interrupted. Because, you can do a lot to reduce the cost of interruptions on your side too.

The thing is, many of the things managers and HR and accounts do are also necessary to the overall process you're embedded in, and so their issues have to be dealt with as well. But they don't have to get your attention right this second, not if they're properly organized. So beat into them that they must use email, the phone is for emergencies, and that meetings should be minimized.

But you can't get out of meetings entirely, as they're part of the mechanism that keeps your manager able to deflect the interruptions. So, schedule them, and try to keep big enough blocks of time free of them. If your company has a calendar system, chuck blocks of coding time into it; you're not free when you're not in a meeting (as a manager might think of it), you're working.

One of the big advantages of a process like Scrum is that it gives enough contact time with the managers to let them get most of their work done in standup meetings and scrum process time, leaving most of the rest of the programmer's time for code.

A scrum team can be pretty noisy, but also you get to look around the room and not call out if someone really is in focus mode; you can observe that if you look. Walls between team members are a problem because they force you to create interruptions before you find out if this is a good time or not, either by poking your head around the door or by calling.

share|improve this answer

Just practice keeping mental pointers to what you were doing. If you fail to step away from The Zone and return to your previous thoughts, then learn how to multitask. You can't expect to operate in a void of sterile seclusion while writing code. Consider writing code more like writing a paper or a story for humans where you have in mind the next steps, moves, addition to the plot, and storyline.

For instance "I need to write this code to compare this vector to this string using boost::algorithm::compare". Now in-comes the boss chatting about how you suck or in comes the family about how you are a dead-beat father. After that, laugh it off and return to the pointer in your head. Fifteen minutes is way to long to recall what one was doing. Eat some mental-boosting foods like fish oils. Check out Luminocity.

Don't live in a Seran-Wrap bubble and learn to shift focus and return. I am certain it will make you a better programmer and better able to work in an environment of increased noise and distraction but able to shift gears easily.

share|improve this answer
Sorry, we are humans, not machines. Yes, all these strategies help, but they cannot replace dedicated concentration and focus. If you are happy with not being at your best, your psychology probably differs from the typical developer, which can be seen as an advantage. Especially, when your in less than ideal environments. There are several reason a developer wants to be at their best (achievement, self-improvement, increasing ones own value to the company, etc.) If you can just shrug off not being at your best and being treated poorly you are way different than me. –  Derek Litz Sep 11 '13 at 14:02
That being said I like the answer because it illuminates the fact that even people in small communities can be quite different. –  Derek Litz Sep 11 '13 at 14:05

This article has some real data and references: http://blog.ninlabs.com/2013/01/programmer-interrupted/

For example, they analyzed of 10,000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio and a survey of 414 programmers and found that a programmer takes between 10-15 minutes to start editing code after resuming work from an interruption.

share|improve this answer
would you mind explaining about this in more detail - how and why does it answer the question asked? "Link-only answers" are not quite welcome at Stack Exchange –  gnat Apr 8 '13 at 16:18
Fine, but if the OP explicitly asks for links you'll see (like in this question) that many of the answers consist almost entirely of links. –  Leopd Apr 8 '13 at 17:17
