A reprint from the April 2013 issue of Gamaustra's sister publication Game Developer magazine, this article, aimed at programmers, explores ways to help you take your work back from distraction.

I'm writing this article in a dull state: low sleep, busy, disorientated, and interrupted. I try all the remedies: using the Pomodoro Technique, working in coffee shops, wearing headphones, and avoiding work until being distraction-free in the late night. But it is only so long before interruption finds a way to pierce my protective bubble.

Like you, I am "programmer, interrupted." Unfortunately, our understanding of interruption and remedies for restoring focus are not too far from homeopathic cures and bloodletting leeches. But what is the evidence, and what can we do about it?

The cost of interruption

Every few months I see another programmer asked to not use headphones during work hours or interrupted by meetings too frequently to do any work, who has little defense against these demands. I also fear our declining ability to handle these mental workloads and interruptions as we age.

Researchers who have studied the costs of interruptions in office environments estimate that interrupted tasks take twice as long and contain twice as many errors as uninterrupted tasks. They also found that workers have to work in a fragmented state, because 57 percent of tasks are interrupted (see References for citations).

For programmers, there is less evidence of the effects and prevalence of interruptions; typically, the number that gets tossed around for getting back into the "zone" is at least 15 minutes after an interruption. Interviews with programmers produce a similar number. Nevertheless, numerous figures in software development have weighed in: Y Combinator founder Paul Graham stresses the differences between a maker's schedule and a manager's schedule, and 37signals founder Jason Fried says the office is where we go to get interrupted.

Studying programmer interruption

Based on an analysis of 10,000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio, and a survey of 414 programmers, we found:

• A programmer takes 10-15 minutes to start editing code after resuming work from an interruption.
• When interrupted during an edit of a method, a programmer resumed work in less than a minute only 10 percent of the time.
• A programmer is likely to get just one uninterrupted two-hour session in a day.

We also looked at some of the ways programmers coped with interruption:

• Most sessions programmers navigated to several locations to rebuild context before resuming an edit.
• Programmers insert intentional compile errors to force a "roadblock" reminder.
• A source diff is seen as a last-resort way to recover state, since it can be cumbersome to review.

The worst time to interrupt a programmer

Research shows that the worst time to interrupt anyone is when they have the highest memory load. Using neural correlates for memory load (by measuring pupil diameter, for example), studies have shown that interruptions during peak loads cause the biggest disruption (see Figure 1).

Figure 1: Tracking the change in pupil diameter over time for individuals given tasks of varying difficulty.

In our study, we looked at subvocal utterances during a programming task to find different levels of memory load during programming tasks (see Figure 2). When people perform complex tasks, subvocal utterances (electrical signals set to the tongue, lips, or vocal cords) can be detected. This phenomenon has long intrigued researchers, some likening subvocal signals to the conduits of our thoughts. Recently, researchers have even been able to decode these signals into words.

Figure 2: Electromyogram (EMG) signals correlated with a 13-minute programming task for modifying a Tetris game.