Programming is not only about knowing how to use specific words and abstract constructs to build a program. It is also about being able to design and develop complex structures of data and algorithmic workflows. And most of the time, these complex elements are interconnected, which means that when you decide to mess with one of them, you’re actually messing with several others.
The by-products (or side-effects) of some functions can affect the rest of your system. Thus, programmers generally need to keep a mental picture of the entire system to avoid creating bugs. That is why it is so important for a programmer to maintain complete focus while building such elements.
Derek Johnson sums it up:
Interruptions are to developers what kryptonite is to Superman—they kill productivity and there’s a significant recovery period.
So, here are a couple of advices for non-programmers on “how to deal with your programmer colleagues”:
- Headphones on = no interruptions – I use headphones all of the time and choose appropriate tunes (usually non-distracting tunes like mellow Jazz) while programming. I know some of my colleagues (non-programmers) find this insulting as they interpret my unwillingness to participate in their discussions on trivial matters as rudeness. But this is not rudeness. It’s just that we know that those conversation sessions (even if very quick) affect the programming productivity.
- Use e-mail – I know that you feel that your problem will only get the necessary attention if you come up in person (or you send a quick message through any instant messaging client) and tell the programmer about it, but that is harmful for the reasons that I pointed above. So, use e-mail. If your programmer colleague has any e-mail discipline, she/he’ll make periodic visits to her/his inbox and deal with the problem accordingly. Oh, and don’t do this after sending the e-mail: