Pair-programming is a cheat code

I had that written on my office whiteboard for a while last year.

I had just finished working with a client for over a year where the whole team pair-programmed full-time (we also did a lot of mobbing).

I was then starting work with a new client, and I wanted to remind myself to push for pair-programming as much as possible because it is a cheat code for developers AND for businesses.

Here are some of “cheats” pair-programming gives you.

Pair-programming increases decision speed

I think this is one of the most underrated benefits of pair-programming.

When we’re building software, there are countless decisions we have to make. Those decisions take time. And frequently, they take coordination across teams. That’s really costly.

And those decisions tend to have ramifications that compound.

It’s typically cheaper for a business to change course early in the feature-development lifecycle. So, you want to arrive at the right decision as early as possible. With pair-programming, you have two people with full context able to bounce ideas off each other, challenge assumptions, and refine solutions quickly.

Compare that to finishing your feature, opening a pull-request, and waiting a few hours (or days) for someone to then question a piece of work. You go back and forth on alternatives (what you would’ve done with a pair at the moment you were coding that thing), and finally, you have to rewrite large pieces of the code because the decision made early informed the design of the whole feature.

Code-review is done in real-time with full context

It’s sad that most companies have a culture of doing code-review through pull-requests. GitHub has been a huge influence in that. And it’s a great model for low-trust environments (where PR author and reviewer don’t know each other). There’s high friction, and that’s a good thing.

But your company should be a high-trust environment. You know your team. You sync with them daily! So, to do code-review in the same slow, async way we do with open-source code seems suboptimal.

And when you’re reviewing a pull-request, you’re often missing context for the work that’s being done, decisions made along the way, and sometimes why the team is even building a given feature. So, as the reviewer, you have to either gain a lot of context to review the code well, or your review is worse than it would be if you had all that context.

Well, do you know who has all that context? The pair. And the pair can review the code as they write it.

That doesn’t mean others can’t look at the code. If you’re working on something gnarly that you want more eyes on, you can always tap another pair and ask them to do a review on a call. All of a sudden you have 4 people (2 pairs) reviewing the code while it’s being written. Very effective and efficient.

Knowledge transfer happens naturally

In programming, we’re always talking about the bus factor or domain knowledge silos. We don’t want a single developer to “own” a piece of code, and if they leave the company, get sick, or get hit by a bus, nobody else knows how to touch it.

(Also, note that they’re likely the only person who can review PRs related to that area of the codebase. Makes that PR problem even worse!)

So, teams tend to need to put a lot of effort into artifacts (documentation, videos, etc.) that can share that knowledge with other developers in case that bus really comes.

But documentation is costly and at best a proxy. Usually, it’s out of date and incomplete.

The code is the source of truth and the full specification of what our application currently does. So, it would be nice if we could rely on that. Of course, it takes time for people to gain knowledge of a particular domain in the codebase.

That’s where switching pairs frequently helps tremendously.

If you frequently switch who you pair with, that siloed context is immediately spread out across the team. The more you switch pairs, the more the context spreads. You don’t have to do anything special (other than rotate pairs).

Pair-programming is the best way to teach junior developers

And since sharing context is so easy with pair-programming, it’s also one of the best ways to teach junior developers. I’ve seen junior developers get good at an alarmingly fast pace. And they’ll ask the best questions, questions that frankly make you (the senior developer) better at your craft.

Pair-programming helps developers learn better ways to work and solve problems

The previous point leads to this one.

When you’re pair-programming, people have insight into how you work, not just the final code in a pull-request. That is phenomenal for two reasons:

• a) Others learn from things you do. Things they didn’t even know were possible! It opens minds to whole new categories.

• b) You learn from questions your pair asks! It’s amazing how a simple question can lead you to realize you haven’t re-evaluated the best way to solve a problem in many years.

(And note that we’re all switching between (a) and (b) all the time. I learn from you and you learn from me. And we both ask questions of each other.)

Is it still useful in an AI world?

Yes, yes it is!

Programming with AI is changing rapidly. How can your team learn to use these new tools as fast as possible?

I think there’s no better way to do that (and to develop best practices) than to pair a lot and rotate pairs frequently.

Think about it the other way. The more you silo information by not pairing, the slower the spread of knowledge and good practices. So, pair-programming is even more (not less) useful in this world full of LLMs.

Give it a try

There are more reasons why pair-programming is a cheat code, but hopefully those are good enough to give you a taste of the value it can bring to your team.

If your team doesn’t do pair-programming, I encourage you to give it a real try. Read a little about how to do it well (and there are ways to do it well and ways to do it poorly). And stick with it. It’s a skill that needs to be learned, so don’t expect to be immediately proficient at it.