Me: “Hey team, I know I’m new here, but I’ve got this great programming practice we should use. It’s called pair programming!'“

Team: “That sounds great, when can we start?”

…said no team ever.

When I started with my last team, I had to make a case for this risky new practice. I hadn’t read Extreme Programming Explained and I hadn’t extensively paired before, but I had read that this could change how software engineers work by increasing quality, learning, trust, and value. I decided the best way to run this experiment was to find a junior level engineer, ask what he was working on, and just pair with him for the day.

I don’t recall what problem we were solving, what code we wrote, or any specific details about our interaction during the day, but when we wrapped up and began to leave for the day, I remember that he turned and said to me:

I learned more today pairing with you than I have on my own for the last month.

I took a moment to enjoy that statement, then said to him, “tell that to the Director of Development.” He did, and that was the beginning of my team’s journey to pair programming almost all the time.

It was a more difficult case to make for two highly-paid senior engineers working together, but I started small. I suggested we try designing our code from a high level as a group using our trusty whiteboard. We found that the design sessions sparked discussions of what we ought to do and why. We began to develop a debate culture where we discussed pros and cons, patterns and principles, and began to trust each other to be wrong along the way to getting it right. I would invite a colleague over to my desk to review my code with me, and the resulting discussion would yield improvements in design and readability. My teammates took notice.

The transition into pairing between senior engineers was far more seamless as a result, because complex tasks benefited from the varied experience that multiple engineers bring to the table. Eventually, pairing was the rule and there were only two reasons we would work individually. The first was to write code whose design was entirely predictable because we were following team patterns and paradigms and there would be little need for debate. The second was simply because we sometimes had an odd number of engineers, so we tried to give tasks that met the first criteria to the odd person out.

That team was the most high-performing team I’ve ever been on. We built trust. We avoided knowledge silos. We were comfortable changing our minds after an intense debate. We produced higher quality code that was well-tested and was easier to understand and change later. We saw many other benefits, but the bottom line for the business is that we built valuable software much faster.

If your team uses pair programming, how did you get started with it? What resistance did you meet and how did you overcome it? What benefits does your team yield as a result? I would love to hear your stories in the comments!

Photo by NESA by Makers on Unsplash