Perils of Pair Programming

Pair Programming is quite popular among software professionals in Silicon Valley. It is an agile development technique where two programmers work together at one workstation. While one writes code (“driver”), the other reviews the code as it is typed in (“navigator”). The programmers switch roles frequently.

This technique clearly has advantages. A lot can get done fast and there is the benefits of collaboration between programmers who may have different skill-sets and competencies. Not to mention the fact that there is feedback in real-time, resulting in lesser errors. A survey of pair programmers from July 2000 suggests that 96% of the programmers surveyed enjoyed their work more when pair programming than when they programmed alone. In addition, 95% were more confident in their solutions when they pair programmed. The Wikipedia entry on Pair programming is almost all positive.

I am skeptical that this study holds in the current Silicon Valley environment, especially in relation to start-ups. A software guy whose company is big on pair programming  spoke to me of the downsides of this kind of work and the difficulties he is having with it. From a psychological standpoint, I can see many downsides that can negatively affect the employees mental health.

  • Anxiety brought on by negative thoughts of whether you can match up to the other employee you are being paired with.
  • Anxiety and stress brought on by whether you will be able to  “get you game-on” during the pair programming sessions.
  • Might promote a competitive mind-set among employees. To be clear, many programmers like this and its implicitly encouraged at many start-ups.
  • Since pair programming will quickly expose deficiencies or lack of speed, it might promote a cutthroat company culture with much less tolerance for mistakes or “bad days”.

Then there is the question of gender differences with regards to pair programming. I am not aware of studies looking at this issue and whether men and women respond the same way to pair programming. I would not be surprised at all if more women than men are disenchanted with this practice and my sense is that this is modulated by how inclusive the particular workplace or start-up is for women.

Ultimately, the over-all company culture will have a huge impact on whether this practice will contribute to or undermine employee wellbeing. If the company has built a culture that engenders “psychological safety” amongst its teams and employees, then pair programming might actually improve employee bonding and satisfaction. On the other hand, even if there is mild distrust and competition among employees, this practice will add to the angst that employees are already feeling. In some ways, pair programming is the canary in the coal mine!