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 thin...
For further actions, you may consider blocking this person and/or reporting abuse
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 :)
I think it is true for other knowledge workers, however; I think a great deal of people think it is no big deal to interrupt someone who is programming. I used to work in a division with a boss who said to walk to people's desks to ask questions. This meant 10 interruptions every single day. It was maddening, even when I planned out my changes.
Actually all interruptions cause disruption, but, as the cartoon shows, what happens to programmers is that they carry a lot of information in their short-term memory when analyzing a problem. The more information you are carrying in your short-term memory, the more difficult is going to recover from an interruption. So, yes, you could do sales, writing, analysis or many other things, but I think that for programmers or people doing math, chemistry or similar things is going to be worse than for a person writing a paragraph of literature, for example. Unless they overloaded their short term memory with a lot of information.
Thanks for posting this, I think it's an important conversation to have.
On the one hand, I would echo what Daniel said: context-switching is a skill that can be developed. Anyone who is caregiver has had to learn this. No one likes it. It is exhausting. But we can get better at reducing its costs through practice. And I strongly agree with when the speaker in the video says that (some) interruptions are opportunities for empathy and collaboration. They can even be great time-savers, preventing you from going down some rabbit hole because you didn't quite understand some requirement, meaning an entire feature you had cooked up in your head is actually unnecessary or doesn't need to be prioritized.
The influence of Flow, or at least how it has been promoted and applied within the tech industry, has been a step in the wrong direction in my view. It's fed into a very self-indulgent and unrealistic view of what programming is. This view puts the legitimate interests of developers in autonomy over how projects are implemented in conflict with the rest of the team and in conflict with the interests of users. In addition, it accepts the current messed-up state of affairs as inevitable.
Which brings me to a second point. This basic problem of having to keep too much in your head has rarely been prioritized in the development of the tools we use. As we age, as programmers this becomes more and more important, yet decades-old innovations in this area such as Hindley-Milner type system algorithms and enforced pure functions over immutable state are still not mainstream. Why are we still suffering with imperative languages - in domains which are not memory- and processor- constrained? It's an astonishing contradiction of the tech industry that it appears to change so quickly from the outside yet is moved forward internally by languages and tools that are essentially 50 years old or older. It's hard not to see this as an effect of the industry focused on developing on a younger (and cheaper) workforce, where the priority is less "lessening the need to keep a lot in your head" and more "lowering barriers to proficiency".
My third point is, I don't totally agree with the solution of "just break down the work into smaller chunks". Yes, when we have the freedom and time to do that, and to push back on deadlines on the basis of such an analysis. The key thing is having that autonomy, and establishing that is a question of political strategy in a particular case. I don't think there are easy solutions in general, though I really appreciate the lessons from experience that are outlined in that RubyConf video.
Thanks again for posting!
I dont really see that his talk addresses his stated problem. It more a recap/revision of something McConnel might wright today... here is how to not be horrible at software development.
Im not sure how to avoid distractions... I know this...
Act like an adult and dont pout when you get distracted. You aren't that important.
Write comments, distracted or not, you wont remember what you were thinking when you look at this in 2 weeks.. or 2 years.
When you get distracted, listen and be present. They may be trying to tell you something that is more important than what you were doing before 'they' approached you.
And yes, if its time for heads down deep think, go find a quiet place, or quiet time. Most the people you work with are well aware that distractions can impact performance... they experience it too. Put a sign up that says 'PLEASE TREAT MY DOOR AS CLOSED'. It works wonders.
I do believe it's somewhat worse for programmers than for other knowledge workers, because programming is a task that's incompatible with errors and approximation.
I also believe, as you do, that programmers can becomr much more resilient to interruptions with one simple trick: when working on something complex, male a plan and WRITE IT DOWN. The vast majority of programmers don't do nearly enough of this.
Exactly! Plan and write! Pen and paper are your friends.
I honestly feel like its a personality and specific problem thing. My wife does a q/a project manager type role and she absolutely hates being interrupted as she has to carefully review and follow a person on screen for part of her job and the other part is walking through processes in her head and figuring who does what and where. She is not in a tech or programming role in the slightest and believes html = hotmail. She deals with it but often feels that a more interrupted day was fruitless because she wasn't able to finish or walk through her tasks and plans for the day.
When I was a call center supervisor It was extremely common for me too be talking to a customer about an issue, answering 1-2 team members question at once (Mute rocks) and fixing a 2nd customers problem all at the same time. I was really really good at this multitasking (partly due to my ADHD and the advantage it gives me in very high stress situations,dopamine ftw). It was so routine that it was almost laughable how many things i could handle at once.
Now that i'm doing development i'm the opposite, its really frustrating when i'm interrupted because i'm trying to walk through code or learn something complex and i have to focus really hard on things to keep everything in place in my head. I think it just depends on a persons personality, the job, what exactly is being done and the atmosphere.
I also have realized that the better i get at a concept the easier it is to bounce back and forth with minimal consequence.
I think the solution is to focus more on trusting people to do what they need to do while coaching and training them to stretch in their weak areas. Over time I see people interact with others more, be more responsible and choose isolation/collaboration when its appropriate because they have the freedom to do so and the education and buy in of the value of both systems.
yes i do think you can mitigate it somewhat. but i wonder if it is also somewhat about engineer style of thinking.
for example when i’m having a conversation with a friend, let’s say i am telling a story. now interruptions are fairly normal but they drive me up wall. often i lose my thread & the train of thought. then i get mad at the person like they don’t care about what i have to say.
but they do. and conversational interruptions are quite normal. but i struggle with them.
I believe interruptions are worse for every employee. For example: If someone interrupts me while I am writing a blog, it takes me hours to focus again.
Same is the case with designers, analysts, sales representatives. A momentary interruption can cost the whole project.
In short, the only person who will not mind being interrupted is the one who is free and don't have any work to do.
Regardless of whether developers are holding a large solution in their minds or they are thinking deeply about how to implement a small feature, the reality is that interruptions cause them to lose their train of thought and it takes a long time to get back to where they were. We built pomodus.com/ with planning, focus and reducing interruptions in mind. Please try it (there's a free plan). If you have feedback or feature requests, please let us know. I hope that this is helpful.
There is a great book which covers the issue in depth - Peopleware. I would recommend every developer or a manager to read it. Interruptions pretty much kill the productivity.
Just topple open office and that's it.
I like this hypothesis. That might be because it makes me feel special, though. I mean, I can handle interruptions pretty well most of the time, so I must be doing things "the right way", right?
I've been explaining non-devs that our concentration is like that of a
house of cards.The comic strip explains it pretty well, as well 👍
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
Slicing and reducing complexity is always a good thing. :) The type of interruption is also important. Here is my take on the subject: medium.com/@thorbjorn.sigberg/out-...