The Advantages and Challenges of Pair Programming
Pair programming, as the name implies, is when two developers work together on the same piece of code on one machine. There are many different strategies when it comes to pair programming.
Pair programming is a widely adopted programming technique. A lot of big companies use pair programming, while others stay away from it. It is, and probably always will be, a topic of debate.
Why should you even bother doing it? And what are the challenges of pair programming?
Why Should You Pair Program?
When pair programming is done in the right way, it comes with a variety of benefits.
Knowledge is constantly shared between developers. Since developers should be vocal about the decisions that are being made, giving feedback or suggesting a certain solution can be done at any point during the session. This is a great way to learn how other developers think about solving certain problems.
Besides the fact that programming knowledge is shared, knowledge of the codebase is also shared between developers. Sometimes there is only one developer capable of working on a project because this developer is the only person in the team that knows the codebase. Pair programming could also be a way to introduce other developers to the codebase of a project.
Two heads are better than one
When two developers work on the same problem, less time is spent figuring out a possible solution when a hiccup appears. Chances are one of the two developers already knows how to fix the problem from previous experience.
A solution is not always directly available, especially when working on complex problems. With pair programming, there is at least double the capacity to tackle the problem and discuss solutions.
Fewer coding mistakes
When looking at the code with two pairs of eyes, the number of bugs should be reduced. Another benefit is that a code review is happening on the fly. Instant feedback from another developer should produce better code. Coding standards also tend to be followed more consistently when working in pairs.
Harder to get procrastinate
When working in pairs it is harder to procrastinate on your work. You can’t just stop working on your programming task and start typing an email or check your WhatsApp. Working in pairs results in better focus, and this will get things done more quickly.
Challenges of Pair Programming
Although pair programming could be really beneficial for your team, it’s not for everyone. And when pair programming is not done correctly, it can be an ineffective use of resources.
Both developers should be involved
When pair programming, both developers must be actively engaging with the task throughout a session. Otherwise, no benefit can be expected.
An often-raised objection is that pair programming doubles the costs. It is basic math. Two developers work on a piece of code instead of one. This is a big misconception since programming is more than just typing code. However, you should be aware this is the worst-case outcome of poorly applied pairing programming.
There have been studies about the costs of pair programming. These studies have shown a 15% to 100% increase in baseline development costs. The additional costs may be offset, at least in part, by increased quality and less rework. However, teams that are considering to introduce pair programming must account for potentially higher initial development costs.
At least the driver, and possibly both developers, are expected to keep up a running commentary. Pair programming is most effective when it is done by “programming out loud.” The driver should be vocal about the decisions that are being made. If the driver is silent, the navigator should intervene.
You can’t force people to pair program
Don’t overdo it. Pair programming is something that cannot be forced upon people, especially if relationship issues are getting in the way. Issues should be solved before you start to pair program.
How Pair Programming Can Help You Grow as a Developer
The most common strategy of pair programming is the driver/navigator strategy. One developer is behind the keyboard and typing the code. We call this the driver. The other developer is the navigator. This person is also actively involved in the programming task but guides the session along.
The navigator should help the driver be able to explain their thought process. While the driver is typing code, the navigator is responsible for checking the code. You can look at it like very small code reviews. Checking for syntax and typos prevents the session from getting derailed.
This strategy is really valuable as a mentorship-and-learning tool. An experienced developer could fulfill the role of the navigator, while a less experienced developer can be the driver. This way the experienced developer can mentor the less experienced developer through the programming task.
Roles can be switched frequently during a session.
Effectively Making Pairs to Pair Program
Two experienced developers
A pair formed by two experienced developers might seem the obvious way to go. But this isn’t always true. While two experienced developers should be able to produce great results, it often gains little insight on new ways to solve a problem. It is unlikely that both experienced developers question established practices.
Experienced and less experienced developers
As previously described, pairing an experienced developer with a less experienced developer is a great way to improve for the less experienced developer. This combination can bring a lot of new ideas since the less experienced developer is more likely to question established practices. Since the experienced developer has to explain these established practices, this developer is also more likely to question them.
A pair-programming session between an experienced and a less experienced developer shouldn’t become a “watch the master fix it” show. This will slow down the conversation between the developers and mitigates the benefits of pair programming.
Two less experienced developers
Two less experienced developers forming a pair can significantly improve the end result of a piece of code, though in most cases this isn’t the preferred situation. It is harder for less experienced developers to come up with a good solution without the help of a more experienced developer acting as a sort of role model.
“Alone we can do so little; together we can do so much” — Helen Keller