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.
- First of all, as someone who hadn’t paired before, the first few days were exhausting.
- It felt a lot like an airplane cockpit. One person would fly the plane while the other prepared for the next move.
- Frequently when I’m programming and run into a snag, I’ll futz around for 15 minutes while slowly losing interest and focus - which usually turns into browsing Twitter, Facebook, or email. Dips in productivity like this simply didn’t happen while pairing. Not to say we found the answer to every question right away - when we couldn’t, coming to a consensus quickly about whether we could make any progress made it much easier to ‘admit defeat’ and start asking other people in the office.
- Staring at a screen for 3 hours in solitude usually makes me not want to talk to anyone. Pairing put me a much more social mood during and after.
- Since I wasn’t wearing my headphones all day, my ears felt much better after a day at work. I’m sure this is highly dependent on if and how you listen to music at work - but it was a nice change for me.
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.