Pair Programming Pointers

Pair programming is the one Extreme Programming practice that I get the most pushback from both developers and managers.

Most of us have experienced programming as a solitary art form and we've done it alone. We figured out a bunch of things for ourselves and we don't necessarily feel comfortable doing our work in the presence of another. But think about how worse off medicine would be if surgeons didn't pair up to do surgery.

If Uncle Bob Martin is correct and the number of software developers going into the field doubles every five years then we are an industry of amateurs with an average experience level of two-and-a-half years. Yet developing software is some of the most complex and intricate work that humans have ever engaged in. Pairing and mobbing are great ways to share information and refine skills as software developers.

So here are some basic tips for a successful pairing session.

Pair programming is not about taking turns at the computer. It's about bringing two minds to bear on the same problem. It's about collaborating and thinking through problems with another person to help us gain clarity. We do this all the time. I'm sure you have the experience like I have had where I was stuck on a problem so I called over a colleague and just thinking about how to explain the problem to them, I've come up with the answer. Externalizing a problem or saying it out loud to someone else helps us gain a different perspective and sometimes that's enough to help us discover a solution that we hadn't thought of before.

But pair programming is more than just externalizing your ideas. It's about forming a true collaboration where both the driver and the navigator are engaged in solving the same problem together. These are typically not skills that we were taught in school or on the job, so learning how to effectively collaborate in a pair it's something that we must be open to.

If we're stuck and I suddenly get an idea that I want to try out then I passed the keyboard to my partner and have them drive. Likewise, if my partner has an idea and starts typing on their own then I'll offer to be the driver.

I see the driver's role as primarily being in service to the navigator. As the driver, I try to handle the minutia of working at the keyboard so the navigator can think about things at a higher level of abstraction.

The navigator is also in service to the driver by giving instructions to the driver so that they are easy to understand and execute. The level of abstraction that a driver can assimilate is constantly in flux. If an operation is new to the driver then the navigator may have to spell out the steps in detail, but once the driver is familiar with a set of operations then the navigator can give it a name and then refer to it just by name.

When we are pairing and mobbing I very often think that we are in service to each other. By working through problems together we gain different perspectives then we would've had by ourselves and we also learned a tremendous amount from each other. Much of the details of being a fine craftsman and software developer can be learned through pairing and mobbing. This includes everything from key bindings to coding conventions. Pairing and mobbing are the fastest ways I know to propagate knowledge across a team.