Work in the technology trenches tends to bubble over like an ignored pot of pasta boiling on the stovetop -- but not because it's being ignored. Rather, we fall victim to the fact that we need to be available at any given moment to deal with emergencies or to clarify technical facts for future planning or to provide an answer to a blocking problem. Folks who do data center and system architecture design and management do not have the luxury of being able to concentrate on a single task. Switching gears quickly and abruptly is part of the game.
Naturally, it can become tiresome. Few situations are more irritating than being shoulder deep in an incredibly complex problem only to be interrupted by any of a half-dozen available contact methods and feel a possible solution slide from your grasp as certain variables that were starting to congeal into an answer shatter like a Prince Rupert's Drop.
As an example, the other day I was far down the well of a tricky geolocation algorithm construction when two phones started ringing within a second of each other. On top of that, a flurry of IM notifications arrived from a monitoring box informing me of nearly critical issues starting in one data center, and I received two completely unrelated text messages from different people. It was more than enough to destroy any semblance of concentration. Even though it took me only 15 minutes to deal with all of those calls and problems, it set me back at least an hour in terms of what I was actually doing. This cartoon states the case pretty well, and this graph underscores the point.
Programmers alone aren't subject to this phenomenon. It can happen at any time to anyone who is deeply focused on a problem or design element, though I think it hits developers harder than most.
Sure, there are ways to combat this, like noise-canceling headphones playing music, or playing nothing at all. You could turn off your phone, put up a sign telling everyone to go away, and shut down all other communication methods, isolating yourself in a cocoon of solitude wherein you should be shielded against any disturbance. Maybe developers can manage that, but the rest of us, especially those of us who write code for IT purposes, can't do that at all. We're always exposed to the elements.
After enough time working this way, either it drives you bonkers or you adjust. It is possible to adapt and accommodate sudden interruption without causing a wholesale reboot of where you were prior, but it sure isn't easy, and it's never guaranteed.
There's also the flip side, which is when you get so deeply mired in code or trying to suss out a solution to an emergent problem that you should step away from it for a while and try to regain perspective. Sometimes, the two are intertwined and we find the onerous interruption that caused us to blink out of where we were focusing has caused a mental switch to flip, or we notice something we hadn't before as we ramp back into the game. Where we might have beat our heads against the issue for another 20 minutes, that two-minute interruption gave us the answer almost immediately.
That's pretty much what happened when I was shelled with phone calls, IMs, and text messages all at once the other day. After doing my best "no, really, I'm not pissed off at all" impression in various ways, I tabbed back to the Xterm that held the code and my eyes immediately honed in on the problem I was having with the calculation. I'd spent the previous 10 minutes trying to figure out how in blazes the calculation was still returning stale data to the test harness because it looked perfect ... only to see that although I hadmentally marked off that I had disabled the caching, I hadn'tactually disabled the caching. I was seeing stale data because it wasn't coming from the new code, but from the cache, and I hadn't added the cache writes back in yet.
It's those types of situations that become the ebb and flow of daily life in the data center and in coding cubicles. Not all times of intense focus are totally productive, and not all interruptions are totally destructive. If given the choice, however, definitely try not to interrupt the programmer. Don't be that guy.
This story, "No interruptions! Technologist at work" was originally published by InfoWorld.