Back when I worked in a cubicle farm, I used to derive the most job satisfaction from those days when I had few interruptions and no meetings. I’d focus intently on a particular programming problem and the whole world would melt away, and there’d be me and the code, and we’d kind of become one in some sort of Tron-esque nerdfest of uber-coding. I, like a lot of other developers, would refer to those moments as getting into “the zone”.
Diana made a post a while ago about how pair programming keeps her out of the zone, and I think I’ve been pondering that for a while. And I think that one of the things I’ve concluded is that I’m no longer as enamoured of the zone.
For most of January, I was working on a somewhat unusual project. It was a bit of an experimental roadmap exercise. There were six of us in a project room, but only two of us would program on any given day. And we had a higher-than-I’m-used-to amount of time not pairing. And one of the things I noticed about that time was that I was surprised by how quiet it was in the project room. And surprised also by how starved I was for information about what was going on.
When people are pairing, they’re talking through various choices and decisions. And I’ve discovered that I like being able to overhear the things that are going on. It gives me some sense of what ground people are covering, and what kind of problems are being encountered. At the same time, it kept me abreast of what’s going on, and in a better position to offer a suggestion if a pair hit a wall.
I don’t generally think of myself as having great multitasking skills. I can’t, for example, read while watching television; I’ve watched friends do this, and I just Don’t Get It. But I think I have learned to keep part of my attention on what’s going on in the project while I’m pairing.
I’ve had some interesting moments in project rooms. I remember one instance, in particular, where I was pairing with someone relatively new to the project. He’d asked about some artifact in the code, and I spent a bit of time explaining the history of that particular artifact. Moments after finishing that explanation, I overheard the pair sitting beside me start to ask each other about the same artifact.
I think it says something about how much they were tuning out the rest of the room that they didn’t notice the people beside them talking about the same thing they were interested in. And, make no mistake, I understand how and why people do that.
But I think that “tuning out” is a key part of the zone experience, and even when people are pairing, and not really getting into the zone, a lot of developers (in my opinion) still seem to be trying to tune out the room. Part of the zone mindset is that other people are distractions, and doing something that does not relate to my programming task is a cost, and not an investment.
(I’m not sure how related this is, but I’ve also been noticing a phenomenon during stand up. Once stand-up starts, someone in the room is usually really, really quick to ask for the music to be turned off. And there’s something about that immediacy that I find fascinating. While I can certainly understand not wanting to have multiple noise sources competing for attention, for some reason it always strikes me that people are saying “now that I have opened up my attention to the whole table/room, I can’t tolerate the distraction of the music.” And if that’s true, I find myself wondering about how much they’re usually blocking out the room. Or maybe it’s nothing. I don’t know; I just wonder.)
And that makes me think about the Prisoner’s Dilemma and various ideas relating to privileging the individual versus privileging the group. For me, the key ah-ha moment of pairing came from recognizing that the conditions under which optimizing my own personal productivity didn’t optimize the productivity of the team. And if I value the team more than I value myself, then I’m forced to conclude that the zone isn’t my friend.