There are many distractions at work, and 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?
This article is being highlighted as one of Gamasutra's top stories of 2013.
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.
If an interrupted person is allowed to suspend their working state or reach a "good breakpoint," then the impact of the interruption can be reduced. However, programmers often need at least seven minutes before they transition from a high memory state to a low memory state. An experiment evaluating which state a programmer less desired an interruption in found these states to be especially problematic:
During an edit, especially with concurrent edits in multiple locations
Navigation and search activities
Comprehending data flow and control flow in code
IDE window is out of focus
Ultimately, we cannot eliminate interruptions. (In some cases, interruption may even be beneficial; 40 percent of interrupted tasks are not resumed, and possibly because we realize that the task is not as important, or because the interruption gives us a chance to reflect on the problem.) But we can find ways to reduce the impact on the memory failures that often result from interruption. In this next section, I'll introduce some types of memory that get disrupted or heavily burdened during programming, and discuss some conceptual aids that can support them.
Prospective memory holds reminders to perform future actions in specific circumstances -- for example, reminding you to buy milk on the way home from work.
Various studies have described how developers have tried to cope with prospective memory failures. For example, developers often leave TODO comments in the code they are working on. A drawback of this mechanism is that there is no impetus for viewing these reminders. Instead, to force a prospective prompt, developers may intentionally leave a compile error to ensure they remember to perform a task. However, introducing compile errors creates a different problem, because they inhibit the ability to switch to another task on the same codebase. Finally, developers also do what other office workers do: leave sticky notes and emails to themselves.
A "smart reminder" is a reminder that can be triggered based on specific conditions, such as a teammate checking in code, or spatial proximity to a reminder (see Figure 3). It's basically the programming equivalent of a Post-It note.
Figure 3: An ambient reminder that becomes more visible as you get near the source of the reminder (e.g., not visible when in another project or namespace). Click for larger version.
Attentive memory holds conscious memories that can be freely attended to. This can come up in programming when a developer has to make similar changes across a codebase -- for example, if a developer needs to refactor code in order to move a component from one location to another, or update the code to use a new version of an API, then that developer needs to systematically and carefully edit all those locations affected by the desired change. Unfortunately, even a simple change can lead to many complications, requiring the developer to track the status of many locations in the code. Even worse, after the interruption, the tracked statuses in attentive memory quickly evaporate and the numerous visited and edited locations confound retrieval.
Touch points (see Figure 4) allow a programmer to track status across many locations in code. Studies examining refactoring practices have found several deficiencies in tool support, and one of those is the lack of ability to track many locations in code. As a workaround, developers abandon refactoring tools and instead rely on compile errors that were introduced when refactoring. Unfortunately, using compile errors to track changes is not a general solution and can still lead to errors. Touch points are inspired from how developers use compile errors. They can be recovered automatically by deriving all points of code recently visited, edited, and searched for.
Figure 4: A set of touch points created from a search and edit operation, allowing a developer to see which places have changed and flag locations that may need special attention.
Associative memory
Associative memory holds a set of nonconscious links between manifestations of co-occurring stimuli.
Developers commonly experience disorientation when navigating to unfamiliar code. The disorientation stems from associative memory failures that arise when a developer must recall information about the places of code they are viewing or what to view next. Researchers believe the lack of rich and stable environmental cues in interface elements, such as document tabs, prevent devs from recalling associative memories.
The presence of multiple modalities in a stimulus increases the ability to form an associative memory. In this sense, a modality refers to a distinct type of perception that is processed by distinct regions of the brain, such as auditory or visual pathways. Examples of different modalities and corresponding stimuli include: visual (error underline bars, highlighting code), lexical (name of file), spatial (position of scroll bar or tab), operational (edit/search/debug step action on file), and structural (logical position of file in hierarchy).
When multiple modalities are present in the same stimulus, more pathways are activated, thus increasing the chance of forming an associative memory. In contrast, a monotonous stimulus with a single modality is less likely to form an associative memory.
An associative link helps a programmer by situating information of multiple modalities with a program element; observations of developers suggest that they frequently rely on associations with environmental cues, such as tabs and scrollbars, for maintaining context during navigation. However, these cues are often insufficient: The act of navigation often disturbs the state of the cues, and the paucity of interface elements such as tabs, which often contain only a file name, starves associability. By improving navigating document tabs, which in default configurations are especially spartan, often showing just the name of the document, we could see increased recall from associative memory.
Two tabs adorned with cues of different modalities: such as error lines (visual) and edit icons (operational).
Episodic memory
Episodic memory is the recollection of past events. Software developers continually encounter new learning experiences about their craft. Retaining and making use of such acquired knowledge requires that developers are able to recollect those experiences from their episodic memory.
When recalling from episodic memory, developers commonly experience failures that limit their ability to recall essential details or recollect the key events. For example, a developer may forget the changes they performed for a programming task, or forget details such as a blog post that was used for implementing part of the task.
A code narrative is an episodic memory aid that helps a developer recall contextual details and the history of programming activity. Different types of narratives can be supported; for example, a review mode for high-level recall of events and a share mode for publishing a coding task for others.
A timeline of programming activities can help you or your teammates remember how you did a task and the resources you used. Click for larger version.
For more on code narratives, check out this blog, which is shared and published semiautomatically via a code narrative. (Note that as of this writing, the blog hasn't been updated recently.)
Conceptual memory
Conceptual memory is a continuum between perceptions and abstractions. How does the brain remember objects such as a hammer and concepts such as "tool"? Well, it first learns basic features of encountered stimuli, such as the wood grains and metal curves of a hammer, and then organizes those features into progressively higher levels of abstraction.
Developers are expected to maintain expertise in their craft throughout their careers. Unfortunately, the path to becoming an expert is not easily walked: For a novice, evidence suggests this can be a 10-year journey. Furthermore, for experts trying to become experts in new domains, like the desktop developer becoming a web developer, there are many concepts that must be put aside and new ones learned.
Studies examining the difference between an expert and novice find that performance differences arise from differences in brain activity. Not only do experts require less brain activity than novices, they also use different parts of their brains: Experts use conceptual memory whereas novices use attentive memory. That is, experts are able to exploit abstractions in conceptual memory, whereas novices must hold primitive representations in attentive memory.
Sketchlet (alpha) is a software tool designed to help a programmer form and prime concepts by supporting abstraction and reviewing concepts that need to be refreshed. You can try it for yourself at sketchlet.sourceforge.net.
By expanding the programming environment to tablets, sketchlets on a "Code Pad" can provide extra mental space to build and remember concepts about code.
For a full list of citations and references, read the original post here.
A diary study of task switching and interruptions (Czerwinski)
No task left behind?: examining the nature of fragmented work (Mark)
Resumption strategies for interrupted programming tasks (Parnin, Rugaber)
Subvocalization - Toward Hearing the Inner Thoughts of Developers (Parnin)
Task-evoked pupillary response to mental workload in HCI (Iqbal)
Read more about:
FeaturesYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
