The #1 benefit of code review is to ensure that the code being written is understandable to at least one other person. If at least one other person can understa

The #1 benefit of code review is to ensure that the code being written is understandable to at least one other person. If at least one other person can understand it, it's much more likely several other people will be able to. In my experience, this is something that many reviewers, including senior engineers, do not understand. If you haven't worked in enough different styles of codebases, maybe you don't even think this is possible or desirable, in the same way that many people didn't think having a uniform formatting style in a codebase was possible or desirable. When people don't think that everyone has the right to understand what's going on in code just by looking at it, we end up with parts of the codebase that are idiosyncratically written, structured in confusing ways, and very difficult for anyone but 1-2 people who wrote them to maintain. And then when folks review changes by those 1-2 people, they lack the domain knowledge to do a thorough review and tend to just look for surface level issues and go "I don't really have context on this but I assume X knows what they're doing." This should be a red flag for you if you find yourself doing it on a regular basis. IMO, if your team is operating this way, maybe you should just be writing better tests and merging to master. But consider how your code is evolving. Are there key areas that are only understood by one person on your team? Are there services that you'd rather completely rewrite than take the time to understand? If so, that represents a huge waste of effort. What would prevent that from happening again?