The Real Reasons To Pair Program

16 December 2012

I posted this on Braintree’s developer blog last week:

Braintree has an opinionated approach to software development. One thing we feel particularly strongly about is pair programming. We pair for almost everything.

Often when discussing pair programming, people focus on the effect of pairing on code quality and developer productivity. The argument goes: a pair costs twice as much as a single developer, but if they deliver code in X% of the time, with Y% fewer bugs and Z% less technical debt, then depending on your measurement of X, Y and Z, pairing might make sense.

While this argument isn’t wrong, it misses the most important reasons why we pair: it contributes to an amazing company culture, it’s the best way to bring new developers up to speed, and it provides a great way to share knowledge across the development team. In each case, practicing pair programming makes it easier to make choices that have slightly higher short term costs, but huge benefits in the long run.

Pairing bakes collaboration into the core of company culture

Pairing is an intensely social experience. You spend eight hours a day working very closely with another developer. This means that if the person you’re pairing with can’t communicate effectively, work through problems with you, and just generally be fun to work with, you’re going to have a bad time. This is part of why Braintree’s interview process puts communication skills and cultural fit on an equal footing with technical competence: we’re not interested in hiring people we wouldn’t want to pair with!

Hiring processes are the cornerstone of company culture; it’s impossible to create a vibrant, cooperative environment without good people. By heavily emphasizing cultural fit and communication skills when hiring developers, we select for a collaborative attitude early on. There’s also a degree of self-selection at work: if a developer doesn’t want to work at a place that pairs, they probably wouldn’t be a great cultural fit at Braintree.

There are short term costs associated with this, of course. If we decide not to hire someone who is good technically but a pain to work with, we’re essentially giving up short term productivity gains in the name of protecting company culture in the long term.

Pairing accelerates new developers like a rocket

When pairing with someone, you don’t just observe them writing code. You see how your pair goes through the entire development workflow: figuring out where to make changes, writing tests, reading source code, looking up documentation, configuring the development environm ent, and so on. You see which tools they use and how effective they are.

Junior developers benefit enormously from seeing how senior people do all of this. More importantly, they can also get continuous feedback from from their senior pair when it’s their turn to drive. I’ve experienced this personally – when I joined Braintree, I had about a year of professional development experience and had not studied much computer science in college. After being here for three months, my workflow has transformed completely.

In the long run, senior developers benefit from this as well: it’s something of a cliche, but teaching a subject really will improve your own understanding of it. That said, junior developers pairing with more senior developers definitely also has an associated short term cost and long term benefit. A pair of senior developers can move faster than a junior dev and senior dev, particularly on a codebase that the senior developers know well. However, the benefits of being able to bring new hires up to speed quickly accumulate.

Pairing places knowledge transfer at the center of the development workflow

Apart from basic programming ability, developers need a huge amount of information to operate effectively. There’s domain knowledge, knowledge of the codebase, an awareness of company conventions, best practices to check, and so on. Any development methodology worth taking seriously needs to have a good way to disperse this knowledge across the team.

When pairing, sharing this sort of thing is a matter of course. Asking questions is never an interruption – constant communication with your pair is part of your normal workflow.

In addition to this, there are hundreds of little development tricks that developers pick up from each other when pairing: command line shortcuts, vim tricks, ways to combine vim and tmux, and a million other things.

Pairing for the long haul

Braintree heavily emphasizes long-term thinking in our development style. We TDD, write code with an emphasis on maintainability and readability over cleverness, and try as much as possible to move slowly and thoroughly. Pairing is part of this; pairing provides a way to make a small investment in our development team every day. We work this way in part because we write payment processing software that provides a mission-critical service for our customers. But we also do it because we believe that, in the long run, these practices pay offin a big way.

comments powered by Disqus