One of the topics that came up the most in our podcast this year is pair programming.
Pairing is one of the core practices advocated by Kent in extreme programming, and Farhan told us it is widely adopted in Shopify, too. It was also recommended by Greg, and DHH said it inspired how he uses AI these days.
This shouldn’t be surprising — all studies about pairing (which go back to the early 2000s) report overwhelming benefits across happiness, growth, code quality, and even overall productivity.
Yet, it is still kinda surprising, in 2024, to hear about teams and people pairing regularly.
Why is that?
Farhan argues that pair programming is the underhanded free throw of engineering. Underhanded free throws have been proven to be better than normal free throws at everything except one thing: they look stupid.
And pair programming does look stupid, to everybody:
💼 To managers, it feels like a waste — it's two devs working on the same code, when they could be doing two separate things.
🔨 To developers, it feels uncomfortable — social interaction is draining. And what about the sacred state of flow?
Nevertheless, several extremely successful companies pair regularly, or most of the time, or even all the time. In some cases, they have been doing so for decades, and they loudly advocate the case for it.
So, this article is my best attempt to demystify pair programming and tell you everything you should know about it:
If you pair already, this is the piece you will send to your skeptical friends.
If you don’t pair, this is the piece that will make you a convert, or will at least make you try.
Here is the agenda:
🏆 Why you should pair program — let’s talk about productivity, knowledge, happiness, and soft skills.
📖 How to pair program — the most popular techniques and when to use them.
⏱️ How to plan for pair programming — what goes into a session and how to make it successful.
🔨 Tools for pair programming — please don’t pair on Zoom. A short list of the best tools to elevate the pairing experience.
❓ FAQs — a greatest hits of the most frequent questions I get about this, including how to allocate resources, whether should managers pair, should you pair remotely, and more.
📚 Resources — further guides, articles, and papers to learn more.
Let’s dive in!
🏆 Why you should pair program
Pair programming is consistently adopted by some of the best engineering teams in the world. The degree of adoption varies: from those who pair regularly, like GitLab, GitHub, Atlassian, and Shopify, to those who pair most of the time, like Thoughtworks and Pivotal.
You will notice that companies that pair also usually write about it (see links above). They advocate for it. They act like they uncovered a secret and want everybody to know.
The benefits reported by these companies can be organized in four main categories:
🏃♂️ Productivity
📖 Knowledge Sharing
❤️ Happiness
🎽 Soft skills
Some of these are to be expected, while others are wildly counterintuitive. Let's see them one by one.
1) Productivity 🏃♂️
The metric for successful programming is not the number of lines of code, but the ability to solve a problem in a maintainable, and understandable way for the long term.
– “If you have two engineers on one computer, won’t they type half as much code?“
– ”I hope even less than that”Farhan Thawar, VP of Engineering at Shopify
But still, let’s talk about output. Various studies [1, 2] suggest that the raw output of a programming pair, in terms of tasks they are able to accomplish, is only 15% smaller than that of two independent developers.
This is somewhat surprising. Why only 15%? For two main reasons:
Less distractions — two people are less likely to get distracted than one. That short trip to Instagram doesn't look all that appealing when there is someone else by your side. Also, if you lose focus or get interrupted, the other can remain in a flow state, and quickly bring you back in.
More awareness — when working for hours on a problem, you might lose perspective of the main task. Remember that time you spent all afternoon on a bug and then fixed it in 10 minutes the morning after? That’s when the “state of flow” gets toxic and turns into tunnel vision. This doesn’t happen in a team of two.
That said, this 15% gap is easily repaid down the line by three main factors:
No code reviews — the code you produce is automatically reviewed by your peer. No blocking PRs to stop you from shipping. Also, this kind of review is way better than your regular PR.
Less WIP — assigning more people to tasks means there are automatically less tasks in progress at any given time. Less tasks in progress equals less context switch, less batching, more focus, and better output.
More quality — pair programming consistently leads to higher code quality. Two people bring in better problem solving, which leads to better design. This in turn brings in less bugs, less bad abstractions, and less time spent on maintenance over time.
2) Knowledge Sharing 📖
Pair programming is a phenomenal knowledge sharing device. There are at least three use cases for which such sharing is valuable: