Perhaps you’ve encountered peers whose passion for pair programming borders on religious belief. Let’s call them Patrick and Paula, the pair programming prophets. They preach that pair programming solves every poor software practice. Few take Patrick and Paula seriously, but their dogma does have a following. We could dismiss Patrick and Paula, but there are enough Patricks and Paulas around to at least examine their claims and determine if there’s any harm or benefit behind them.
In The good stuff, I reviewed proven practices that make teams twice as likely to exceed performance goals. Peer programming was not singled out as one of them, though it does appear in that research as one of two recommended ways of doing lightweight change approval (the other was intrateam code reviews). As a result, I’d never push pair programming before inspirational and supportive leadership, continuous delivery, DevOps, or lean software development. Nonetheless, let’s discuss pair programming pros and cons.
What do Patrick and Paula preach about pair programming?
- High quality. Code is continuously reviewed and discussed as it is written, catching errors and avoiding pitfalls.
- Robust design. Instead of going with one person’s gut, a pair can discuss reliability, security, and scaling issues to determine the best design.
- Knowledge transfer. When a team member is away, the pairing partner can cover. Also great for onboarding new teammates.
- Focus. There’s no daydreaming, checking social media, or deep diving on the internet while pairing.
- Social. Coding can be an isolating task, but not if you practice pair programming.
“Sure,” Patrick and Paula concede, “pair programming uses two engineers to do the work of one, but the focus, high quality, and robust design more than make up for the lost time while also providing knowledge transfer and a social experience.” Are they right?
As the previously mentioned research points out, the quality gained by pair programming can also be achieved by intrateam code reviews. Likewise, intrateam design reviews provide robust designs. While Patrick and Paula might argue that pairing forces you to do those code and design reviews on time every time, many teams already insist on code reviews for all pull requests and design reviews for all feature work. For straightforward designs and improvements, pairing may not be worth the overhead.
Knowledge transfer is essential for every team, but it’s also attainable by assigning every area a primary and backup owner. The backup is on every associated code review and fills in whenever the primary is away.
While focus and socialization are important, there are many ways to provide them. Some engineers prefer coding to socializing—it’s part of the profession’s appeal. They also love that feeling of flow you get when you lose yourself in a codebase, which is more difficult to achieve when pairing.
For more on assigning ownership, read Effective delegation: Assign ownership.
You got a friend
If your team code reviews all pull requests, reviews designs for all substantial and subtle feature work, and assigns every area a primary and backup owner, then pair programming’s benefits may not outweigh its costs. Are there times when you should pair?
Some engineers love pairing, and that’s great. They’ll get all the benefits without complaint. Ensure both participants are enthusiastic about working together and are well-matched. Also ensure they have a good place to pair that has sound isolation, so they avoid disturbing their peers, as well as appropriate seating. Naturally, they should be co-owners of the area(s) in which they pair.
Another terrific use of pairing is onboarding new team members, particularly new hires. Pair an experienced engineer with the new person—ideally their onboarding buddy or mentor. It’s important for the mentor to see the pairing as an opportunity to both generate code and advance the skills of their less experienced peer. Set this clear expectation, give the pair sufficient time to code and coach, and ensure the engineers take turns at the keyboard, modeling and then practicing skills.
Finally, mob programming may be useful for crucial code, like a core function change or major live site incident fix. In mob programming, the entire feature team works together, with one team member at the keyboard and the rest collaborating on the design and code. It’s an expensive way to utilize an entire team’s resources but may be worthwhile for a sufficiently critical purpose.
For more about different programming styles, read You’ve got coding style.
Underpromise and overdeliver
I applaud Patrick and Paula’s enthusiasm for strong programming practices and high-quality code. However, it’s not necessary to be dogmatic about pair programming to gain the benefits it highlights. Ensure your team reviews designs for substantial and subtle feature work and all pull requests. Assign owners and backups for every area. If some team members love pairing and are compatible, provide them appropriate workspaces and let them be their best selves. If other team members prefer to work alone and get into flow, provide them appropriate workspaces as well. Pair mentors with new team members, have them take turns at the keyboard, and allocate sufficient time for them to code and coach. Finally, if a code change warrants it, have the entire feature team code together.
No one should be forced to pair any more than they should be forced to work alone. As long as the team is working cooperatively, sharing knowledge, and producing quality code with robust designs, life is good, and we can all work in our own best manner.
Want personalized coaching on this topic or any other challenge? Schedule a free, confidential call. I provide one-on-one career coaching with an emphasis on underrepresented, midcareer software professionals. Find out more at Ally for Onlys in Tech.