What are the benefits and drawbacks of pair programming for different skill levels and learning styles?

I'm glad this article mentioned observing how others use tools as one of the benefits of pairing, because people often overlook this one. This benefit can apply to devs at all levels, not just beginners, and it can be very powerful. For example, if while pairing you learn about some feature in or plugin for your IDE that you were previously unaware of, that tooling improvement can increase your productivity every day, whether you're pairing or not. During my most recent pairing, with a developer I've worked with for almost a year, we each learned something about VSCode that we hadn't known before. That will continue to pay off for as long as we're using that tool.

A particular risk comes around diversity, equity, and inclusion within the engineering community. The engineering community is already overwhelmingly white men. Pairing an early career woman or minority candidate with a strong-headed, "old-school" attitude engineer can be especially intimidating and risks pushing them out of the field before they even get started. On the other had, having the right pair with high EQ and awareness for cultural differences can help make the field more accessible for these same individuals.

Building on the statement about shared ownership, one thing that pairing (and rotation of pairs) helps provide is a distribution of knowledge. For some developers who thrive on the "White Knight" or "Gray Beard" persona, this may be intimidating and a threat to their identity as the senior-most developer on the team. For many, being a knowledge silo is career-limiting. Once you are viewed as the only expert on a particular product or section of code, you will be pigeon-holed into any and all work related to those areas. This means even years later you cannot escape these products unless you leave the organization. Pairing and rotation prevents knowledge silos, freeing us to rotate on and off of products to promote career development.

Pairing is also exhausting. Many (though not all) developers are introverted, which means that the act of pairing takes energy by default. It is important to recognize this and communicate with your pair and with your team about when you need a break to ensure a sustainable pace is maintained without burnout. Relatedly, pairing creates peer-pressure to be hands-on-keyboard Executives love this and highlight it as a perk of pairing, because it creates mutual accountability. However, this ignores the fact that most development is knowledge work; the brain needs time to process challenges to discover creative solutions. Pressure to remain coding scan hamper problem solving. This can be solved with a good break culture and open communication.

In my experience, pairing makes dynamic staffing easier as well. A product may require some number of engineers - say 4 engineers operating as two pairs - during normal times, but when a critical deadline approaches or an unexpected headwind or issue appears, it may become necessary to scale the team. With a normal team, you would expect a lag as new developers are onboarded and learn the code. With a team that practices pairing, we can essentially undergo mitosis, dividing our two pairs of engineers into 4 individuals then pulling in contractors or developers from a different team to pair with each of them. This effectively doublers my engineering team instantly.

For larger programs, pairing helps keep multiple teams coordinated over longer time frames by allowing for rotation. When each engineer owns their own sections of code there may be a high activation energy to lend one developer from one team to another for cross-pollination. With pairing, it is easier to rotate developers between teams or to have developers to short "sabbaticals" with different teams to understand the bigger picture beyond their component of the product.

In regulated industries, pairing helps to maintain legal/regulatory compliance at the speed of software. Continuous code review can replace phase-gate code checks. Additionally, rotating different functional experts (security, architecture, data analytics, etc.) with an anchor developer makes it easier to keep these diverse voices engaged throughout development, catching issues sooner and responding to emergent issues faster.