Pair programming is really a very simple concept. It’s about writing code in groups of two or more people. The person currently at the keyboard is called the driver. The person or people who are not at the keyboard are called the navigator or navigators.
The driver’s job is to deal with the minutia of entering code into the computer. This actually frees the navigator to think about the next few steps and keep a bigger picture in mind.
Nearly every team that I have met who is either having trouble with pair programming or didn’t like pair programming turned out to be doing it wrong. To them, pair programming was taking turns at the computer. They fight for the keyboard and the person who got the keyboard would hog it. Since the navigator really didn’t have anything to do they would take a nap until it was their turn.
That is not pair programming!
Pair programming is not about taking turns at the computer. Pair programming is about bringing two minds to bear on solving the same problem. So how do you encourage true collaboration, especially when we were taught to program in solitude?
One solution is to “past the keyboard.” I like to swap driver and navigator frequently and this helps to keep both engaged in the task at hand. How frequently? I say swap driver and navigator anywhere from every 2 to 20 minutes and I tend to prefer the short side, especially when I’m starting out with new teams. In other words, swap driver and navigator every 2 to 4 minutes to start with and that tends to keep people engaged.
We want to pair to bring software development to a true collaboration where two people are working together to discover the right solution. One of the best ways that I found to get developers into a truly collaborative mode when pairing is to have them start off in what Llewelyn Falco calls strong style pairing.
Llewellyn defines strong style pairing as follows: “In order for an idea to go from your head into the computer, it must go through someone else’s hands.”
In other words, the navigator is the one directing the driver to do the work. I like to think that the driver is in support of the navigator. While I’m the driver, my job is to make it easier for the navigator to do their job. I do this by dealing with the little details of typing in code so that the navigator doesn’t have to worry about it.
When I play the role of the navigator, I feel my job is to support the driver by helping them enter in code the most efficient and effective way possible. For example, if I’m aware of key bindings for actions that they are unaware of, then I may share that with them or I may help them learn a new procedure of steps by first giving them the instructions step-by-step and naming the procedure so that when we need to use it again I just refer to it by name instead of listing each step again.
The way I like to think of it is that the navigator’s job is to give information to the driver at the highest level of abstraction that they are currently able to receive. This is constantly changing for the driver at any given moment. That’s why it’s really important for the navigator to be very sensitive and make sure they’re not overwhelming the driver.
When driver and navigator are both engaged in pair programming then development can become a true collaboration and we can see really great things emerge. Not only will pairs produce code with fewer defects but they’ll also write cleaner code that cost less to maintain and extend.
Pair programming can be exhausting so I don’t recommend doing it for more than a few hours at a time. Pair programming can also be a lot of fun and very engaging when we do it well. That doesn’t mean that the magic happens every time or with every person. We have to find our best partners, that’s what will discuss in my next post so stay tuned.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Agile Infrastructure.
Previous Post: « Try It, You’ll Like It
Next Post: Swap Roles Frequently »