A reviewer soon understands that senior devs are producing good code and stops investing time on reviewing their code. If they are doing their job properly. But again it comes down to internal motivation and self management on their part.
Yes, sorry I should have been more explicit. Initial reviews have value (is this guy full of beans or does he know what he's doing), but constant reviews of senior developer code do not. If you've hired anyone you have to constantly do reviews for, you've probably hired the wrong person. I mean they should get what you are looking for after a month or two.
I know exactly zero developers senior enough to have gotten over writing bugs. I know I've written bugs that happened to pass all my tests only to blow up in somebody else's face, sometimes after surviving years of production use.
Code review would've at least had a chance to catch them early—so long as you treat it as critical analysis of program logic and not just a screen for generic goodness.
IMO if your code reviews are glorified manual style checking, you're doing it wrong.
>I know exactly zero developers senior enough to have gotten over writing bugs.
No one was arguing that. Code reviews aren't for bug discovery, though that can sometimes happen. It's a very inefficient way to discover bugs.
Developers should test their code for bugs before completing the task and submitting to QA. QA is a more thorough than development bug / unit testing and includes integration. Betas (if applicable) are the final source of pre-release bug discovery. Spending a bunch of time on code reviews to find bugs.
IMO code reviews should do two things:
1. Make sure the developer knows how to develop and is not being sloppy and not following whatever standards are set (comments, etc). They are essentially training wheels for new developers to the organization and junior developers.
2. Make sure the code represents what the developer thinks it does (sanity check).
You do need to make sure the changes follow the "philosophy" of whatever component is being changed. Otherwise you get things like duplicated functionality or APIs that don't have any cohesion. If the Senior engineer frequently works on this specific piece then its not an issue, but no matter how senior someone new to an area will not produce optimal code.
