Why pair programming is a practice you should NOT overlook

7 min readJan 11, 2021

Image Source: Reddit https://i.redd.it/kg3cgpznfql01.jpg

Nowadays, almost every developer in the industry is aware of a practice known as pair programming. However, it is a practice that is not as widely accepted as it should be. Though some consider it a practice not worth putting their time into, the truth is that it yields long term benefits from both a learning and relationship building standpoint. Developers tend to dismiss the idea surrounding the concept of pair programming, but it’s more than just “two developers working on one computer,” as it is essential for both building top-level software and collaborative teamwork. Whether if you’re highly experienced or an absolute newcomer as a developer, pair programming is a simple yet effective practice nobody should overlook.

But first of all, what IS pair programming?

If you have never heard of pair programming, it is an agile software development technique where two developers work together on one computer. The concept behind pair programming is that two minds working together as collective intelligence is better than one.

There are a few different methods of pair programming such as the Driver-Navigator style, Ping-Pong style (with a focus on Test-Driven Development) and Strong-Style Pairing (with a focus on knowledge transfer).

The Driver-Navigator style is both self intuitive and the most common style of pair programming that you will encounter, so let’s give an example.

We have two developers named Left and Right. Left(the driver) will be the one who is in charge of writing the code, while Right(the navigator) is the one reviewing the code as it is typed in, staying alert for mistakes while focused on the overall direction. As the session goes by, both Left and Right will switch roles frequently to avoid mental strain. The simplest way to think of it is as if you and a friend were on a road trip, and whilst one will be driving the other will be navigating with a map. Eventually, the driver will need some rest and the navigator will take over.

Though the process in producing the desired outcome is slower, a significantly higher quality of code is created. Having an extra set of eyes mitigates the chance of lazy code, resulting in better readability, fewer bugs and an overall better long-term quality of the code.

Okay… so how effective is pair programming? Have you had any personal experience?

Personal Experience

I have personally used pair programming several times throughout the course of a Web Development Bootcamp I was a part of. As somebody who was a complete newbie, I found almost every bit of it daunting. A majority of the time, the most common obstacle I faced was developing an approach to solving problems. However, through all the sessions I found that being able to work with a peer and bounce ideas off one another removed the feeling of helplessness I always had. I found myself a lot less distracted through the process, as both my peer and I would be determined to devising a solution. It kept me diligent, as the mistakes I made would be caught almost immediately, resulting in cleaner written code. Being able to see other perspectives and coding styles was insightful, and the knowledge that we shared with each other helped build confidence. It confirmed with me that I had the right understanding.

Working in pairs has been enjoyable in that it has simulated the experience of playing a video game with a best friend. We started on the same level, worked our way through countless stages of the game, improved our skills and strengthened our teamwork ability.

Overall Effectiveness

Whether if you agree or disagree, many others believe that pair programming is truly something people look forward to doing. It beats out having new methodologies shoved down your throat, and doesn’t become a “just get it done” sort of task. Sure, it can be tough at first. Working in pairs requires you to develop the right skills and mindset, as most developers are used to working independently. However, as you begin to build that skillset, you will build momentum.

Pair programming is not meant to be a mentorship session. It brings best practices to the forefront. There will be no room for lazy code, and you won’t need to re-explain yourself because it becomes readable code. The intentions of pair programming is not only to share knowledge, but to keep each other focused on the task and brainstorm when you run into obstacles. It’s more about writing the right code that is inline with the team’s practice.

It forces discussion of approaches/solutions. Vocalizing builds a strong relationship between the two developers, which creates a comfortable atmosphere where they can openly ask each other questions or speak about things they do not understand. Through this, it allow developers to reflect and ensure that they have the right understanding, or if they have a good solution.

It also facilitates the onboarding process of new team members and creates a better work culture. Not only will knowledge be shared amongst one another, but new team members will be thrown right into the mix and learn about the project, get to know the business and the organization with the help of their peer. Changes in teams can impact workflow, but people really just need time to get to know each other. Pair programming minimizes that impact because there is a lot more communication involved than working solo. The increase in communication also allows the team to possess a great personal chemistry and a distinct team identity, resulting in a much stronger workflow.

Collaborating with different developers ultimately grants collective code ownership. When the set of developers are constantly changing, the codebase becomes more consistent than with independent coders, as developer’s coding styles can differ. It increases the likelihood that a team member could make a change anywhere in the codebase and feel comfortable doing it without breaking it.

Hmm. Pair programming in theory seems legit. However, do you have any statistics on the outcome?

Most definitely! In 1999, an experiment to validate the quality and effectiveness of pair programming was conducted, which involved a group of senior software engineering students. All students received the same instructions and attended the same classes. The students were then split into two groups, composed with the same mix of high, average and low performers. One group would consist of individuals, while the other group would be collaborative pairs, all working on the same assignments.

Table data of results from the experiment. Image Source: http://sunnyday.mit.edu/16.355/williams.pdf

At first, adjusting to the collaborative work seemed tedious. Students were skeptical of the benefits that would come from pair programming. They often wondered of the difficulties of adjusting to the other’s work habits, their style and ego, the disagreements they may face on methods of implementations, and the overall additional communication required. After all, prior to the experiment, they had become so used to working alone. However, as they progressed through assignments, they started working as a collective unit and learned to overcome the urge of grabbing the mouse or keyboard and taking control.

Contrary to the students initial skepticism, the 1999 experiment concluded:

Some may question the value [of pair programming] if the collaborators do not perform “twice” as well as individuals, at least in the amount of time spent. For instance, if the collaborators did not perform the task in half the time it takes an individual, it would still be more expensive to employ two programmers. However, there are at least two scenarios where some improved performance over what is expected or possible by a single programmer may be the goal: (1) speeding up development and (2) improving software quality.

Wow… Pair programming really seems to be the hit. I’ve never done it before but now I’m eager to try. What are some things to keep in mind?

#1 — Trust the process!

No matter what you may hear, the most important thing to remember is to trust the practice. It’s proven to be an effective technique in various cases. Pair programming is meant to be a collaborative technique, and the people involved must work well together. If you’re the stronger developer, it will be easy to feel that productivity has declined due to your peer. Vice versa, you might be afraid to express opinions and contribute when you have a weaker understanding. Stay open to the experiences you come across through this practice!

#2 — Just because you have another person watching what you do, doesn’t mean it’s a bad thing.

Not everybody has the ability to review over everything they have written as they go. There will often be blind spots that immediately become apparent to a peer, and that peer does not need to be a Senior developer to provide feedback. Juniors can also share their methodologies/implementations that can quicken your skill development.

#4 — This practice will keep you focused.

It’s very easy to get off track, especially when working on independent activities. Working with a peer helps diminish inactivity by creating a work rhythm that maximizes your skillsets.

#5 — You’ll always learn something.

There is an abundance of different ways that problems can be solved in Web Development, but nobody is knowledgeable to the point of being familiar with every single method. Every developer brings a unique perspective to the chopping block, and a consolidation of experiences can promptly result in a high quality solution.

Final Thoughts

As I’ve mentioned from my personal experience, I highly suggest pair programming as it is vastly effective in learning and productivity. Though of course, you shouldn’t pair program every single problem, as the possibility of becoming dependent on working with a peer is a concern.

What you should keep in mind are the priorities that your team may be focused on when working on a project. Remember that there is a time and place for everything. If your team needs to push an MVP (Minimum Viable Product) with haste, then it is better to save pair programming for the later stages of your product. It is up to you to decide when the most opportune time to utilize this technique will be, but you will inevitably see the most value when using pair programming to face more complex problems.

As the old saying goes: “A problem shared, is a problem halved.”