Unforseen Perks of Pair Programming

As someone who had never pair programmed before, it was exciting to get thrown into the deep end during my first week at Braintree where engineers pair nearly 100% of the time.

The relative merits of pair programming have already been spoken about at length.[1][2] This post is not an attempt to argue one way or another. Whether it works for any organization is probably too context-dependent for any axioms I could lay down.

What I want to share with you were my observations - including some unforseen perks - I had during my first week.

More details on how Braintree pairs:

A pairing station consists of one Mac Pro with two monitors side-by-side, mirroring each other.

One way Braintree’s flavor of pairing differed from what I’ve read about is in the concept of the ‘driver’ and the ‘reviewer’ - where one person is doing the typing and the other person is thinking about higher level stuff and where to go next. This was not how my pairs usually went - instead we handed off the controls to each other fairly frequently - sometimes in the middle of writing a line of code. I’ve never done improv comedy before, but switching off frequently reminded me of the concept of chivalry in improv - i.e. not needing to write all the code yourself; adding suggestions when helpful but pulling back and letting other people take the reins. There’s probably a similar concept in Jazz improvisation. Since we’re on the subject already, if you haven’t seen it before, you should watch Design, Composition, and Performance by Rich Hickey.

I also thought of a metaphor that describes my experience with pair programming in contrast to code reviews (I know the two are commonly pitted against each other - I don’t think they’re mutually exclusive, although that’s not the point I want to make). Code reviews seem like a build-and-compile step to software development, whereas pair programming seems more like working with a REPL. You’re getting instantaneous feedback on the quality of your code and your design decisions instead of waiting a week to hear it.

Having never tried it in practice, pair programming didn’t seem that appealing or useful. However, after last week I now have a better idea of why it’s employed by firms like Pivotal, Facebook, and Thoughtbot. The adage “If you want to go quickly, go alone. If you want to go far, go together” comes to mind. Programming is viewed as a fundamentally solitary activity but I think in some cases that characterization is naive or inefficient. Hopefully these observations make you consider trying out pair programming if you haven’t given it a go already.


Contents (top)