Why developers hate being interrupted
thetomorrowlab.com
thetomorrowlab.com
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.
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?
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.
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.
- 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?
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?