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?
Oldest comments (44)
Spot on Frederik. We all need deep work. I'd say the "maker vs manager schedule" idea is accurate but can apply to lots of kinds of work.
Good article
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!
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.
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 :)
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
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.
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.
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.
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.
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.
"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'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.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.