I write down my thoughts so if I get interrupted I can resume from where I was.
Then, I try to encourage people I deal with to use the issue tracker as much as possible.
The only thing worse than keeping JIRA constantly up to date is keeping interrupting managers up to date when I already keep JIRA constantly up to date with the thing they're asking about. It gets amusing when I'm deep down enough into the technical weeds that I've forgotten the exact high level task I'm working on (the thing the manager actually cares about), and refer to JIRA myself to answer the question of what I'm working on.
Some days I can barely even get started working, because I am already anticipating interruption.
Wearing headphones doesn't help. I think it should be a clear social signal, but other people do not. In fact, they talk to me as if I can hear them (I cannot) and have to repeat whatever their introduction sentence was when I finally take them off.
Why is this normal?
One way to do this would be to buy (e.g) a bunch of white caps and tell your coworkers to wear them when they need to concentrate, and to not disturb others when they are wearing them. I know of at least one company that does this and it works well for them. You can also do this with headphones, just tell your coworkers politely.
This phenomenon is not constrained to programming. It's sometimes referred to as flow[0] and has been documented as taking somewhere between 15 and 20 minutes[1] to regain after an interruption.
Programmers may be more sensitized to its disruption than most due to the nature of the work, but the net effect is the same. If a person is required to concentrate in order to perform their job, interruptions will cause performance to degrade.
The article makes some good points, and nobody likes constant interruptions and context switching. Especially in particularly complex parts of the coding process. I also agree that it often takes ~10 minutes after a significant distraction to get back into things.
I think non-programmers could definitely benefit from this article. But I also think it's a two way street and there are certain steps you can take to minimize the damage done. Some things I at least try to do:
- This may not go over well at everyone's companies, but just being honest with your coworkers sometimes. Send a message or email indicating you need to put your head down for a while to address priority tasks, and that you'll be logging out of Slack/IRC/whatever and can be contacted by email if anything urgent comes up. A healthy work environment should allow for it.
- If headphones on is a 'signal' to others not to bother you, just politely mention it to them if they keep interrupting you during. Invite them to email you with any non-critical issues and you'll get back to them when your higher priority work is done.
- Getting knocked out of the "zone" and it taking 15 minutes to get back... this definitely happens. But most meetings are scheduled. If your coworkers know your signal not to be bothered unless it's important, you can then work around the scheduled meetings. Do the less complicated coding tasks if possible leading up to the meeting so you don't need so long to get back in the zone after. If that isn't happening, at least keep a text editor open and jot down some notes to remind you of where your thought process was. A checklist is even better.
- Use bookmarks. A lot of editors / IDEs have them, and if you bookmark all the areas of interest, if you do actually have come back and 'get back in the zone' without notes, you can at least hop around the pertinent areas quickly to regain context.
Anyway, just some thoughts on what's helped me at least reduce that issue. I'm not sure it can completely go away.
While interruptions are bad for your own productivity, they may really boost the productivity of the person doing the interrupting. I'd rather have a junior dev interrupt me when he needs a quick answer to a question instead of spending an hour googling and copy-pasting a dangerous hack from Stack Overflow. What's the point of sitting in an office when you don't collaborate?
The trick I use to reduce the effect of interruptions is to not respond right away if I'm in the middle of something. I just say "I'm in the middle of something, let me just finish this!" and then I get back once I'm at a point where my "mental load" is reduced.
I see so much of this arguing against being interrupted, or context switching. I suffer from it, most of us do, but I think everyone's trying to solve the wrong problem.
The problem isn't that we get interrupted and our concentration suffers, it's that we keep trying not to be interrupted. Good developers are people who knit things together. The myth of the savant coder who just cranks out beautiful amazing stuff has to die. What makes a great developer are soft skills, and gluing together other code, not cranking on something for hours alone. Just like every other industry, you have to deal with other human beings, email, and the rest of life. We don't NEED to be cranking out code for hours on end, we need to integrate and interact with other people.
The problem isn't that we get interrupted and
our concentration suffers, it's that we keep
trying not to be interrupted.
For a programmer, frequent interruptions are a major problem. Interruptions break a person out of the mindset required in order to solve problems. This is why managing interactions within an organization is one of the primary foci of project management.
What makes a great developer are soft skills,
and gluing together other code, not cranking
on something for hours alone.
Soft skills are certainly beneficial in a team. But what "makes a great developer" are not soft skills. What makes a great developer is providing solutions within the constraints and expectations of the organization (time, functionality, cost, etc.) for the problem at hand.
I think there is a time and a place for both modes (and it also depends on personality). What's wrong with private exploration / development after a period of research on the problem?
It depends, of course, and I assume you're not drawing a black and white line, but I agree.
For many years in my professional career, I was getting annoyed at interruptions and complaining. I've done intentionally anti-social things to prevent getting interrupted. (They rarely, if ever, actually worked.)
But I also watch programmers (including myself) code like crazy and resist interruptions solving problems they don't actually have, and if they'd stop to check in, they'd find out the cost of the context switch is trivial compared to the cost of losing hours, days, or even weeks to coding the wrong thing.
As programmers, we'd do well to learn how to be the ones doing the interrupting rather than wait till it comes at us and then complain about it. Seek out more consensus on what we're coding before we start typing away, plan for changes in requirements before building things that can't easily change, report our status to managers often and before they come asking, establish conventions and willingly work with others, etc.
It's noteworthy that (fiction) writing hasn't gone down the "collaboration is part of the job"/"don't trust the coder hacking away by herself" wormhole that seems to be swallowing the software world at the moment.
This is something I definitely agree with. I've sometimes found that taking a few seconds to cache state in a notepad before responding to the interruption helps a lot. Having times of day dedicated to meetings also helps reduce fragmentation. At the risk of being overly self-promoting, solving problems with fragmented work days is something my cofounder and I are working on now with TimeFerret (https://www.timeferret.com).
This might be somewhat off-topic but do we really always have to conduct a study first before we can acknowledge and solve a problem that is obvious if you have any common sense?
I agree with that notion completely, but I think one can overdo it and get lost in pedantry and bureaucracy. Imagine you would program your software and do a benchmark test on every single line. That is what it feels like.
I've always liked the warning to not let perfect be the enemy of good. But I also think it's easy to rationalize too much guessing and too little evidence gathering. I find it a really hard balance to strike.
So introspection is replaced by studies that mostly focus on a single aspect of a complex system, analyzed by people who don't know MANOVA and just do p-value fishing in Excel.
Let's say the ratio is worse: 10x less productive; 10x more error prone.
I will still interrupt my coworkers who are working on the wrong thing. 1/10th of a thing that makes 100x more money is better than 1x of a thing. I want that nonsense flushed from their working memory.
I understand that makes me a micro-manager; but I'd rather have more productive coworkers that help keep our business alive. My coworkers appreciate it (most of the time) because it helps them grow.
> I will still interrupt my coworkers who are working on the wrong thing.
How common is this, how can you tell, and why were they working on it in the first place? How often do you interrupt them when they were working on the right thing, as an unfortunate side effect?
I've wasted time and energy on dead ends and it is one of the most frustrating things, even when it was understandable, sanctioned, and a desired exploration of the problem space. I'm all for trying to avoid unnecessary waste.
> I understand that makes me a micro-manager;
That this is your understanding would concern me greatly, though. I'd rather be macromanaged - have the big picture explained to me, in a way that I can understand and buy into, that I can then approach in the ways that best suits my own talents and abilities. Where I can contribute my own insights and ideas to the collaboration, where I don't start working on the wrong shit in the first place.
Not just... along for the ride, like floatsam, being told I've been doing it wrong a hundred times and do it this other way because I've been told to, without any deeper insight to correct the underlying problem. Or even worse, without any real underlying problem in need of actual correction.
