Pair programming is a development technique wherein two programmers work together at the same workstation at the same time, discussing the work as they go. While the technique can lead to new perspectives, knowledge sharing, and increased code quality, it is a tool, and not a silver bullet, said Todd Merritt, a software engineer based out of Nashville, in a recent session at the 2019 CodePaLouSa conference in Louisville, Kentucky.

“There are certain specific use cases where it’s great, and others where it’s not, and it can become expensive if you do it wrong,” Merritt said.

SEE: Six in-demand programming languages: getting started (free PDF) (TechRepublic)

Pair programming can be costly at first, as it requires two developers working on the same project, but the long-term benefits may be worth it, Merritt said.

Benefits of pair programming include collective code ownership, team building, a reduction in calendar time, knowledge transfer, and a focus on quality over quantity, Merritt said. The technique also prevents silos, and acts as a constant code review, with quick turnaround on feedback to prevent errors and reduce poor programming practices.

A good pairing partner is a strong communicator, willing to fail, asks good questions, accepts productive criticism, controls their ego, and trusts their partner, Merritt said. When pairing, developers should talk about everything related to the system, from unit tests to system design to basic requirements.

Despite the benefits, sometimes developer teams need to justify the cost of pair programming to their organization, Merritt said. Here are several common reasons when pair programming is a good idea:

  • Complex or mission-critical systems

  • Systems that involve constant change and volatility

  • Shared code and libraries

  • High-risk deadlines

  • Knowledge transfer/mentoring

  • Onboarding team members

  • Technical interviews and phone screens

Times when it does not make sense to pair program include simple tasks, nonproduction code spikes, or when a pair partner is sick (unless you can do so virtually), Merritt said.

Pair programming is somewhat instinctive—code reviews, system architecture design, mentoring, and production support are all basically examples of pairing to some degree, Merritt said.

In a standard pair programming scenario, one person acts as the “driver,” controlling the keyboard and mouse, while the other is the “navigator,” reviewing the code and thinking of the big picture. Both communicate the entire time, discussing the ideas and concepts being coded. Initially, you can set a fixed amount of time when one person drives while the other navigates, and then flip when time is up (known as Time Box Switching), but there are other styles as well, Merritt said.

Coding is a social activity, and pairing is a discussion, Merritt said. “When you pair with somebody, your code looks completely different—you put extra effort in,” he added.

For more, check out How to become a developer: A cheat sheet on TechRepublic.

Also see

Image: iStockphoto/scyther5