Programmers, Teach Non-Geeks The True Cost of Interruptions

Interruptions are one of the biggest sources of inefficiency for programmers. Now, to be fair, they’re probably a big source of inefficiency for everyone, but relatively speaking, they’re worse for programmers. To understand what I mean, let’s take someone whose job is in sales. A lot of the day is probably spent on the phone or in transit to and from meetings. In a given meeting or while reviewing notes prior to a meeting, an interruption to a sales person means time spent dealing with the interruption, a shake of the head, and a “where was I… oh, right.” For a manager, the day is often just a series of never-ending interruptions. In a management capacity, I find it common to sit down at lunch, still not having done the first thing I planned to do that day. Paul Graham has an excellent article about the different natures of the day for managers and for people he calls “makers,” a group that clearly includes programmers.

For a programmer, an interruption is oh-so different. There you sit, 12 calls into the call stack. On one monitor is a carefully picked set of inputs to a complex form that was responsible for generating the issue and on the other monitor is the comforting dark theme of your IDE, with the current line in the debugger glowing an angry yellow. You’ve been building to this moment for 50 minutes — you finally typed in the right inputs, understood the sequence in which the events had been fired, and got past the exact right number of foreach and while loops that took a few minutes each to process, and set your breakpoint before the exception was triggered, whipping you into some handler on the complete other end of the code base. Right now, at this exact moment, you understand why there are 22 items in the Orders collection, you know what the exact value of _underbilledCustomerCount is and you’ve hastily scribbled down the string “8xZ204330Kd” because that was the auto-generated confirmation code resulting from some combination of random numbers and GUIDs that you don’t understand and don’t want to understand because you just need to know what it is. This is the moment where you’re completely amped up because you’re about to unlock the mysteries of what on earth could be triggering a null reference exception in this third party library call that you’re pretty sure —

“HI!!! How’s it going? So, listen, you know that customer order crashing thing is, like, bad, right? Any chance I can get an ETA on having that fixed?”

Interrupted

DAMNIT!!!!

The project manager just startled you while you were getting ready to hit the next instruction and you hit “step over” instead of “step into!” He’s droning on and on about the importance of himself or the customer or something that you’re not listening to because you’re trying to control your rage at having lost all of your debugging context while also starting to think ahead to how you can get back to the point you were at in maybe 30 minutes instead of 50. But it’s no use. PM’s boss sees PM talking to you, walks over, and now there’s a full-blown discussion about the Initrode account going on next to your desk, loudly, complete with ridiculous buzzword BS bingo and sports metaphors about “closing out the game in the endzone” or something. By the time the dust settles and you’ve been Six-Sigma-ed into submission by 3rd degree black belts, you know that you’re going to be ordering a pizza and doing this again at 7 PM after everyone else leaves so that you can have some peace and quiet to work. All you can do is shake your head in sad disgust and wonder, “what on earth does 8xZ204330Kd mean and why did I write that down?”

But here’s the real insult-to-injury moment. When you try to explain to the PM how insanely destructive to your productivity that interaction was, he snorts at you and tells you not to be so melodramatic. He wanders off, wondering why programmers are such overdramatic prima donnas. Your non-techie peers just don’t get it, no matter how many times you try to make them understand. When part of your job is walking around all day demanding status updates and having the same demanded of you, it’s easy not to understand how different the programmer’s work paradigm is. I’ve been on both sides of it, and now that I spend a good portion of my day doing planning and overhead activities, I have to fight the impulse to drop by the area where my team sits and interrupt them regularly to get a piece of information so that I can put it in some email or add it to a list of resolved issues. PMs, managers, etc. all have real problems, many of which involve attempting to provide timely support to partners, clients, or internal staff, and issues and problems are interruptive, by their very nature.

Well, worry not, because I think I have a way that you can actually demonstrate to them just how devastating interruptions are to your productivity compared to, say, theirs. In other words, here’s how to make someone understand that, for you, an interruption isn’t just a delay after which you can get right back to work but a complete total of your efforts up to that point. Here’s how.

Invite the PM/manager/sales/whatever person to sit at his desk and tell him to humor you. Open up notepad and type a series of 3 or 4 digit numbers in sequence, like so:

123
234
345
543
432
321
999
888
777

Now, tell him to add those numbers in his head. He can look at the screen and talk/whisper/mutter to himself, but he can’t write anything down and he can’t type anything. He may laugh. Tell him that you bet him lunch he can’t get it done in five minutes, only getting one shot at getting the answer right. Maybe he’ll stop laughing and get to work.

Sit down, curl your hands behind your head and give him half a minute or so. Listen to him muttering. Then, get out your cell phone and call his office line. If he ignores it, ask him if he’s planning to answer it, since it could be important. He’ll grunt and mumble something about having to start over.

