I talk a lot about code review and think that it’s a great tool, but I want to re-iterate a point I made previously: code review is not the right tool in every situation.
What I mean by code review is the widely-used, pull request style workflow.
When you want to integrate your code changes to the main branch, you post your changes to a code review tool, for example by creating a pull request in GitHub. Your teammates then review your change and either approve it or ask you for some improvements. Once the change has been approved, it is merged to the main branch.
Furthermore, I’m talking about professional software development teams shipping software-based products or services. Thus, my advice won’t directly apply to e.g. open-source development. The same workflow is popular in the open-source world, but the relationship between open-source collaborators is different from the relationship between the members of a professional team.
In this context, what are some situation where code review is not beneficial?
High-velocity collaboration over a small code base. For example, when you’re starting a new project, there’s a lot of scaffolding to set up and many new things to build. Typically the details do not yet matter much and changing things is easy. Code review is too slow and too detail-oriented - you’re better off with talking to each other and reading each others code after it has been merged to the main branch.
When code review does not do anything. If getting your changes reviewed takes days and the result is just “LGTM” (looks good to me), the review process is not bringing you any value. Slow reviews are demoralizing, as finishing any task takes seemingly forever, and they hurt the team’s ability to ship.
You could try fixing the broken process, but the simplest way to improve the situation is to stop reviewing altogether. There’s an emotional barrier to actually stopping, but if the reviews are not providing any value, it is a safe step to take.