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

Structuring your environment to support your memory

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

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

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.