Gamasutra: The Art & Business of Making Gamesspacer
Programmer, Interrupted
View All     RSS
October 22, 2014
arrowPress Releases
October 22, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Programmer, Interrupted

April 22, 2013 Article Start Previous Page 2 of 4 Next

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. 

Article Start Previous Page 2 of 4 Next

Related Jobs

Avalanche Studios
Avalanche Studios — New York, New York, United States

UI Programmer
Avalanche Studios
Avalanche Studios — New York, New York, United States

UI Artist/Designer — Hunt Valley, Maryland, United States

Lead UI Engineer — Chicago, Illinois, United States

Lead UI Engineer


David Amador
profile image
Well, I just interrupted my work to read an article about not interrupting work so...
Anyway good article :)

Dolgion Chuluunbaatar
profile image
Pfffffffff this just shows how inefficient human beings are at programming. We clearly need to focus on building AIs that can program programs things for us.

Ruslan Shestopalyuk
profile image
Humans would probably have built it long time ago, if they weren't interrupted all the time.

Yama Habib
profile image
I don't know about you, but my IDE's already write most of my code for me. I give it another decade before it learns to not need my input at all.

Marcin kossowski
profile image
Great article.

Though I'm sad to hear that people leave full control of their code to IDE's....

Tylor Reynolds
profile image
Great article, I am interested in the touch points you mentioned. I was hoping you could explain further how they would work on a more detailed level and if you know of any IDE's/editors that support this feature.

Joe McGinn
profile image
The worst offender for interrupting programmers has to be the open plan office. Not suggesting a return to Mad Men, but small quiet semi-private rooms with 3-4 programmers in it can work wonders for concentration. I'm convinced that 20 years from now people are going to look back at current office design and just shake their heads with how inefficient and unhealthy they are.

Aaron Haaf
profile image
As much as I hate having other people bothering me, I can also appreciate the immediacy of problems being sorted out, which may be better overall for the team.

However, I do have a sign saying "DO NOT INTERRUPT UNLESS CAKE OR DEATH" somewhere when I really need to sort something crazy out.

Maybe a vacation room or two for "task-forces" or as a reward for good behavior.

James Carroll
profile image
@Joe ... I agree - prefer pod like environments for teams of devs that work closely together

Kelly A
profile image
Oh my goodness yes! We recently moved offices, but moved into a temp space while our new one was being reno'd. We were in an old college classroom, and it was quiet, and myself (an artist) sat with the programmers, and we got SO MUCH DONE.
Fast-forward to now, with an open-concept room - we have people walking behind us, people interrupting us, and it's so quiet you can hear a cricket fart, which is not a healthy work environment.
I understand the idealized notion that we'll all magically collaborate, but that just doesn't happen.

Ken Nakai
profile image
I agree. Cubicles with high walls that don't open to a traffic path (hallway, path to the kitchen) or groups of offices are good. At the same time, I think people need to learn to focus as well. You're never going to get an environment where someone isn't moving around at some point. I remember a developer who effectively needed to be locked away because every little thing interrupted him. I'm sorry but if you can't deal with people and the slight swoosh of someone walking six feet away from you or more, may I suggest what a college friend of mine used to do during summer: become a park ranger in the middle of nowhere.

I definitely agree that open offices where there are just no barriers at all are dumb. I believe in collaboration and keeping people together (thus not a fan of individual offices for everyone if that's feasible in a particular space). Just need to still enable people to be able to focus on their work (and I suspect it's going to get harder with the younger generation coming to the table wanting instant gratification--no patience--and used to the idea of being constantly distracted--texts, Twitter, all sorts of input--rather than focussed on a single task.

Nick Harris
profile image
Put the entire programming staff on their own floor several flights of stairs down from where the managers reside. Have no direct lift access between them forcing the managers to walk UP many stairs to "pop in for a quick chat". Have no IM, or email, or telephones in the programming area.

The only interruption should be the Fire Alarm.

Joe McGinn
profile image
Agree Aaron, that's why I'm suggesting office pods (nice term James!) of people who work in a similar area. And as Kelly says, in the context of game development they don't all need to have one job, I'd put designer/coder/artist who work together in one pod.

Nathan Mates
profile image
Joel On Software recommends that all programmers have a door. That's not feasible on most offices/budgets, but from personal experience, most office buildings allow for rooms of 2-4 people and a door, which work great. You can set that up as small pods of a task-oriented group (cross-discipline as needed), or a few programmers on a related area together.

Look at the articles on the design of Pixar's offices - they deliberately tried to make people meet, same as open plan offices. But, they did not try and make people meet at their desks. They made common areas (bathrooms, hallways) a common target to mix people. If you're already up and away from your desk for another purpose, a meeting doesn't take a programmer out of the zone. That's the kind of compromise that office makers need to make. Not this "let's make a giant mosh pit and hope that hearing two cow-orkers sixty feet away yap about something unrelated to work will spark communication and collaboration" nonsense. Peopleware (how many decades old is it now?) has the same point.

Worst part of being on an open-floor plan: hearing two associate producers. On speakerphone. To each other. I was located in an area between them, so I heard each of them twice (original and speakerphone).

Rakesh Raparla
profile image
Nice article i think i am sure i am the very best example for this one :D

Travis Martin
profile image
Ooh, this is really relevant to my interests! We work just two of us in my home office, and it's a point of contention that the non-programmer (hehe) interrupts me to great loss of productivity. We have developed a system, though, where if she has a problem she'll write it down, and we'll look over the list at the end of a specific time period.

It's great to know I'm not alone in this O_O;

Gregory Booth
profile image
Nice Article!

As someone working from home this is *really* relevant!