Pairing is for peacocks

I promised last week I was going to write more about pairing, and especially strategies for dealing with the situation where you don't understand what the heck is going on in a pairing session. I did write about that but you can't see it yet – it's shaping up into being a more substantial essay and I want to take another week to work on it.

Instead, this week, I'm going to talk about a little-known reason to pair that I personally think accounts for a lot of its value to both individuals and organizations: Pairing gives programmers an audience.

This is absolutely a major motivator for me. I like to make jokes, and pairing gives me an audience for those jokes. Laughing with my pair makes work more fun, which makes us more relaxed and creative, which at least in theory improves our programming output.

Having an audience has a value beyond "fun," though. It gives engineers a way to show off to each other without shipping really complicated stuff.

"Showing off" is really underrated as a motivator, especially by engineers. We tend to believe stupid things like, "I make decisions rationally," or, "I don't care about what people think of me, I just care about doing the job right," or, "I care about getting 'Senior' in my title for the money." Engineers, in my experience, care a lot about social status, and it drives a lot of their decisions, especially technical decisions.

I think the drive for respect from peers drives a lot of bad architectures, and a lot of bad technical decisions. When you don't get feedback from your peers very often, there's an impulse to, one, demonstrate how much work you're doing by volume of code, and two, demonstrate how extremely clever you are by how complex that code is. Neither of these factors are correlated with quality or effectiveness.

If you instead ship simple solutions a lot of your work is going to be invisible. Other people who know how hard it is to come up with simple designs might be impressed, but even people who should know better will often downplay how hard something simple must have been when they didn't see the produce that produced it.

When you have a pair, on the other hand, you have someone who's right there the entire time, and got to see the entire process of going from "janky first-pass solution" to "simple, refactored, actually-maintainable solution." You can impress your pair first with your cleverness, and then with your wisdom.

You can also show off with speed. This was a major part of the pairing culture at least at Pivotal, and it made me want to get better and faster.

You also just have someone to celebrate wins with. A good pairing culture teaches people to really celebrate the green test run and the small commit. These are values that are otherwise pretty hard to transmit.

If pairing cultures really do produce simpler solutions than non-pairing cultures – and I believe that they do – I think the "peacocking" opportunities pairing gives engineers are one of the main reasons why. Pairing gives engineers an outlet for their need to impress each other.