Where can I find articles on why interruptions are bad for programmers? [duplicate]

Question

This question already has an answer here:

• How to explain a layperson why a developer should not be interrupted while neck-deep in coding? 18 answers

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.

Answer 1

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.

Answer 2

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.

Answer 3

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:

I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there's sometimes a cascading effect. If I know the afternoon is going to be broken up, I'm slightly less likely to start something ambitious in the morning. I know this may sound oversensitive, but if you're a maker, think of your own case. Don't your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don't. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.

Answer 4

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).

Answer 5

You can start with Joel Spolsky's books.

For example Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity book.

Answer 6

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.

Answer 7

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.

Answer 8

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.