Pair Programming – a most uncomfortable working situation

Firefighters, soldiers, hostage negotiators, and trauma specialists regularly deal with life and death situations at work. On the scale of uncomfortableness, these jobs are at or near the extreme. For many of us who write software for a living – even those of us who write life-preserving software – there is nothing that compares to the stress and pressure that these jobs constantly demand.

In our sequestered bubble of work-related-stress, we have certain expectations: 

1. That creative work requires physical comfort. The ambient noise, temperature, lighting, smell – in short, the inputs to all our senses – must produce a sense of calmness to maintain the mental concentration required for creativity to sprout.
2. That there will be sufficient time to solve the problem. Creativity is difficult to schedule. Tough technical problems rarely, if ever, yield to the first solution. This makes predicting “how long would it take to solve X?” a particularly fiendish question to answer. (The copious literature on the art of software estimation is one indicator of the toughness of this problem.) 
3. That there will be sympathy when we admit to being stumped. Being stuck is the default state. When you’re solving a technical problem, the feeling is one of being constantly unproductive. This is because the easy parts get done quickly; and then you get to the next blocker. [1]

My thesis is that pair programming is uncomfortable because it pushes hard against these expectations.

Sitting in close quarters to someone – a necessity when pairing with them – is likely to create physical discomfort. The slightest personality quirk – the way someone exhales when there is a compilation failure – can be difficult to put up with when you pair with them for hours at a time. Pair-programming is probably the only professionally acceptable situation where you’re likely to breach your pairing-partner’s personal space. (It doesn’t happen in meetings, during whiteboard sessions, or at lunch.)

Pair programming creates a time pressure on creativity. When you’re pairing with someone, the expectation is that you’ll make some progress at the end of an hour or so. You may have had the same expectation of yourself, if you weren’t pairing. However, the contract of pair-programming heightens that expectation because you not only expect progress of yourself (the default), but also of your partner; and they expect the same of you. This expectation of progress is even more heightened if you’re pairing in view of other people: your teammates, for example. The social pressure created by this high-visibility trapeze act pushes against the need to have sufficient time to be creative.

Pair programming can create tacit assumptions about your partner’s prowess. The very act of pairing implies that “when I am stuck, you’ll help me”. [2] If you’re both stuck as a pair, you may both have less sympathy for either of you than if you were stuck on the same problem alone. The thought that “two smart people shouldn’t be stumped by a problem at the same time” is a powerful nag. Of course, the very reason pair programming works is because it allows two brains to focus on the same problem simultaneously. [3] However, this guarantees neither that you’ll be stuck less often, nor that you’ll feel that you’re stuck less often. 

Pair programming is productive, effective, and an excellent way to develop software. It can also be a lot of fun. However, it’s not automatically any of those things. To make pair programming all this (and more) for yourself, it’s helpful to realize that it may be the most demanding, even uncomfortable, activity you’re asked to do as a software professional.

Footnotes

[1] Twice I drove on the Autobahn between Hamburg and Sundern, a distance of 350 km. The times during which I drove at 250 km/h were wistfully brief – because they went by so fast! I spent the most time stuck in rush hour traffic in Hamburg and while passing through construction or speed-limited zones.

[2] The converse – “when you’re stuck, I’ll help you” – is also implied. Although I’d guess that, because of human nature, we assume it a little less stridently!

[3] A better explanation is that it harmonizes the asymmetric activity of the two pairing partners: the driver (more sequential and logical, i.e. “left brained”) and the navigator (more holistic and imaginative, i.e. “right brained”). As my friend and mentor Neal Ford puts it: “pair programming is the first time we’ve used a whole human brain to solve a problem … using two half-brains at a time!”