Pair programming is a programming technique where two software engineers collaborate on a piece of software simultaneously. In an office, this is done at a single workstation where the two engineers sit side by side. Remotely, this is done through a communications channel like Zoom, Hangouts, or Teams, and a collaborative IDE like the Live Share extension for Visual Studio.
The two engineers each take on a role when pair programming. One engineer is the driver who writes the code and makes tactical decisions. The other is the navigator, who reviews the code on the go, gives directions, and stays focused on more strategic decisions. Unless one engineer is much more experienced than the other, both engineers should frequently switch roles to stay engaged and share the different workloads equally.
The Benefits of Pair Programming
Pair programming is a controversial topic because it doesn't work in every scenario. It's not something you can simply start doing without considering how to do it. It's a skill that takes some effort to get good at. But the benefits of pair programming are genuine.
First, it improves the quality of your software. A meta-analysis found that pair programming leads to higher-quality software when compared with solo programming. This makes intuitive sense, because you have two sets of eyes looking at the same code at the same time.
Second, pair programming speeds up knowledge transfer between engineers. There will always be differences between how you program and how someone else programs, even for the simplest of applications. You'll always learn something new by watching someone else program and being able to ask questions about why they did something a particular way.
Third, when done correctly, pair programming ensures that engineers are intimately up-to-date with the entire codebase. No engineer works on a piece of code entirely on their own. Instead, they work together with other engineers and, in the navigator role, have to consider how any particular feature fits within the larger codebase.
Fourth, pair programming helps to quickly onboard new team members. When a new engineer joins a company, it can take a while before they're familiar with the codebase. Not only does pair programming speed up this process, but the engineers will be able to hit the ground running with the help of someone who's already familiar with the codebase.
When Does Pair Programming Not Work?
Let's start with when you shouldn't do pair programming:
- When you need to be in the zone. Sometimes you just need to crank out some fresh code and you're better off doing it on your own versus collaboratively.
- For routine or simple tasks. Pair programming is quite intense and may not be worth the mental effort for tasks that you can easily do on your own.
- When you have extremely tight deadlines. Although pair programming often results in better-quality code, it can take a little longer to get there.
- When the engineers aren't compatible. Not all engineers work equally well together. Always ensure there is a reasonable match between the skill levels, experience, and work styles of both engineers.
When Does Pair Programming Work Best?
Pair programming is the most effective in the following scenarios:
- For complex problems that require brainstorming. Two engineers can come up with more and better solutions than one engineer. Scenarios include algorithms that touch many parts of a codebase or have intricate business logic.
- For fast test-driven development (TDD). There's a pair-programming scenario called ping-pong where one engineer writes code along with a failing test for that code. The other engineer then takes over and rewrites the code until it passes the test, then writes a new failing test for the updated code.
- When writing high-stakes code. Especially for code related to security or performance or a business-critical feature, it's better to have two engineers working on the problem over one. Their combined knowledge will drastically decrease the chances that something goes wrong.
In Conclusion
Pair programming isn't necessarily a must-do. But as long as the two engineers communicate properly, set good objectives for every session, and take frequent breaks, it can be a great tool in an organization's toolbox to improve the quality of its code.
