Programmer Interrupted

I’m writing this post in an apt state: low-sleep, busy, disorientated, and interrupted. I try all the remedies: Pomodoro, working in coffee shops, 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 them are not too far from homeopathic cures and bloodletting leeches.

But what is the evidence and what can we do about it? Every few months I still see programmers who are asked to not use headphones during work hours or are interrupted by meetings too frequently but have little defense against these claims. I also fear our declining ability to handle these mental workloads and interruptions as we age.

The costs of interruptions have been studied in office environments. An interrupted task is estimated to take twice as long and contain twice as many errors as uninterrupted tasks (Czerwinski:04). Workers have to work in a fragmented state as 57% of tasks are interrupted (Mark:05).

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 similiar number (vanSolingen:98). Nevertheless, numerous figures have weighed in: Paul Graham stresses the differences between a maker’s schedule and manager’s schedule. Jason Fried says the office is where we go to get interrupted.

Interruptions of Programmers

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

• A programmer takes between 10-15 minutes to start editing code after resuming work from an interruption.

• When interrupted during an edit of a method, only 10% of times did a programmer resume work in less than a minute.

• A programmer is likely to get just one uninterrupted 2-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 but can be cumbersome to review

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, such as pupillometry, studies have shown that interruptions during peak loads cause the biggest disruption(Iqbal:04).

We looked at subvocal utterances during a programming tasks to find different levels of memory load during programming tasks (Parnin:11).

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 (Trafton:03). However, programmers often need at least 7 minutes before they transition from a high memory state to low memory state (Iqbal:07). An experiment evaluating which state a programmer less desired an interruption found these states to be especially problematic (Fogarty:05):

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

A Memory-Supported Programming Environment

Ultimately, we cannot eliminate interruptions. In some cases interruption may even be beneficial. But we can find ways to reduce the impact on the memory failures that often result from interruption. I introduce some types of memory that get disrupted or heavily burdened during programming and some conceptual aids that can support them.

Prospective Memory

Prospective memory holds reminders to perform future actions in specific circumstances e.g. to buy milk on the way home from work (PM).

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 (Storey:08). 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 (Parnin:10). A problem with compile errors is that 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 (Parnin:10).

A smart reminder is reminder that can be triggered based on conditions such as a teammate checking in code, or proximity to a reminder:

Attentive Memory

Attentive memory holds conscious memories that can be freely attended to.

Some programming tasks require developers 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 to 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 an interruption to such as task, the tracked statuses in attentive memory quickly evaporate and the numerous visited and edited locations confound retrieval.

Touch points allow a programmer to track status across many locations in code.

Associative Memory

Associative memory holds a set of non-conscious 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 associative memories from being recalled.

The presence of multiply modalities in a stimulus increases the ability to form an associative memory. In this sense, a modality refers to distinct type of perceptions that is processed by a distinct regions of the brain, such as auditory or visual pathways. Examples of different modalities include: lexical, spatial, operational, and structural. 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. In particular, by improving navigating document tabs, which default configuration are especially spartan, often just showing the name of the document.

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 those 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 the blog post that was used for implementing a 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. Two narrative structures are currently supported: A review mode for high-level recall of events and a share mode for publishing a coding task for others.

See a blog post shared and published semi-automatically via a code narrative.

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? The brain 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 (Chi:82). 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 (Milton:07): 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.

Sketchlets(alpha) helps a programmer form and prime concepts by supporting abstraction and reviewing concepts that need to be refreshed.

Future

• fMRI studies of programmers. See preliminary research!
• Will future programmers take designer nootropics for boosting memory and attention to keep up?
• Can we predict the memory load of using a language feature or performing a particular programming tasks?
• What new tool ideas can be derived for programmers?
• What experiments need to be run?

Interested in participating in an experiment or have any ideas? Email me at [email protected] or comment below.

References