Choose your language:

France
Germany
Hong Kong
India
Ireland
Japan
Malaysia
Netherlands
New Zealand
Singapore
Sweden
United Kingdom
United States
developers work in a pair programming style

Pair programming: Annoying management fad or surprisingly good idea?

April 2, 2018

By Jordan Schwartz

At first thought, being told to pair up with another developer to work on the same code—at the same workstation—sounds tricky (not to mention, like an introvert’s worst nightmare).

However, it might be time to give pair programming a try. We’re increasingly seeing companies insist on the practice, which turns out to be a lot more efficient than it sounds given the right circumstances. More critically for you, many developers report being wary at first but then taking to the practice.

Why pair programming might be more than a fad

If you’re presented an opportunity to work with a company that uses pair programming, you may be thinking, “No way in [bleep] I’m working in a pair”—but hear us out. The benefits you receive may outweigh the initial annoyance of having to work closely with another person. When pair programming programs are executed correctly, companies are able to push products out faster—and developers report many career benefits, including soft skills development critical for advancement.

Pair programming’s time has come, in part because of the tools that allow developers to rapidly deploy to test environments have grown up. However, that speedy deployment is starting to outpace developers’ ability to craft code and onboard less experienced team members.

Eliminating bottlenecks and improving productivity

In a perfect world, a code review wouldn’t take a week or more to get feedback back to you; feedback would be immediate and continuous. Voila! Pair programming delivers exactly that.

Also, forget about going down the wrong path only to realize it weeks later. Pair programming can dramatically save time by incorporating feedback much earlier in the process; thus, you’re much less likely to produce problematic code.

Increasing code quality and distributing knowledge

Continuous code review logically produces higher quality code. Working with another developer holds you to a higher standard and also provides a second set of eyes to notice potential bugs that could have taken you a day or two to find.

A common issue dev teams run into is that one superhero developer who the team relies on to know everything. What happens when they aren’t in the office? Pairing helps distribute that knowledge across the entire team—communication dramatically increases and everyone is informed about the project, infrastructure and dependencies.

Transferring hard skills and improving soft skills

Pair training is inevitable when two developers are paired together with different levels of skill—the knowledge flows naturally. In essence, formal training time has been replaced with development time, and you and your team will write higher quality software, understand the incremental addition of capability and performance of features, and move faster as a unit.

Even though you may not think your soft skills need work, some developers report that pair programming significantly enhances them. “While in a pair, I’ve seen growth in my communication skills,” says Adrian Gonzalez, a developer who works as a TEKsystems consultant. “I’ve learned how to give constructive criticism and I can better communicate what I am trying to accomplish.” Providing feedback may feel uncomfortable or awkward at first, but it will soon become natural, and this skill is critical for growing in your career.

Embrace the change to reap the rewards

As with any work style change, there will be a few kinks to work out before developing an operating rhythm within a pair. Be open to switching pairs and working with someone below or above your experience level. Successful programs include developers who are willing to experiment, and a process to gather and use data on what's working and what isn’t.

If you’ve joined a project that’s implementing pair programming from scratch, try to stay positive and cooperative. It’s challenging to execute at first, but in most cases the juice is worth the squeeze. 

Have you tried pair programming? We'd love to hear what you thought of the experience—good or bad—in the comments.

Related content

Competing for developer roles in DevOps environments

 

Blog Archive
20172016201520142013