The Cost of Interruptions While Programming
I think we all struggle to explain to coworkers and clients the cost of interrupts when we're in Flow (excellent book, BTW - if you haven't read it). Neal Ford just wrote a nice post about the topic. For me the killer quote was:
How do *you* explain to co-workers and clients the need for uninterrupted flow time? And how do you signal when you need to concentrate and when you're open to interruptions in the physical world. I was considering a ping pong racket or similar with red and green sides - red side up, leave me alone. Green side up, come on over. Thoughts?
@Eric, Depends on the headphones. Unfortunately I *always* have my Shure in-ear buds on - whether in office, at home, on subway or working in starbucks. Maybe I should get some big over the ear phones as a "do not disturb"!
@Rob, Yeah - that's what I really liked. All programmers know the problem, most of us have coping mechanisms, but it was by far the best analogy I'd ever come across. I'm going to try it on some clients and I'll see if they "get" it more easily.
On the other side of the coin, I think it's a good idea to ask someone if it's a good time when I show up in their cubicle. As long as they are good about getting back with me, I don't mind saving my question for later.
Then again interruptions are there and will most likely never go away. What about the phone, email or IM? How about your bladder or stomache craving that tasty pizza from down the road?
Unfortunately it really depends on your role and how you fit into an organisation. If you are "just a programmer" perhaps you can be shielded from a lot of interruptions by your immediate boss or even a process of "don't speak to the programmers!".
At the end of the day we all need to deal with it because much like email...it's never going to go away :)
1. The Internet is Broken
2. Printer toner is out
3. Paper Jams
4. How do you calculate sums in Excel
5. Did you just get that email I sent you? -- one of my favorites
It may not take 30 minutes to get back into but it does take time, especially if you are working on someone else's code and figuring out what they were thinking and why in the world they have 500 lines of code for something that could be done in 75.
Sorry for sounding bitter but today was one of these days of interruptions where people just walked in my office, plopped down and started chatting. I love to chat too but when you are dealing with SOAP calls to a third party and the third party really has no docs and it is all trial and error I am sorry if I am standoffish to quote Jake.
I think how you should manage interruptions depends on three things: how you expect to work, how other people (boss/teammates/etc) expect you to work, and what happens when you ignore interruptions.
To extend the analogy a bit, some people have a devil of a time getting back to sleep: wake them up for 5 minutes and you really have awakened them for an hour. Other people drop right back into dreamland: for them, a 5 minute interruption is just that, and only if you poke them once a minute to ensure they're still awake. If you lose your train of thought easily, or if you're working on someone else's code like Brian mentioned, then maybe you do have to guard your time more carefully.
However, at many companies, you can't simply say "You can't interrupt me, please go away". If you're in an environment that allows that, by all means take advantage of it, but if there are expectations that you'll be available for questions and such (particularly if you're a senior developer/team leader), you'll probably have to have some sort of compromise: green means "approach at will" and red means "approach with caution". (Or donuts!)
The other thing to keep in mind is what happens if you do ignore the interruption. If it's just someone wanting to talk, or a little question about something not specifically related to your position, then it might be easier to push off for now. If it's about something that's going to be worse if you have to clean it up later, you might need to take that call ...
I think it's best to stand firm when you can and compromise when you have to.
The problem comes in when the interruptions involve different trains of thought or require more time than the interrupter expects. For example, "Hey can you help me debug this real quick?" Or when a project manager pops in for a "quick" time estimate on a new customer request. Obviously both tasks require the brain of the engineer, but ultimately take him/her off their highest priority task.
When the boss comes in asking why such and such isn't finished yet, how does the engineer account for lost interruption time?