7 Ways to Win with Pair Programming

One of my recent articles was a tongue-in-cheek tutorial entitled, "10 Ways to Kill Pair Programming". I've always been more interested in focusing on solutions instead of problems, so I can't just release an article like that and not follow up with some suggestions on how to make "Pair Programming" work.

I started to learn computer programming around 1986 with my good friend, Garret Hamann. We didn't know it at the time, but we were practicing a technique that would soon be known as "Pair Programming". Garret learned from his dad who was an engineering student at Vanderbilt (probably via pairing). Garret transferred what he knew to me when we would pair for hours on the weekends. We would write RPG's on my Commodore 64, taking turns on the keyboard, talking, arguing, learning. Then we would re-write those games on Garret's Apple II. What a great way to learn to code!

"Pair Programming" is kind of a big deal these days. Adoption is widespread, especially amongst those who run in Agile circles (ever increasing, thankfully)… and with good reason. The benefits are huge. I can attest to that from experience.

My friend, Colin Callahan, and I started Acklen Avenue back in 2010. Right out of the gate, we decided to take a stand on a handful of practices that we were certain produced higher quality code and better team experience. Pair Programming was one of those practices. Since then, it has paid off in SO many ways. We are now 50+ in size with almost no team turnover and we are consistently cranking out quality products. Pair Programming is to thank for much of our success! Here are a few wins that we get every day from Pair Programming:

TRIBAL KNOWLEDGE: Even if you never switch pairing partners, your team feels the benefits or pairing simply because you're not the only person on the team that knows how a section of code works. If you get hit by a bus or win the lottery, your team has another way to access your knowledge through your partner.

NO NEED FOR CODE REVIEWS: Code is reviewed as it's written. This provides a much more thorough and meaningful code review process and saves time.

BETTER DESIGN MEANS LESS REFACTORING: Two heads are better than one, no matter how smart you think you are. When done right, pairing partners can help each other make better design decisions as the code unfolds. Because the code is designed better, you will naturally have fewer needs to go back and refactor code.

CONSISTENT FOCUS: Ever feel like your focus is waning? It happens to everyone, but it doesn't always happen at the same time for everyone. When pairing, when one partner's focus begins to suffer, the other partner can help keep the ball rolling with a word or two. Better focus means more forward progress.

Without realizing some of the benefits, it might be easy to look at "Pair Programming" as a waste of time or a productivity reducer. But, in fact, coding in pairs make the overall software development process much more efficient and enjoyable.

In my earlier article about "Pair Programming," I proposed some ways to kill it off. Today, I'd like to suggest a few ways to help your team thrive in pairs.

BE WILLING TO LOSE:When you have an opinion and your pairing partner has an opposing opinion, you should talk it out. Maybe draw some circles and lines on the whiteboard. The goal is to arrive at the best decision, not for your opinion to be the winner. Sometimes, the best decision might be to stop discussing it and pick one. After all, you can always refactor later if it turns out you went the wrong direction. Being willing to lose is an essential part of working as member of a team and is even more essential for pairing.

BE AN ENCOURAGER:You like to be praised for a job well done. Give the same consideration to your pairing partner. Take opportunities to build him/her up in front of the team and make it genuine. Talk about your partner more than yourself. Call attention to his/her best contributions.

VOCALIZE CODE: Code certainly isn't English, but we all have the ability to speak an English version when we're explaining code to someone. Instead of coding silently, vocalize as you code. Keep a constant conversation going. If the only sound in the room is fingers on keys, you're doing it wrong.

EXPECT AND ACCEPT CORRECTION: Part of the huge benefit to pairing is the combining of two sets of experience. The only way to truly tap into that combined experience is to correct and discuss. Expect your pairing partner to question your decisions. When they do, put your pride in the trash can and discuss it like you care about the project more than your own opinion. If your partner isn't starting discussions, start them yourself and invite him/her to interrupt at any moment.

LEAVE SOME SPACE: Even though it's a good practice to correct and discuss while pairing, it's not so good if you go crazy with it. If your partner misses a semicolon or enters a typo, give them more than a half second before chiming in.

ALLOW SPEED DIFFERENCES: Some programmers like to zip through code like it's a race. Other programmers take their time and move at a much slower pace. Decide as a pair how you will handle the differences in speed and stick to it for an entire iteration. If you're vocalizing your code, you will naturally slow down at some points and speed up at others. The main thing is to respect your partner's pace.

SWAP DRIVERS OFTEN: Being in the driver's seat is admittedly more fun. With that in mind, swap seats every so often. If your partner doesn't request it, you should offer it.

For more information on "Pair Programming" and how to make it work for you or your team, check out these great articles: