When asked:”What’s the best thing I can do right now to improve my code quality” I always answer: code reviews. A code review is the best bug preventer out there. And even more, I like its older brother better: Pair programming.

Because if a code review finds bugs after the fact, working in pairs finds bugs as they enter the code. The discussion on design options usually results in a better design, and there are more people who can support the code, because not only two people have seen that code, but also discussed it.

Most of my life I didn’t pair program, apart from doing it informally, like working on a bug. At Typemock, I did it most of the time, with no special methodology. Didn’t have a pilot or navigator. Just working together on different problems.

As I’ve gone back to pairing recently, I found it different than before. Apparently I’m more alert to how the process works, whereas before I’ve just gone along for the ride.

So here are a few things I’ve noticed this time around. It was mostly as a pair to an expert, and a few times leading the pair

• Atmosphere. Going into a session, you’ll feel how it’s going. It’s based on how attentive you are, how is your partner is, how much both of you know the problem domain and code. How you get on from here relies on your starting point.
• Patience. This coming from someone who doesn’t have much of it. I don’t recall if it was this way a few years ago, but man, I needed to work hard at it. When I was the expert, I needed to explain in length without making it sounds like I’m bored.
• Nodding works. When I wasn’t the expert, taking on the role of a rubber duck, coaxing the driver to explain the problem and solution, provided a solution many times. Of course, that required me to shut up, which wasn’t easy.
• Safe silence. When I wasn’t the expert, I found myself weighing in if to ask a question or not, fearing it might sound stupid. Silence offers safety. I coerced myself to ask some questions, qualifying it with “I know it maybe a stupid question, but…”. Results varied: Sometimes it pushed the discussion forward, sometimes got a “yes, it is a stupid question” look.
• Attitude matters. Mine of course, but how the partner behaves has much to do with the success of the process. For example, when working with an expert, I’ve noticed phrases and gestures that made me think I was slowing the process at times. I had to fight this off in my head, or shut down. When I was the expert (or more knowledgeable from the partner) I had to resist conveying the same feeling. Both were hard.
• Partners matter. From the soak-everything-in to the know-it-all, there are no perfect partners. Some are more compatible than others. You may not have a choice with whom to pair, but there’s a learning and growing opportunity with all.
• Negotiations. Collaboration, even in this level, is about give and take. Based on the atmosphere you’ll decide when to push topics, from naming to what to test. Your partner may agree, disagree or raise you five. Be ready to accept losses on the way to completing the task.
• Undebated truth. When leading a pair with a junior person, many things I said sounded like a fact. Non-debatable fact, no reason to discuss, just plain truth. This is really dangerous. We should encourage questions, embrace peeking and poking in our vision. Still, I found it hard to stop moving forward based on my assumptions.

Pair programming isn’t just a development practice. It’s skill, which we can improve and reflect on to choose our way. It’s still worth the time spent, just like unit testing. And like unit testing  – It requires a lot of discipline. Discipline to ask when it’s awkward, to stop running when feeling sure and to give up sometimes, to win other battles.