Give him another 30 seconds or so and say, “So, harder than you thought, huh? Which number are you on? You know which number always gets me? 333. Something about that number. Or maybe it’s 221. Or anything that adds to 9,365. Numbers, amirite! Oh, crap, sorry, you were concentrating. I’ll be quiet.”

Give him a minute. Pull out your phone and start talking loudly to no one on the other end, simulating a call. Start reciting imaginary phone numbers. Look sheepish and apologize.

Give him another minute. Blurt out that you’re low on work today, and ask him if he still wants you to add those three things about the four or five other things to six or seven of the upcoming performance presentation slides, and, oh, geez, numbers again, your bad.

Give him yet another minute. Then tell him that he’s only got 20 seconds left. Or is it 30? Maybe 25. Whatever the case may be, he’s getting into crunch time. Oh well, you guess he failed. Thank him in advance for lunch, but offer to let him keep his lunch money if he promises to stop constantly doing what you just did to him while you’re trying to code, which is a lot like keeping track of numbers all day in your head.

  • gringo

    Good article. That’s what I like, teaching by example. Nothing speaks more clearly to other person than referring to something he knows.

  • http://Typecastexception.com John Atten

    Fantastic. Also, when you take the work home, so that you can focus, there is always the girlfriend to do the same thing . . . but you get in REAL trouble if you try to push back on that one . . . ;-)

  • mikeloux
  • Pingback: Work interrupted | alinacristina.net()

  • Eric Richards

    Absolutely true. A whole day can go off the rails with just a handful of well-timed interuptions

  • NoGF

    Real devs don’t know the existence of a female at home.

  • Pierre Rasmussen

    Totally agree.

    At our company we try to use the chat channel (Lync in this case) so the other person can choose when to answer you. It works ok, but it doesn’t give you 100% shield against interruption :-)

  • jon

    That’s why you have 2 girlfriends. Each thinks that you are with the other and you can go to the office and get some work done!

  • Rebecca

    Some real devs *are* the female at home.

  • Pingback: The True Cost of Interruptions | AccessAdp.com()

  • http://www.daedtech.com/blog Erik Dietrich

    That’s usually the approach I take too, if I want someone’s attention. Or, I’ll walk over to where they sit and actually look to see if they’re staring intently at the screen. I find that it’s pretty easy to tell based on someone’s body language if they prefer not to be interrupted at that moment.

  • http://www.daedtech.com/blog Erik Dietrich

    I like that a lot. That collapsing into a little black hole really makes the graphic, in my opinion.

  • http://verraes.net/ Mathias Verraes

    My trick is to estimate the wages of the programmers in the room, and calculate the total cost of 15 minutes of their time, including taxes etc. I hang a note on the door saying “Opening this door may cost €213.37. Are you sure it’s worth it?” It cut interruptions in half.

  • Brad Rembielak

    After reading that post, I feel validated.

    I have told non-programmers three things: programming is like doing a jigsaw puzzle of an every evolving picture with more pieces than you’ll need (if you’re lucky) where many pieces fit in the same spot and almost look right and it all happens in your head.

    The second thing I tell them is what you said in your post: when it comes to concentration it’s like summing up a long list of three digit numbers in your head and then when you get distracted, you have to start all over.

    The last think I tell them is what we do is not rocket science. Rocket science is easier.

  • Sean Feldman

    This is so true. I compare development to art, you’re in a middle of creation ina a flow, interrupt it and you might never get inspiration or idea back.
    Because of this most developers are productive at night, when distractions are minimal to none.

  • Ogbonnah Kingsley Francis

    very funny really

  • jvs

    Excellent!

  • Pingback: Articles for 2014-jan-20 | Readings for a day()

  • Herbie M

    This neatly accounts for why I can spend a whole day getting nowhere and then, suddenly, when everyone else has gone home, I solve the problem.

  • Russell Allen

    Umm… does no-one else reading this work with unit tests? I don’t dev/tolerate working with code like that described.

    And what if that interruption stops you building/fixing the wrong thing, which I would assume to be a much bigger productivity fail? Sorry, this smacks of ivory towers to me.

  • Pingback: Programmers, Teach Non-Geeks The True Cost Of Interruptions. | InterViewDvd MagaZine Blog()

  • Pingback: Les liens de la semaine – Édition #63 | French Coding()

  • http://www.daedtech.com/blog Erik Dietrich

    For what it’s worth, as the author of the article, not only do I work with unit tests, but I have multi-part instructional post series on the blog about both unit testing and TDD (check the large “Unit Testing” tag in the tag cloud). I have to say that there seems to be a gaping hole in your premise here, as I see it: the existence of legacy code that wasn’t developed using TDD.

    Those situations are the ones in which developers have this problem — not in the case of green field code they just wrote 20 minutes ago using TDD. And, like dark matter, untested legacy code makes up more of the software universe, especially when it comes to generating problems that need debugging, than its well-covered counterpart, and to suggest otherwise smacks of the kind of towers you mention.

  • http://www.daedtech.com/blog Erik Dietrich

    Thanks for the nice feedback, all. I’m glad that you liked the article and found some value and, perhaps gallows humor, in it.

  • mr_echoes

    Multiply this 10 times per hour and you’ll know the kind of hell I’m passing :-(((

  • Guest
  • Krakoģil

    Been there, done that. This sounds just like my previous job where management didn’t want to understand the s***t how programming is done.
    Also, not having testable code (that’s why you must do TDD or BDD) doesn’t help. with tests and testable code it would take 5-15 minutes, not 50 to get debugger at state where bug will come up.

  • Fred

    So, just hit the ‘back’ button to reverse the effects of the Step-Over. ;-)

  • Jim

    Maybe it’s your methods and IDE are letting you down.

  • http://www.daedtech.com/blog Erik Dietrich

    That’s very true. I find that well tested and factored code actually requires very little time in the debugger. Of course, to write well factored and tested code requires its own kind of concentration and envisioning of the architecture that’s also quite sensitive to interruption.

  • http://www.daedtech.com/blog Erik Dietrich

    I think you’re on to something here. Let’s spec out an IDE plugin and make a killing. :)

  • http://www.daedtech.com/blog Erik Dietrich

    No arguments here. The part of this little dramatization that’s probably most common to my situation as a developer historically was the “order food and wait for everyone to leave” part. I’d often get more done from 5 to 7 PM than during the entire day from 9 to 5.

  • Pingback: The Baeldung Weekly Review 3()

  • oising

    Ah, for moments like these, there’s Intellitrace: Accidentally did a Step Over instead of a Step Into? Well, take a deep breath, turn to the aggressor, slap the errant twat firmly in the chops, return to your screen and rewind one step. Oh, what’s that? You don’t develop on Windows? Oh well… back to 1996! (That said, I get your point.)

  • oising

    Already exists in Visual Studio: IntelliTrace.

  • Scott

    As a programmer and an emergency doctor, I can say interruptions are frustrating, annoying, demoralizing and irritating when they happen during programming. That’s nothing compared to what happens when we get distracted in the Emergency Department.

  • yitznewton

    I was reading this thinking along similar lines: a program should be designed in such a way that you don’t have to hold the whole thing in cognition, rather just the component you’re working on, and stitch the parts together. So I was going to add a more blandly-phrased version of Russell’s comment.

    Agreed that working with poorly-designed code that one is inheriting, often does not allow you to work this way; on the other hand, this would definitely be an opportunity one should take to leave the codebase better than s/he found it.

  • Rey d’Tutto

    I LOVE YOU!
    This is Perfect!

  • Dairenn Lombard

    This is nearly impossible to deal with and you just end up having to quote Exceptionally long amounts of time for incredibly short amounts of work. Something that really only takes 3-4 hours of work routinely gets quoted out to 2-3 days because the reality is, that’s 180-240 minutes broken up into 30-60 minute increments that have to stop for interruptions, meetings, lunch, having to leave Exactly at 6 to come get the kids from daycare, etc.

    The one thing I do to limit the amount of chase-back time to re-understand the context of my current work (since I’m a sysadmin quickly turning into a dev-hack thanks to Chef) is have as many things acting as a bookmark as I can. Text files and even e-mails to myself that tell me what I’m doing and for what purpose, what challenges I am trying to overcome, who I need to ask for help during the next regular sync, etc.

    The nice side-effect is that I end up looking like a bad mofo at daily scrums, able to praddle off everything I’m working on in 45 seconds or less, because I basically have to journal what I’m working on or else waste an hour just trying to figure out what I was doing before I was forced to stop.

  • Sebastian

    There is another way. I keep the issues list bang up to date and always send a status email to all stakeholders at close of play. Mysteriously the managers do not interrupt me because they have no need to. If they do then its because something has happened that needs dealing with, urgently.

    However when I act as team lead I expect the same courtesy from my team and that’s when you discover how rude most programmers are. You are not special but only one small part and not that important a one of the solution.

  • Dairenn Lombard

    I do that too, but, you’d be amazed how often people pretty much refuse to read their e-mail, comments in tickets, notes in tasks, etc, etc, etc. And that only deals with one kind of interruption, and the most legitimate kind. It does not address the people with ADD who have to ask you questions right now. Not in an e-mail. Not at the meeting in an hour from now. But right now, in your chat window or telephone.

    The fundamental issue is that how developer’s work is seen is almost completely disconnected to how it actually works. Because if folks did know these things, they would hold questions about anything–whether it’s a status update or new inquiry, or a simple, hey, what’s up, how was your weekend–for the time that they’re away from their keyboard.

  • Dairenn Lombard

    This is perhaps the greatest thought on this topic I’ve read.

  • 4johnny

    Sounds like you could use a good dose of Agile (Scrum in particular)… :-)

  • http://www.daedtech.com/blog Erik Dietrich

    No arguments here at all, though I’d consider the prospective boyscouting to be orthogonal to the issue of interruptions.

  • http://www.daedtech.com/blog Erik Dietrich

    I was thinking of a lower price point than the 12 million per seat or whatever VS Ultimate costs ;)

  • http://www.daedtech.com/blog Erik Dietrich

    I’d view doing the exercise as something Scrummaster would value. What better way to remove interrupting people as impediments than to convince them to stop the interruptions?

  • http://www.daedtech.com/blog Erik Dietrich

    I think optimizing for recovery time from interruptions is probably common in shops with lots of interruptions. It’s the only way to retain some productivity. The defensive estimate sand-bagging approach is a decent way to get buy-in, but it’s a little abstract.

    I once made a spreadsheet that detailed my work in hourly-ish increments and factored in 15 minutes of burn time for “context switching” when I was asked to stop on project 1 and start on project 2. In this fashion I approximated, over the course of some months, what excessive “task thrashing” was costing the business in terms of my cost as a resource (in other words, I was wasting something like 20 or 30 or whatever percent of my days with this when doing a lot of switching back and forth). This was actually pretty effective — when I showed my manager at the time, he made a concerted effort to structure our work to allow larger blocks of time for each thing we were doing.

  • http://www.daedtech.com/blog Erik Dietrich

    Glad if you enjoyed, and even gladder if you get some use out of the analogy in your day-to-day interactions.

  • oising

    Hah, sure, but you get what you pay for, right?

  • Manuel

    I’ll just drag-and-drop the debugger position indicator two lines back up in my Delphi IDE *duck and cover*

  • jiml

    Your manager is either mildly autistic or insecure, if he cannot pickup on how deeply you are concentrating.

  • Javier Rivera

    Yeah, and for those females the same rule may apply with their husbands. So we’re back to square 1. :/

  • Javier Rivera

    This man is smart. He deserves the cookie.

  • Uncle Mikey

    I solve that problem by not working after hours unless *I*’m the reason I’m behind on something. If I fall behind on something because someone interrupted me? Guess it’s going to be late. Too bad. So sad.

  • GonzoI

    I’ve always preferred the “Mental House of Cards” metaphor to this adding metaphor. A calculator can add, and you can write your work down, and the manager knows that. You’re artificially creating a problem to make your example work, and that always makes people doubt the validity of what you’re trying to prove.

    This is an old problem, inherent to anyone exclusively using their brainpower to solve a problem. I work for someone who pops in to intentionally disrupt for his own amusement.

    I will say, though, that starting over stepping through for 50 minutes is excessive. You can set breakpoints behind you as you eliminate blocks of code until you find where you need to be. You still have to get your head back into the problem, but you’re not stepping through an entire program all over again.

  • Pingback: Agile | Scrum | Pearltrees()

  • Timothy Boyce

    Where I work people have the habit of coming over to your desk if you don’t answer in two minutes. There is also no way to permanently disable the taskbar blinking in Lync, which is almost as bad as being interrupted.

  • Pingback: 程序员,告诉他们被打断的真实代价 | 我爱互联网()

  • Pingback: Interesting Links #3 | James Snape()

  • SnarkKnight

    “He can look at the screen and talk/whisper/mutter to himself, but he can’t write anything down and he can’t type anything.”

    That’s your problem. Don’t blame others, use shorthand to keep track of where you are in your head.

    Problem solved. If you can write down 8xZ204330Kd, you can probably write down the reason why as well.

  • http://barlians.com David Bruchmann

    yes, the comic can serve as explanation for customers too whats happening in your had about “simple” requests sometimes

  • Pingback: Il Costo delle Distrazioni.. @TelelavoroBlog()

  • Pingback: So you can’t find good developers … | Andrei's web corner()

  • scollege

    Kudos, great article. I would love to run your demo on others at work, but they would never sit still for it. They commiserate but don’t change a thing.

  • http://www.daedtech.com/blog Erik Dietrich

    They might sit still for it if you tell them that winning the game means you buy lunch :)

  • jsmunroe

    I’d attack that list of numbers like a programmer. I’d see that the first six numbers are symmetrical. And so 123 + 321 = 444, 234 + 432 = 666, and 345 + 543 = 888. I would then realize that the problem can be simplified to (4 + 6 + 8 + 9 + 8 + 7) * 111 or 42 * 111 which is 4 (2+4) (2+4) 2 or 4662.