I started pair-programming years ago, and it has become a huge part of how I code and work with others ever since. Yet, when I go to clients, the very thought of pair-programming or pairing up is met with lots of different objections. They range from things taking longer, or that it is a waste of a senior person’s time, to paying twice as much for half the work. Those are the objections, but what are my main reasons for advocating for it?

Growth and Development

The bottom line is that if you aren’t growing as a developer, then you’re losing ground in your career. For leaders, if they aren’t investing in their people, they are setting their business back, and ultimately pushing out the people who want to grow the most.

There are lots of ways to grow as a developer. You can read, go to conferences, hire a consultant, and prototype using new things. Another great idea is to pair-program. When you pair, your partner exposes you to all of their techniques and abilities. We all have little things we tend to forget over and over. Your partner may have a clever way to remember. Similarly, you can help them.

Also, lots of developers are curious about areas outside of their specialty. Front-end developers want to learn more about the cloud or server-side and visa-versa. Pairing with people who are good at other things allows people to try doing work they’re unfamiliar with while having someone experienced help.

You can pair programmers with non-technical people as well. A developer who pairs with a business analyst or someone in quality will deepen their understanding and appreciation for the skills they bring.

Risk Management

If I were paid every time I joined a team where they have a single point of failure, I’d be retired.

Seriously, organizing teams around towers of ability and knowledge are so common that one of the first things I do with groups expose the risk contained.

Here’s one example that comes up more than it should. There is a team of developers all working on a complicated product. There is one developer who has worked on this product several years longer than the rest of the team and is one of the only people who remembers how things got to be the way they are. When that person gets sick, the team slows down dramatically as nobody can ask this person questions. If this same person wins the lottery, the team will be crippled while the team tries to make sense of things without that individual. Pairing would fix that.

For developers, there is a risk when one person takes on work and then has to leave for one reason or another. The rest of the team is unable to help, and that work has to wait until the other returns. If that bit of work was critical, too bad, you have to wait. Pairing would help with this too.

Team Development

I often wind up in conversations with leaders about teams where I ask a question like, “How do you know if you have a good team,” or, “What does a team look like?” Most leaders are taken aback by those questions as they’ve got plenty of teams around them, but haven’t considered deeply what that means.

For most, a team is a group of individuals that are staffed together.

Real teams are more than the sum of their parts. They amplify the good and dampen the poor. They grow together and do what no single person could.

Making a team like that is no simple task. One simple ingredient that teams need is an appreciation for one another. Pairing together helps each other see strengths and grow an appreciation. Pairing can help bind a group of individuals into a team.

Quality

The last reason to try pairing is quality. This is probably the most common reason given to try pairing. When people are pairing, one person is deep into the code, and the other is thinking beyond it to the next steps, the design, the interplay of the moving parts.

One person’s mistake is often caught by the other. The innovation of the other bolsters a shortfall in one’s approach.

You get the best of both instead of the good and bad of one.

The quality improvement from pairing pays for the supposed lack of productivity. The truth is it is a trade. There is a dip in productivity from the pair immediately, but higher long-term productivity as the pair removes tech-debt and bugs. Anyone who has worked on a codebase older than a few years can appreciate that.

Try It

If this has helped convince you to try pairing, it is simple enough to start. Find someone else willing, talk through how you’d like to pair. Rotate your pairings every 15-20 minutes. Take a longer break after 45 minutes or so. Debrief on what you experienced.

It can be an intense and tiring experience, but I wouldn’t trade it.