What Developers Really Think of Pair Programming

Truth be told, many developers will tell you they prefer to work in an environment without meetings, colleagues, or even meals (see: Soylent) to distract them. But pair programming, an agile software development technique, might be an exception—or at least a worthwhile technique for facilitating better code outcomes.

For the uninitiated, pair programming involves two developers—often one more junior and the other more experienced—working together at a single workstation. Formally, the “driver” is the one writing the code, while the “navigator” reviews the code as it’s written. When the driver is a junior engineer, pair programming can be beneficial because errors are caught more quickly, not to mention it can help to build their confidence by offering real-time feedback on their work. When it’s the other way around, and the junior developer takes a step back to be navigator, they can learn more quickly by observing how their colleague thinks about the problems at hand and translates them into code.

Opinions about pair programming are all over the map, as some organizations swear by it while others swear it off. And individual developers have their fair share of thoughts about the technique as well. At Hired, in addition to thousands of data points about the hiring process for technical talent, our unique access to developers around the world allows us to collect deep insights about the state of software engineering, and the thoughts and opinions of the people who do it every day. We surveyed more than 700 developers for our 2019 State of Software Engineers to offer some interesting insights into when pair programming works—and when developers think it falls short.

When it works

Pair programming can be an incredibly useful tool for junior developers to learn quickly, so it’s no surprise that a significant number of developers prefer companies that offer it. According to our data, 48% of engineers would be more interested in working for a company which offers pair programming. And it’s not necessarily just junior developers who benefit; about half of respondents said they think it’s more efficient because it allows teams to catch bugs along the way.

Additionally, there are some “softer” benefits to pair programming—that is, not necessarily having to do with the code ultimately produced. For example, pair programming can facilitate relationship-building and moral support between team members, enable colleagues to share best practices, and make it harder for developers to procrastinate or get distracted while coding.

When it’s less than ideal

Pair programming doesn’t work for everyone, though. Our data found that approximately 4 in 10 developers think that while pair programming is good for junior engineers, it doesn’t benefit people with more experience. Furthermore, 1 in 5 believe that pair programming can leave one person doing all the work, and 14% of respondents believe it enables sub-par developers to go unnoticed as they lean on their partner and never develop the skills to successfully “drive” on their own.

The right balance

As with most things in the workplace, finding the most effective techniques for individuals, teams, and companies is a matter of testing things out to see what works—and constantly providing feedback as teams grow and evolve. Pair programming can be an incredible learning tool for junior developers, so if you’re still building your skills it may make sense to look for companies which offer this as an opportunity. If you’re more advanced, on the other hand, pair programming may not benefit you directly, but there’s a good chance it’ll be valuable to your team’s productivity and effectiveness, so it’s worth at least being open to giving it a shot.