Programmer, interrupted (2013)
gamasutra.com
gamasutra.com
"Hey, how is this task going?" -> go to JIRA
"Hey, are you blocked?" -> go to JIRA
"Who is working on this?" -> go to JIRA
Then I check JIRA when I have the time.
More to reference = less time to get back up to speed
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.
0 - https://en.wikipedia.org/wiki/Flow_%28psychology%29
1 - http://grahamchastney.com/2011/10/axiom-interruptions-cost-2...
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.
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.
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.
What makes a great developer are soft skills,
and gluing together other code, not cranking
on something for hours alone.
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.
Then it looks like it goes in to a sales pitch for 'solutions' to that problem?
I'm with Feynman on Psychology.
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.
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.
He can tell because he's a manager, and if he wasn't always right, he wouldn't have been made a manager, so he's always right.