I've never found it to be a problem, I guess I must be good at context switching. But then again I'm usually working on 4 or 5 things at a time anyway, so a few interruptions don't seem that bad! I like the break, and then there's the bonus of solving something by not thinking about it.
Same here. I work from home and often enough have a 2-year old wander into my office. Talk about random interruptions. But I don't notice skipping more than a beat.
Maybe it's because I don't tend to work with really bad codebases that force me to keep huge mental models in my head while I'm making changes. Or perhaps I'm fast at getting ideas onto paper so that the stuff I need to keep in memory remains small. Either way, the dynamic the article describes is not an absolute, universal thing. There are environmental / behavioral factors at work besides "Developer, Interrupted."
random interruptions aren't the problem, it's having to drop de-coupling work in a RTOS that I'm 3 days into when I get a support request that requires me to do the same in a second codebase, and then a phone call about a project I just deployed.
I thought I was just an idiot, now I realize I was at a bad company; but [my inspiration is gone] it's too late for that now
Your last point is a truism for me: if anything, having random questions or discussions to break up the dev work seems to imbue me with greater energy. Almost like being briefly forced to think about something different allows me to 'see the forest for the trees'.
You're very lucky in that regard. For me, a context switch, especially when I'm working from home, not only throws me off for a few minutes, but also takes away my motivation that has a more than few-minute impact.
Of course, I'm actively working on that, but interruptions don't help. And the more they happen, the more demoralizing they become and it's a vicious cycle.
There's an elephant in the room, as well, which is social status. Impromptu status pings are a show of power ("this happens on my time") and often make a person feel subordinate and demotivated. It's only 15 minutes to recover context if motivation isn't lost, but if the impromptu meeting becomes intense and emotional, then you can lose hours. All meetings cost time at the edges (no one starts a project at 9:50 if there's a 10:00 meeting) but those that are infuriating, stupid, or otherwise unwanted probably do more damage than meetings do if they're useful and rare.
Impromptu status pings, except in a production crisis or in a time-critical situation, shouldn't happen. Any status reporting infrastructure should be regular, legible, and structured and, in typical times, ought to consume no more than 15 minutes per day.
As for meetings, those can be useful or worse than useless, and the problem there is that the usually higher social status of those who schedule them prevents proper feedback on the meetings that don't work or make sense. Just as there's complexity creep in code as features (whether well-thought-out) pile on and kludges and counter-kludges are thrown in, there's complexity creep in management as meetings get thrown on calendars and the people most aware of them not working don't feel comfortable pointing the fact out.
"Impromptu status pings, except in a production crisis or in a time-critical situation, shouldn't happen."
I have the urge to weaken that, when the status has material impact on what the ping-er should be doing. If my coworker - superior or otherwise - is trying to figure out what he should be telling our most important customer that's a different thing then him just wanting to know - or worse, thinking it's keeping me on task.
I agree. The first rule is that there are no rules. If you need to interrupt someone to get unblocked, that's different from asking for a general status report. I was talking about the latter.
Interruptions are to developers what kryptonite is to Superman—they kill productivity and there’s a significant recovery period.
I hate to break it to you but this is not a problem unique to developers. "Flow" is not exclusively the domain of developers and basically every workplace I have been in has had this problem in some fashion.
Here is a list off the top of my head of groups of people who hate being interrupted:
Developers aren't the only ones who should be free from interruptions while working. My feeling is that the majority of problems that developers think are unique to them are just classic bad management.
I did not think anyone was claiming that this was unique to developers. The article's quote from Paul Graham explicitly mentioned writers, for example.
Every group for themselves ;-)
But I don't think musicians and artists usually have bosses and coworkers around as much as developers do. Researchers seems to often have other researchers as bosses which hopefully don't interrupt them multiple time every day. Athletes would probably hate having someone come in every day in the middle of their training session telling them there is a meeting in 15 min but I haven't heard about that happening very often.
Well exactly. These are management problems. Insofar as they are unique to the environment they apply broadly - rather than as a discipline.
And yes, most researchers at least in my experience work in the same kind of structure as developers, namely one in which their "bosses" may not be a researcher at all or whose job has moved away from being a researcher for so long they have forgotten how to work.
What's really great is when you're working on something else, someone sends you an email, and then walks over to discuss the email they just sent, because you didn't reply in 30 seconds.
I've been teaching myself how to resolve deadlocks occurring in our database and completely removed one deadlock scenario from occurring (it was occurring hundreds of times per day) and reduced another scenario down to about 1 deadlock per day from about 200 per day. It was really hard stuff for me at first (although I think I've got the hang of it by now).
My managers will simply not do anything about the phone ringing on my desk that several other people at the office can handle (including themselves).
On the one hand, I feel like acting like a child and just giving up on the problem I'm currently solving since nobody asked me to do this but on the other hand I know every year during our peak season these deadlocks bring our system to its knees and it doesn't look like anyone else is going to do anything about it (I just got access to the codebase a couple months ago and thought of adding error logging a few weeks ago which showed me the thousands of deadlocks that were happening everyday).
I'm not sure why I even try to help if they don't try to help me.
I don't just mean in terms of monetary compensation (although that too). If you haven't explained the value of your efforts to your bosses, then you should do that. If they can't understand the value of it, or don't want you to put effort into it (or aren't willing to support you while you put effort into it), then you shouldn't do it. Spend the time instead answering the phone -- that's what they want to pay you for -- and keep looking for a better job.
Somewhere up the chain of command is, hopefully, someone who thinks about everything in terms of money. Find that person and explain that the downtime and performance issues cost some amount of money every year. Do the math, come up with some real and plausible numbers. Then explain that you can fix it for probably some other amount of money. Before you go to them, make sure the first number is bigger than the second, otherwise they'll tell you you probably shouldn't be spending your time on it, and they'll be right.
Engineers have a bit of a tendency to focus on technical inefficiencies without giving enough consideration to the human or financial things in a business. The ringing phone might actually be costing the business more money than the deadlocks; some customers hate it when they call up and the phone consistently rings a dozen times or goes straight to voicemail. There might be other things that would be more important than fixing the deadlocks -- documentation tends to be a pretty common ailment.
It's great that you're taking initiative to fix some problems in the company, but be careful about feeling resentment over a lack of support for it if you haven't talked to anyone first to make sure you really should be working on this particular problem to the exclusion of other duties.
Yea, interruptions are annoying, but you have to learn to get good at them. Communication is the most important part of large software projects, and denying someone knowledge is just going to make the workplace unproductive.
Obviously there are trivial interruptions, but I do not believe that coding in 4 hour blocks is healthy of useful. If you can't start where you left off, you're probably not documenting well either. How is anyone else going to debug that?
21 comments
[ 3.2 ms ] story [ 58.7 ms ] thread- http://www.economist.com/news/international/21637359-how-wor...
- http://www.newyorker.com/currency-tag/the-open-office-trap
>Physical barriers have been closely linked to psychological privacy, and a sense of privacy boosts job performance.
I wonder if this is still true in today's internet connected workplace?
https://dl.dropboxusercontent.com/u/25009451/ProgrammerInter...
Maybe it's because I don't tend to work with really bad codebases that force me to keep huge mental models in my head while I'm making changes. Or perhaps I'm fast at getting ideas onto paper so that the stuff I need to keep in memory remains small. Either way, the dynamic the article describes is not an absolute, universal thing. There are environmental / behavioral factors at work besides "Developer, Interrupted."
I thought I was just an idiot, now I realize I was at a bad company; but [my inspiration is gone] it's too late for that now
Of course, I'm actively working on that, but interruptions don't help. And the more they happen, the more demoralizing they become and it's a vicious cycle.
Impromptu status pings, except in a production crisis or in a time-critical situation, shouldn't happen. Any status reporting infrastructure should be regular, legible, and structured and, in typical times, ought to consume no more than 15 minutes per day.
As for meetings, those can be useful or worse than useless, and the problem there is that the usually higher social status of those who schedule them prevents proper feedback on the meetings that don't work or make sense. Just as there's complexity creep in code as features (whether well-thought-out) pile on and kludges and counter-kludges are thrown in, there's complexity creep in management as meetings get thrown on calendars and the people most aware of them not working don't feel comfortable pointing the fact out.
I have the urge to weaken that, when the status has material impact on what the ping-er should be doing. If my coworker - superior or otherwise - is trying to figure out what he should be telling our most important customer that's a different thing then him just wanting to know - or worse, thinking it's keeping me on task.
Thoughts from your PoV?
I hate to break it to you but this is not a problem unique to developers. "Flow" is not exclusively the domain of developers and basically every workplace I have been in has had this problem in some fashion.
Here is a list off the top of my head of groups of people who hate being interrupted:
Writers, musicians, artists, academic researchers, potters, watch makers, statisticians, athletes, gardeners etc...
Developers aren't the only ones who should be free from interruptions while working. My feeling is that the majority of problems that developers think are unique to them are just classic bad management.
And yes, most researchers at least in my experience work in the same kind of structure as developers, namely one in which their "bosses" may not be a researcher at all or whose job has moved away from being a researcher for so long they have forgotten how to work.
My managers will simply not do anything about the phone ringing on my desk that several other people at the office can handle (including themselves).
On the one hand, I feel like acting like a child and just giving up on the problem I'm currently solving since nobody asked me to do this but on the other hand I know every year during our peak season these deadlocks bring our system to its knees and it doesn't look like anyone else is going to do anything about it (I just got access to the codebase a couple months ago and thought of adding error logging a few weeks ago which showed me the thousands of deadlocks that were happening everyday).
I'm not sure why I even try to help if they don't try to help me.
Do what makes your boss happy with you, for security.
Do what will help you get the next job you want.
Find a niche where they pay you and forget about you, and do what is fun.
I don't just mean in terms of monetary compensation (although that too). If you haven't explained the value of your efforts to your bosses, then you should do that. If they can't understand the value of it, or don't want you to put effort into it (or aren't willing to support you while you put effort into it), then you shouldn't do it. Spend the time instead answering the phone -- that's what they want to pay you for -- and keep looking for a better job.
Somewhere up the chain of command is, hopefully, someone who thinks about everything in terms of money. Find that person and explain that the downtime and performance issues cost some amount of money every year. Do the math, come up with some real and plausible numbers. Then explain that you can fix it for probably some other amount of money. Before you go to them, make sure the first number is bigger than the second, otherwise they'll tell you you probably shouldn't be spending your time on it, and they'll be right.
Engineers have a bit of a tendency to focus on technical inefficiencies without giving enough consideration to the human or financial things in a business. The ringing phone might actually be costing the business more money than the deadlocks; some customers hate it when they call up and the phone consistently rings a dozen times or goes straight to voicemail. There might be other things that would be more important than fixing the deadlocks -- documentation tends to be a pretty common ailment.
It's great that you're taking initiative to fix some problems in the company, but be careful about feeling resentment over a lack of support for it if you haven't talked to anyone first to make sure you really should be working on this particular problem to the exclusion of other duties.
And don't do it for free.
Obviously there are trivial interruptions, but I do not believe that coding in 4 hour blocks is healthy of useful. If you can't start where you left off, you're probably not documenting well either. How is anyone else going to debug that?