The buddy system: an alternative to pair programming

Pair programming has always rubbed me the wrong way. I understand why some people like it. It’s great to have collective code ownership. It’s great to have conversations about what the code should look like before the code is actually written. And it’s great to have a collaborative work environment where people are always learning from each other.

But a LOT of people are turned off by pair programming. It’s too easy for the person who isn’t typing to just zone out. Some (many?) developers just don’t enjoy pair programming as a practice. It generates a LOT of noise (imagine 5 pairs of people talking at once). And no great internet company that I’m aware of seems to do it heavily. In fact, the biggest advocates of pair programming are often consulting shops (who charge by the programmer-hour and therefore have an obvious conflict of interest).

Trying to figure out how to get some of the benefits of pair programming without the drawbacks, we stumbled onto the “buddy system” at SlideShare. The rule is pretty simple: if you’re going to be doing something dangerous and complicated (like swimming or writing production ruby code) you probably shouldn’t be doing it alone.

So developers at slideshare just tend to work together on stuff. They don’t work on the same code … there’s always a bunch of different files that will need to be edited or created for implementing a new feature. But they’ll work on the new feature or bug together, usually in ad-hoc teams of two or three.

Some of the benefits of this approach are:
* Architecture and overall code structure always has a consensus of at least two behind it. If there’s a disagreement, it will be audible and the rest of the team can get involved as needed until consensus has been achieved. This dramatically reduces rework caused by one developer making an architectural decision that the rest of the team doesn’t agree with.
* There’s always someone available who can code-review your code and already understands the context of your code. This is crucial, because we do code-reviews before every checkin. And an uninformed code review doesn’t have value (it’s likely to be a “lgtm”, or “looks good to me”).
* There are always at least two people always understand a given section of the code base.
* The work feels a lot less lonely. There’s someone else deeply involved in the same problem that you are facing. It’s easy to learn from them because you’re working together.
* You still get lot’s of “me” time, with just you and the compiler. Lot’s of engineers got into programming because they enjoy quietly writing code, and there’s no need to take that away from people as long as enough collaboration is also happening.
* The collective nature of the work makes it more likely that peer pressure will keep developers from cutting corners on unit tests or other good practices that your team has adopted.

Just to be fair, there are a couple of disadvantages:
* Not all problems are big enough for two people to work on. Simple bug fixes, for example, should just be grabbed and worked on.
* Unlike pair programming, some code will typically be written before a second person looks at it. So you miss out on getting the feedback as early as possible (when the code is most easy to change and no one has emotional investment in it yet)

Overall, though, we’ve found the buddy system to be a remarkably fun and productive way of working.