Programmer? Interrupted?

2 minute read

My friend Andrew Connell (@andrewconnell) posted a very interesting article called Programmer Interrupted to Facebook today, saying:

…all developers should share this with the one you love or non-developers you work with. Help them understand why you get so pissed when they come into your office to ask the simplest questions. Many times I feel like I’m holding a castle made of cards up with one finger, holding my breath when suddenly there’s this tiny puff of air that brings everything organized to complete chaos Smile

I do think that these effects vary considerably across individuals, and I don’t think it has to be a permanent condition.

When I was a young programmer (my second job in the mid-80s), I was in a highly interrupt-driven environment at Bain & Co., the management consulting company. I did a bunch of different things during my tenure there, but a lot of it was what we called “programming” at the time. Because I was interrupted extremely frequently – sometimes half a dozen times an hour, by my recollection – I simply learned to be better at it over the six years I was there.

At a later job around 1999-2002 at a company called ArsDigita, I was amazed at how defensive the young developers sometimes were with their time. They occasionally could be almost hostile at interruptions, which in a way ensured that they couldn’t learn to deal with them. I think the headphone thing actually made it worse, since an interruption was more jarring to their memory patterns, as it often required a physical incursion to get their attention. They interrupted each other, too, by the way; I’m not basing this just on my observations from interrupting them myself.

I can’t say that I’m great at managing interruptions, but I do think that I learned to be better at it than some people are. I don’t suggest that everyone embrace interruption – or even encourage it as I sometimes do – but I do suggest that everyone should consider how their work environment actually functions most of the time to consider how best to adapt. If you are likely to be interrupted, work to identify how you can best work inside that construct.

Techies often get a bad rap because they are too defensive and say no too often. Part of that bad rap can come from the impression of “my work right now is more important than whatever you are here for” that comes from reacting unpleasantly to interruptions from the very people for whom we are supposed to be doing the work.

Don’t just try to avoid interruption, treating it as an evil, but welcome it on some level so that you can be a better IT professional. You’ll have a happier user base, and you might just learn some new tricks.



  1. Great point, Marc. As more and more people learn “to speak code” it’s important to be approachable and work on communication skills. It helps us grow and them. Everyone needs a different strategy that works for their style.

  2. I agree, we all need to be approachable, however there are times when interruption is _very_ costly. Given this I may reply that if it’s not urgent I’ll contact them when I get to a suitable break point, without actually looking away from the screen.
    I’m not trying to be rude, I’m just trying not to let the mental model I’m holding collapse under the external pressure.

    • Gavin:

      At least you are giving them an option. My point is that it’s important to consider the ramifications on others of protecting your mental space over time. The type of interruption also factors into it, as does who the interrupter is. As always, it depends.


  3. I recently moved back to a developer role, and have been training myself to deal with such interruptions. Specially as the company I work for moves to the open space model, where the urge to start an impromptu conversation will likely be greater. What I have been finding myself doing is that if I’m in the midst of trying to understand a piece of code or writing some complex logic, I ask that person if its OK I get back to them… That seems to work for me; I am able to continue to focus on the task at hand.
    The item I’m still having difficulty with is the office chatter around me – my office mate is on conference calls throughout the day and normally has people come into the office to ask questions or have small meetings. I hate to say it, but I may try the “Headphone” approach for this…
    Thanks for the post and the link… Great analytical piece.

    • Paul:

      Maybe a “Programmer working” sign with a way to leave a message when you have the headphones on? (Paper still has its uses!).

      Mitigation, mitigation, mitigation…

      Let’s all work to make IT suck less.


  4. You get a better relationship with your ‘Internal Customers’ when you can break away and help them. I know its tough at times, especially when you “a programmaer” tend to get into a “zone”, meaning your current intelect is right in the sweet spot and your figuring out the logic as your coding (sometimes for hours and you forget the time) only to be interrupted and then spend a half hour getting back to where you left off. But in the long run its the relationships in the workforce that matters. To me anyway.


Have a thought or opinion?