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?”
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.
No Fields Found.
Good article. That’s what I like, teaching by example. Nothing speaks more clearly to other person than referring to something he knows.
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 . . . 😉
Real devs don’t know the existence of a female at home.
Some real devs *are* the female at home.
Yeah, and for those females the same rule may apply with their husbands. So we’re back to square 1. :/
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!
This man is smart. He deserves the cookie.
Story of my damn life >:(
NICE. Makes me think of this comic: http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer
I like that a lot. That collapsing into a little black hole really makes the graphic, in my opinion.
yes, the comic can serve as explanation for customers too whats happening in your had about “simple” requests sometimes
[…] https://daedtech.com/programmers-teach-non-geeks-the-true-cost-of-interruptions […]
Absolutely true. A whole day can go off the rails with just a handful of well-timed interuptions
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 🙂
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.
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.
The number of people think sending me a Lync/Slack is an excuse to walk over to my desk 3 seconds later to ask “If I’ve seen that message [they just sent]” is staggering. I usually just answer “did you get my response?” And when they invariably say “no”, I say “So, what conclusion do you draw from that? I’ll respond when I’m ready.”
[…] https://daedtech.com/programmers-teach-non-geeks-the-true-cost-of-interruptions […]
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.
This is perhaps the greatest thought on this topic I’ve read.
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… Read more »
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.
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.
very funny really
Excellent!
[…] Programmers teach non geeks the cost of interruptions […]
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.
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.
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… Read more »
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.
No arguments here at all, though I’d consider the prospective boyscouting to be orthogonal to the issue of interruptions.
[…] the rest of the article, in the link below. https://daedtech.com/programmers-teach-non-geeks-the-true-cost-of-interruptions // < ![CDATA[ google_ad_client = "ca-pub-3875356300053748"; /* G0001 */ google_ad_slot = […]
[…] Une astuce intéressante pour faire comprendre aux non-programmeurs le coût des interruptions de tr…. […]
Thanks for the nice feedback, all. I’m glad that you liked the article and found some value and, perhaps gallows humor, in it.
Multiply this 10 times per hour and you’ll know the kind of hell I’m passing :-(((
http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer
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.
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.
So, just hit the ‘back’ button to reverse the effects of the Step-Over. 😉
I think you’re on to something here. Let’s spec out an IDE plugin and make a killing. 🙂
Already exists in Visual Studio: IntelliTrace.
I was thinking of a lower price point than the 12 million per seat or whatever VS Ultimate costs 😉
Hah, sure, but you get what you pay for, right?
I’ll just drag-and-drop the debugger position indicator two lines back up in my Delphi IDE *duck and cover*
Maybe it’s your methods and IDE are letting you down.
[…] => Programmers, Teach Non-Geeks The True Cost of Interruptions […]
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.)
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.
I LOVE YOU!
This is Perfect!
Glad if you enjoyed, and even gladder if you get some use out of the analogy in your day-to-day interactions.
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… Read more »
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.
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… Read more »
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… Read more »
Sounds like you could use a good dose of Agile (Scrum in particular)… 🙂
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?
Your manager is either mildly autistic or insecure, if he cannot pickup on how deeply you are concentrating.
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.
This. I just turned down a job in an office where they have Slack messages and constant interruptions all day for no good reason. I worked there for a week on a trial basis. I noticed at the end of that week the MD was contacting devs on Slack at 21:45 on a Sunday evening, trying to find someone to fix an inevitable screwup that only happened because another developer couldn’t concentrate 9 to 5 Monday to Friday. Erm, no. Next week, how about you turn off the music in the office, stop trying to have 15 noisy conversations in… Read more »
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… Read more »
[…] Programmers, Teach Non-Geeks The True Cost of Interruptions | DaedTech […]
[…] ← → 英文原文:Programmers, Teach Non-Geeks The True Cost of Interruptions […]
[…] Programmers, Teach Non-Geeks The True Cost of Interruptions – a simple way to show to your boss how drive-by-management kills programmer productivity. Also work reading Maker’s Schedule, Manager’s Schedule which highlights the differences. If this is still a problem then this notice might be your only solution… […]
“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.
[…] Per comprendere al meglio come funziona il lavoro del programmatore paragonato a quelli dei suoi vicini (venditori e manager) l’autore suggerisce – e io non posso che condividere, sghignazzando per quanto è vero.. – di leggere: “Programmers, Teach Non-Geeks The True Cost of Interruptions“. […]
[…] into the true cost of interruptions for developers. I suggest you start by reading this excellent article on the […]
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.
They might sit still for it if you tell them that winning the game means you buy lunch 🙂
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.
This is why I start work at 6:30 am. I get an hour and a half of good, solid work in for the day. I can’t work late to get a break because our clients are on different time zones.
I’ve been in that boat before, myself. Start early, work late, work offsite… you always wind up carving out a time and place to get serious work done.
Recently a junior programmer left a project I was working on, because after he breached our agreement that technical interruptions should occur only in the case of urgencies, I have asked him about the nature of urgency and when he changed his tone to very unfriendly with a sentence starting with “Oh my God” I explained him why is a problem to interrupt the other. I did not use any ill terms, yet, the project owner blames me for the hysteria of the junior. This lowered my motivation drastically.
Yeah nothing says “I don’t even understand what my subordinates do” more strongly than the manager that routinely has loud/obnoxious conversations within proximity of his/her devs’ working spaces.
It seems like I see less and less of that as time goes by, but then again, I also probably have fewer chances to see it.
PMsStakeholders are not the only problem. SlackTwitterRSS ReaderSocial Media is big distraction to productivity today. The only solution is switch it off, it’s the only way I can ever get some work done.
No doubt about it. When I work these days, I close pretty much all browser windows and set my phone to Do Not Disturb. I also usually deal with email only once a day or so, around lunch time. All of that has helped me a lot.
The fundamental problem with your approach is that it makes the incorrect assumption that these people don’t know they’re being assoles. Trust me, they do. They just don’t care. What they do care about is projects not being delivered on time. So I do that instead. And when they (or their boss) ask me why it’s late, I tell them. Funny how much more effective it is.