Pair Programming: Tech's Best Friend or Biggest Nightmare?

Pair programming is a popular method some companies use to improve the coding skills of their software development staff. But is it all it’s cracked up to be?

What is Pair Programming?

Let’s get a clear picture of what pair programming is.

You have a pair of developers working together, each in a different role: one “driver” who writes the code and one “navigator” who reviews the code and maintains a sense of direction for the coding session. Both people are working alongside each other, and they periodically switch roles. The goal is that, since the work is being reviewed in real time, the code quality will improve.

Traditionally, pair programming can be done “hip to hip,” with the driver and the navigator sitting very close to each other, sharing a monitor. Of course, this physical set-up is a bit cramped! Nowadays, pair programming is typically done with screen sharing or remote desktop access, so that the devs don’t have to sit so close together, or even work from the same location! In other words, pair programming is accessible to remote staff and distributed teams.

Some developers feel strongly that, while pair programming can be a great tool when used intentionally in specific circumstances, it may be a horrible method to use across the board, as a teamwork default. Time for a pros and cons comparison! Let’s look at the upsides of pair programming, and then cover its common criticisms.

Upsides

1. Two heads are better than one

When you work independently on a problem, you are limited by the bounds of your own creativity and knowledge. And when you stare at a problem for long enough, it becomes more difficult to see the situation in a new, creative light. In other words, someone else will be able to see options and roadblocks that you don’t. This is called the Einstellung Effect: the longer you look at a problem, the less creatively you approach it.

With pair programming, the Einstellung Effect is less of a concern because you’re working alongside another person who gives feedback on your code, and you give feedback on theirs. Two heads are better than one! If you’re working independently, we recommend setting a limit to the amount of time you work solo, to avoid getting stuck for too long.

2. Learn from each other

Programming in a pair also helps you learn new coding methods, strategies, and shortcuts because you’re observing how someone else does their work.

And it’s more effective than someone sharing their tips and tricks with you just by explaining them, because you get hands-on practice! So the things you pick up are more likely to stick and help you improve your own coding game in the long run.

3. Gain institutional knowledge from a seasoned expert

For new staff, it can be super useful to pair program with an experienced member of the team. This can be a form of onboarding or temporary mentorship. The new dev will more quickly learn where things are, how to access certain resources, and the best methods for addressing certain company challenges. Using pair programming as part of the onboarding process can be great.

4. Prevent siloing

When everyone on a team works independently, this can lead to knowledge siloing: no one knows what other people know. This means that when you lose a “tower of knowledge”, even temporarily, you lose their expertise.

Pair programming curtails this issue because it involves sharing knowledge and methods across team members. When multiple people know how something works, your team has more sources of wisdom when one particular person isn’t available.

5. Increase camaraderie

Pair programming helps teammates bond, especially in a remote work environment. In the age of awkward virtual coffee hours, shared projects help us connect with each other in a more comfortable, authentic way.

Downsides

Of course, there are some downsides to pair programming that can make it difficult to rely on.

1. Interruptions

First, a lot of the coding process relies on uninterrupted focus. While this is true of all career types, it is especially important that we let our coders get into a flow state if we want them to be efficient. Disruptions to the coding process make it inefficient, and unfortunately, pair programming can be a heap of disruption!

Collaboration can be helpful, but only to a point. There comes a time when two programmers could be working on different projects independently, instead of working more slowly on one shared project.

Solution: Consider why you think pair programming would be useful for a particular project or set of coders. You need to be clear on your objectives! Why are you choosing a slower process (pair programing) over a faster one (working independently)? Once you’re clear on the reasons, set a limit to how much time the coders will spend pair programming, so that the project isn’t ground to a halt.

2. Hand-holding

There’s also the issue of some staff using pair programming as a crutch for their work. Having a self-starter attitude is essential in software development, so if someone isn’t comfortable working by themselves, it’s a problem. Don’t let pair programming become an everyday work style for the same staff members, over and over again.

Solution: your org needs to have a culture of go-getterness and empower everyone to contribute equally, according to their talents. If a team member seems overly reliant on pair programming, check in with them to ask what’s going on. It’s possible they're lacking confidence in their skills and need to be reminded of their value, or they might just enjoy the company of their programming partner and need to manage social time vs. work time better.

3. Poor attitudes

With pair programming, it’s possible that not everyone will be a good sport about it. Pair programming requires openness to collaboration and working at a slower pace. For some coders, this situation is a nightmare, and they want no part in it. Don’t force them!

It brings down morale when one person is willing to pair program and the other isn’t. The first person might feel socially rejected and the second person could become frustrated. If this dynamic becomes the norm, it could hurt company retention. And of course, a stubborn attitude from one programmer can further slow down the project.

Solution: You should only pair programmers who are excited to collaborate. And if pair programming is important to the goals of your org, get more people onboard with the work style by encouraging a culture of constant collaboration, outside of pair programming. If a team is more comfortable sharing ideas and giving feedback, they will probably be more open to pair programming, even temporarily.

4. No growth

It’s possible that the paired programmers might not learn anything from the process, in which case, the paired setup was a waste of time.

Solution: In order for pair programming to be most effective, you need to have one of two situations:

1. The partners need to be learning from each other, or
2. One person needs to be mentored by another, with the second person working on their mentorship skills.

In other words, there should be some difference in the partners’ individual knowledge bases and experience level. To make this dynamic possible, avoid partnering people who have near-identical skill sets and work backgrounds.

Conclusion

While pair programming can be a slower coding strategy, more work up front can save you time in the long run. If you’re clear on why you want to implement pair programming and you find good partnerships, the strategy can improve your team’s workflow.

--

If you want to stay up to date with all the new content we publish on our blog, share your email and hit the subscribe button.

Also, feel free to browse through the other sections of the blog where you can find many other amazing articles on: Programming, IT, Outsourcing, and even Management.

Interested in hiring talented Latin American nearshore developers to add capacity to your team? Contact Jobsity: the nearshore staff augmentation choice for U.S. companies.