This is quite a popular cartoon. I posted this in a comment on why programmers wear headphones a year ago, and it has received 63 ❤s.
But I think we like this idea because it makes us feel special, and I don't believe we're as special as we think we are. A talk I found on YouTube some time ago has convinced me that a lot of interruption aversion we feel is caused by not breaking our work into small enough chunks.
This in turn is caused by not understanding the scope of what we're doing. Very often we just dig in, thinking it'll be a small change. An hour later we're left with 10 uncommitted files with changes all over the project.
I'm not denying that you have to keep a lot in your head when programming. A change in one place does have effects on other parts of the system, requiring a fairly complex mental model. But I do think that you can improve your resilience to interruptions if you:
- Come up with a solution to a problem before you start writing code, and think about which parts of the system that solution will impact.
- Divide the solution you came up with into small chunks, so you can take them one at a time.
This is currently a "Do as I say, not as I do" story. It's something I'm trying to improve on, but with time, we can get there.
If you want to hear a much better explanation than I just gave, check out the YouTube video I mentioned:
Was this as convincing to you as it was to me? Are there other ways we can be more resilient to interruptions?
Top comments (44)
I disagree. Well, sort of.
I studied physics in college and did enough research to publish and present a paper. When I was doing physics, I remember there being some moments where I was on the cusp of some great realization that helped me solve a problem, and I didn't want to be interrupted at that point. But most of the time it wasn't like that. My work was always written down and I could deal with an interruption and come back to it with only slight irritation.
When I started programming, literally the most interesting thing I noticed was how many things I had to keep in my mind at the same time in order to do anything with the code. It felt mostly like a new skill to me. It felt like trying to carry too many clothes without a laundry basket. Things kept falling and I had to pick them up again and again.
You're correct for a lot of the things that programmers do. But when it comes to debugging and editing existing code, I've never come across anything that requires keeping so much in the mind at a time. It's not as difficult in general as physics, but it requires a lot more focus for longer stretches of time before something useful can happen.
"It felt like trying to carry too many clothes without a laundry basket. Things kept falling and I had to pick them up again and again."
THAT.
I know that feeling. When I write code my goal is for the code to rqeuire as little time and mental effort as possible in order to understand it. Tough I assume most programmers would say the same, I think we often accept code that is much more complicated than it needs to be.
Complexity does of course also depend on the problem you are solving with the code, but still.
You list part of the solution to making distractions less impactful as “Come up with a solution to a problem before you start writing code, and think about which parts of the system that solution will impact.”, but.. this is exactly the part that is most impacted by distractions for me! Actually coding a solution is almost trivial, coming up with it in the first place is the hard part and the part that is most sensitive to distraction.
Couldn't have put it better :)
Sometimes I have to code something to verify that a solution is possible. These times, just code and hope it works is cheaper than list out several solutions in the first place.
So even coming with the solution before coding isn't feasible.
I don’t agree that programmers are worse in this issue. This disruption issue happens in sales, analysis, design, writing, and many others (not only in knowledge workers) imagine being interrupted while pouring hot iron into a mold.
"imagine being interrupted while pouring hot iron into a mold."
Yeah, I imagine that it is easier to go and start talking to someone who is using a computer than to someone dealing with hot iron. I think this is the case
I doubt it's that simple, and I'll relate a real-life example.
I'm digging into a bug that was filed the past week, trying to figure out what went wrong and fixing it for the next sprint. Out of the blue, one of my support team members comes up and says "Hey Red, the board's showing the monitoring system's down."
I'm the monitoring system expert. I HAVE to stop, switch gears, diagnose the problem, fix it, or get someone on the phone to do the same.
I'm left with two to four hours eaten out of my day every time, and I CAN NOT do anything to prepare for the "recovery of what I was doing" because when I'm interrupted for such an event, it's the equivalent of "OMG everything is on FIRE!!!!" and I don't have time to even write stuff down so I can quickly resume what I was doing.
And in this case, the original problem I was diagnosing I don't have a solution for, because I'm still trying to find the problem when I get interrupted.
If there was a more extreme version of the comic, I would relate to it, because right now, as I'm writing this, I'm finishing up a project that I should of had done two days go... were it not for the fact that the above happened this week, in addition to glasses breaking and having get an eye exam to get those replaced.
Sorry to have to say it, but this is bullshit. The problem of dividing a problem is in software, often almost as complex as the original problem! You can see the problem with teams applying the agile process, implementing user stories, and keeping accumulating technical debt. Yes, users or product managers have it easy dividing their specifications in "user stories", but software is not architectured following those lines.
I agree that software from a user-facing model is not divided up the same way as its internal structure, but at some point, you have to think about how a user story maps onto the structure of your software, and I think it can be valuable to think about this ahead of time rather than seeing what needs to happen while you're writing the code.
Not advocating for a waterfall model here, but I sometimes wonder whether we've thrown out the baby with the bath water by ditching all up-front design.
Ditching all up-front design is dumb. Not sure where you're getting that from.
Thank you for saying this! I'm a full-time homeschooling parent who is also a full-time coder/manager. If distraction hit us harder than average, I would be 0% productive. And yet... I ship apps all the time.
The trick, as you say, is breaking work into small chunks. If you have to keep too much in your head, it's because you're biting off too much work at once. It's the mental equivalent of writing a 100-line method - break it into subroutines!
Also, context-switching is a skill that can be developed. We are not beholden to some sort of biological imperative to always do only one job at a time.
But I think we like this idea because it makes us feel special, and I don't believe we're as special as we think we are.
That's spot on. I've been guilty of it. The whole "I shall not be interrupted for I am doing something very important, and my job requires more concentration than yours" thing...
But I also feel that there is a significant amount of 'load-up' we must do when we jump into our work, and having to reload that into our brains after an interruption costs money. Our time isn't free, so it's up to us to set this expectation with our co-workers, because it's our responsibility to be fiscally responsible for our companies/organizations.
So I try to set this expectation: You're bringing me a 'house on fire' bug. That means automatically I am going to stop what I'm doing, unload this work from my brain, and dive headlong into this so-called bug you're screaming about. But only if you can prove to me that you went through the necessary steps to understand if this really is a potential bug, or if it's something you did wrong on the back end, or if it's user error from one of our external users. Because you've been through this a number of times and probably actually know the answer.
Most people I know who complain about being interrupted (myself included) don’t think we shouldn’t be interrupted because our jobs are more important than others, we don’t even say we shouldn’t be interrupted at all, just that unnecessary distractions (eg noise from open plan offices) should be removed as much as possible and that interruptions should be minimized to those that are important. Its ultimately up to the other person to decide how badly they need a response right now vs sending an asyncronous request (eg email or text chat) and getting a response later. If they need it now to do their job, then interrupt away, but be mindful of the fact that it will be detrimental to whatever I’m working on (and cause frustration). Sometimes its worth it, but many times the request really isn’t urgent. We’re arguing that everyone needs to be aware of the cost so that we’re not interrupted for things that either could wait or that could really have been solved without us (ie yes it might save you ten minutes of work to interrupt us, but is that saving worth the cost of interruption? if I was working on something complex, it often costs me much more than ten minutes to get back to where I was) I know that obviously the sales guy may not know what I’m working on and making a determination on the cost will be hard, so I’m not asking for an accurate appraisal of cost/benefit, just some mindfulness and a quick thought of “do I really need it right now? can I figure it out myself within the next ten minutes?” and if they still need to interrupt me after that, then ok, do it.
To me, the “not that special” part of the article doesn’t mean its ok to interrupt us, it means its not ok to interrupt others too. That is, interrupting the accountant, sles, marketting, whatever people is detrimental to their jobs too and should be minimized. It doesn’t mean “interruptions are detrimental to everyone, so its ok to interrupt everyone no matter what job they’re doing”.
I've never had this issue, as I write everything down first. Whenever I am about to start work on a new function or feature, the very first thing I do is design it. I write down the logic with pen and paper. I rewrite it into pseudo-code and comment blocks in the newly created script files where it'll go. Only then I start coding. At that point, the code itself takes barely a few minutes to complete, and no interruption in the world would break my focus at any point due to everything being written down. My sister on the other hand loses her mind if she had the slightest bit of an interruption and that cartoon is putting it mildly. Even though I'm infamous for being a "one-track mind" with my work. Like many others have already said and I'll say it again, write everything down.
I think that at some point you make a good point, because truly the interruption comes at a high cost when you are processing a lot of information that is "on the air", like the cartoon clearly shows.
The fact is, is it avoidable in all cases? Maybe.
Some idea I have never got to expand is that it would be good to have a solid "problem analysis" tool that allow you to keep track of the ideas, relations and assumptions you make when you are thinking about a complex problem.
Something like a mind reader and clarificator software!
I think this premise is wrong. I haven't met any developers who think we are the only ones who suffer from interruptions. There are many lines of work that can suffer from them, some more than others. While your suggestions are good and should be used (not hacking code without some thought, breaking down a problem), I don't think that is a magic bullet for this issue. The planning is the part that is ripe for interruptions, coding once you have a plan should be trivial.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.