Gamasutra: The Art & Business of Making Gamesspacer
Programmer, Interrupted

Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 25, 2014
arrowPress Releases
April 25, 2014
PR Newswire
View All





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


 
Programmer, Interrupted

April 22, 2013 Article Start Page 1 of 4 Next
 

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. 


Article Start Page 1 of 4 Next

Related Jobs

Infinity Ward / Activision
Infinity Ward / Activision — Woodland Hills, California, United States
[04.24.14]

Principal / Lead Rendering Engineer
Gearbox Software
Gearbox Software — Plano, Texas, United States
[04.24.14]

Graphics Programmer
Turtle Beach
Turtle Beach — San Diego, California, United States
[04.24.14]

SENIOR C# SOFTWARE ENGINEER
SOAR Inc.
SOAR Inc. — Mountain View, California, United States
[04.24.14]

Unity 3D MiniGame Programmer (and Designer)






Comments


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!

:D


none
 
Comment: