Full original post

This post was written by Paul Hinze 6 years ago when he changed jobs and transitioned from a dev culture of pair programming to that of peer code review. He shares a balanced perspective on both these practices.

In pairing, everybody on the team gets better together because of constant communication. Junior developers can be trained easily by giving them an experienced pair; best practices, knowledge, new tools, and techniques spread naturally & quickly across the team. It is not all sunshine and rainbows with pairing though. It can lead to over-diluting core talent which can kill both productivity and morale. When it comes to tackling the larger problems of system design and architecture, that require more deep thought or creativity, pairing can be detrimental to progress.

In teams that follow the practice of code review, there is a motivating pressure to perform well for the review. There are no barriers to take on deep thought problems. As code reviews are asynchronous, there is a lot of work schedule flexibility. Code reviews can be strategically distributed to ensure that more experienced developers always touch certain kinds of code reviews which provide additional quality control and protection against bugs landing in production. However, in teams with code review processes, you can feel lonely, zone out for long periods and run late on deadlines. If code reviews are not done with a tight cadence, they can become bottlenecks

10 mins read