Programmer, Interrupted
Developers hate to be interrupted, and with good reason: it kills their productivity. Here's research on the care and feeding of the different kinds of memory programmers use.
We've discussed the effect of the working environment on the productivity of software developers. The constant interruptions and meetings that characterize the typical workplace lead most programmers, at some point, to fantasize about moving to a nighttime schedule for their coding work.
Source: Public domain (A. M. Bacon, Manual of Gesture, 1875)
How bad are interruptions, really? Susan Cain, in her book Quiet: The Power of Introverts in a World That Can't Stop Talking, quotes research indicating that "people whose work is interrupted make 50 percent more mistakes and take twice as long to finish it." Presumably this research covered a range of professions. There can be little doubt that software developers fall at one extreme of any such range -- they take longer get in "the zone" and longer to get back into it once their concentration has been broken by outside factors. Paul Graham's classic essay "Maker's schedule, manager's schedule" explores this point in depth.
Research
Chris Parnin is a PhD candidate studying computer science at Georgia Tech. His research is all about the question of interruption and resumption of work, specifically for programmers. He not only studies how long it takes programmers to recreate the context of their work in order to resume an interrupted task; he looks into specific strategies and tools that hold out the promise of making the process faster and easier.
Parnin's research shows that when a programmer is engaged in an editing operation, only 10 percent of interruptions are resumed in less than a minute. (In other words, "There is no such thing as a quick question!" -- as many of us have found ourselves blurting to our interruptors.) Also, programmers are likely to average just one uninterrupted 2-hour session in a workday.
The key to improving task recovery time, according to Parnin, is to consider the different kinds of memory programmers use to do their work. Humans have a number of different flavors of memory, which arise and are processed in different regions of the brain: prospective, attentive, associative, episodic, conceptual. Parnin suggests techniques including specific functional additions to IDEs that would support each kind of memory when the inevitable interruptions occur.
The comments on Parnin's article are worth a look as well. One reader notes that pair programming can help with the interruption problem: one person holds onto the context while the other deals with an interruption, and work can resume much more quickly. Another reader, seemingly a junior developer, admits that now he feels guilty, but that "there must be a point at which it will actually be more effective interrupting a more senior developer, to get an answer, rather than struggle on your own for hours on end to resolve an issue." Food for thought.
Related posts: