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.
I'am sure the problem exist for everybody. This is finally a context switch a bit like our CPUs.
Part of the problem may be purelly that you lost some information you need to acquire again, true. But the brain is now focussed on the interruption and may take some time to just not think of it anymore.
As to split a problem into small tasks, this is important and help but is itself a complex task... And you may as well forget what the tasks where if you are interrupted. You can write down things but then you make you brain slow down, to work a speed of writing/reading instead of its own naive speed.
As for headphones, if you play music and not just cancel the noise, it decrease concentration. It has been proved that pure silence is better than music and it seems logical. A part of you concentrate on the music. It is an interruption by itself. How I remember that one that our prefered music with my girlfriend or simply, hey I like it or no, I'll go to next track.
It is sure that being organized to live with interruptions if you cannot avoid them greatly improve your productivity. There many tricks. People for example switch to tasks that do not require much concentration at hours when they are most likely to be interrupted or between 2 meetings. Some people would just say to go back to them later and stay focussed. You can also concentrate on reading mail/chats conversations and all at certains hours/time (like every hours or when you have a slow compilation blocking you).
I also simply know many people that when they know they need to have max concentration go to a meeting room where they are alone, put their chat status on do not disturb and so can be concentrated on the task for a long time and make significant progress.
Yes, thanks for the post, I agree with your argument. Not always, but very often, you can reduce the scope of your mental model to small chunks, write one at a time and unit test them and you will need less focus while you are working.
I use to relate to the comic strip but I don't find myself in this situation so often since I use more pure functions and unit tests. Besides, simply by working on the chunks (functions) you give yourself time to think about the problem.
When I try to think about the big picture, like about how my API will work with other parts of the system or how to improve the architecture of a project, I have found that diagrams and explaining the system in words (maybe a description of the system in layman words or just write down my thoughts about the problem in bullet points) helps a lot too to come back to the problem after lunch or any distraction.
Do you preer a physical paper or whiteboard, or do you use diagramming software?
For me: Always something physical, so paper (blank without any lines or whatever) or whiteboard. Diagramming software is clunky and slow compared to a pencil, and will block your natural flow of thoughts.
If I am trying to understand something pen and paper, because it is fast and it helps me think. If I am trying to create something for long term reference or I know that I might come back to the diagram in a couple of days and modify it because is something still evolving I try to do it digital.
Dia is fast and allows you to group, link and move things easily. I have tried ArgoUML but I don't really like UML and I just want the diagrams as a mind-map, not to generate code, so it looks overkill to me. I have also tried inskape but don't know the short-keys and I am slower.
Summing up: use whatever works for you, but I find that writing things down in whatever medium helps, you can not keep everything in your head and offloading to paper or just a bullet point list helps a lot to come back to the problem the next day or after some time.
I'm a sysadmin who someone decided awhile ago to promote to enterprise architect. While I'd worked with a lot of dev projects in the past, and had my own experience with programming on the ops side, I really don't think that a lot of software dev projects lend themselves into being broken into smaller chunks. In fact, that approach is often doomed to result in all kinds of continuity problems. Managers really like sprints because it gives them something to take up the chain in the face of the "what have you done for me today" philosophy carried over from sales. How might the Manhatten Project gone if they'd run it that way ("We almost lost Chicago")? No, I like the idea of establishing office hours that was described in one of the linked articles. How that gets enforced in reality is beyond me though, especially when some people seem to think the problem is individual contributors' time management skills.
I started out in office support but at the same time doing loads of coding before I moved exclusively into development. So I was constantly interrupted about inane things (e.g. A4 Load Letter!). I developed the skills to work in busy environments, a number are mentioned in the comments.
Take note of the forced interruption - take a damn break! It's plain unhealthy to get so into something like that at your desk. If you go for a walk, you're less likely to be disturbed if you need to do some thought work! What about your whiteboard? Well I work a lot with remote people/teams where whiteboards are usually impractical, so it's possible to survive without the high from the pens!
Reading previous comments, I have 2 bugbears to raise...
1) Don't blame Agile. It's only there to help keep you developing things that are relevant. If there's something wrong with your processes, change them! That's what retro's are for! Sounds like everyone's main complaint is "I spend ages diving down rabbit holes of complexity because we never fix tech debt" - does your business really think that's a healthy situation in which to work?
2) Headphones.. if used properly are great ways to work, and I'm sure some people may work better with them. But they are also misused quite frequently. When I've heard trainees upset and crying because they can't get the help they need because their assigned senior is always plugged in and is unapproachable... you gits! I've also observed great amounts of sloppy working from headphoners too, like the ones who never seem to use the right processes, who create enormous PR's so complicated that they're un-reviewable, who end up getting sacked because they're unmanageable and unproductive from the business' point of view, etc.
I would also say that if you are one of those works with their headphones on, beware! The new generation will kick your butts with their collaborative working skills. Which, I might say, generally produce things far better than the lone wolf developer. If you are paired with someone and you get interrupted, chances are you'll pick up the trail a lot quicker.
Great piece! Being in a position that I can say something about this issue, I think that even if you design and architect the solution before coding, the bits, pieces, bolts and straight up duct tape to make it work is a focus-oriented task. Interruptions should be minimized.
A proper architecture, that is obvious and simple to all parties in a company/team (PMs, devs, devops, testers, content), makes it easier to re-focus, though.
Several issues in projects I worked on came from the fact that the business architecture never got reflected in the technology. If you are working on a business-first case, grill your PM, do small drafts, do delivery dates on small issues, keep track of the development and, last but not least, explain what is necessary in terms of time and manpower to deliver a solution.
I'm also guilty of "coding away", so to speak - tinkering requires focus. That is why my personal solution to the interruptions and constant iterating over business ideas is drawing stuff down and coding until another meeting. Those are not standups or briefs - since I do remote, so it's in both mine and my client's best interest to not waste our mutual time talking about the weather. I usually schedule an hour meeting for about two to three weeks of development.
Thus, TLDR;
That should let you get back on track easily whenever unwanted human interaction happens :)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.