Code Reviews vs Pair Programming

One doesn’t really make the other redundant

Photo by Alvaro Reyes on Unsplash

I’ve heard many developers saying “we have code reviews, so we don’t really need pair programming” or (rarely though) “we do pair programming, so we don’t really need code reviews”. Does one practice make the other redundant?

I don’t think so. Even though both practices improve the quality of software and promote knowledge sharing, they help teams achieve those goals in different ways and with different “side effects”.

A few examples when it makes sense to apply both practices together.

1. Two junior developers have paired on a task for a day and believe their code is ready to be deployed. Should a more experienced developer review their code before it is merged into master and goes live? Most likely, yes. After the code review the juniors will get quick feedback and opportunity to learn from it. The reviewer will be certain that the code is actually production-ready.
2. While pairing you have found an elegant solution to a problem and made important change to the system. Would you like to give heads-up to the rest of your (potentially remote) team about that? Yes, perhaps. Every team member will be familiar with the new solution or with important change and will get a chance to comment on that.
3. While pairing on a task you have reached a point when you have finished coding and made sure that you code works as expected. You may still want to have a look at the diff before merging the code into master to make sure that the code not only looks good to you today, but will also make sense to you both in six month time.

Pair programming would help when the brain power of two developers is needed to solve a problem or some technical skills have to be transferred. Code review would ensure that the code produced by developers “looks good”, is correct, and can be understood by each team member.

In my opinion, code reviews are a must-have practice. Pair programming is a nice-to-have thing, though. Not every programming task requires combined efforts of two developers. However, every change to the codebase must be reviewed and communicated to the team to minimise the risk of introducing errors.

While writing this post I realised that I’d like to share so much about how developers accept criticism while pairing and during code review, about the difference between pairing with junior and senior developers, about reviewing the junior developers’ code, about my approach to reviewing code, about situations when, in my opinion, pairing works best, and about mob programming. Hopefully, I will write about all that in future posts.

In the meanwhile, I would like to recommend these articles on pair programming and code reviews:

• Pair Programming vs. Code Reviews
• Code Reviews vs Pair Programming
• Giving better code reviews
• Effective Code Reviews — 9 Tips from a Converted Skeptic
• Code Reviews: Just Do It
• Effective vs Ineffective Pair Programming
• Effective Navigation in Pair Programming
• Pairing in Practice followed by Pair programming questions
• So how good is pair programming, really?
• Mob Programming — the Good, the Bad and the Great.
• Our top 12 mob programming tips and thoughts
• Pair Programming vs. Mob Programming

If you found this post useful, give some claps below or a share on social media. Thanks for reading!