Executive Summary
The users of your software don’t care how good the code is, only that it allows them to be more effective in the job that they are trying to get done. Code reviews don’t necessarily prove how effective software can be, only that it follows some internal standard. There are other ways to get to the same result by automation that will not be as “in your face” to the person being reviewed. This doesn’t mean that senior level peeps shouldn’t help junior levels but there are other, more constructive, ways of doing this; lunch and learns, mentoring, online gamified training, ect. By time spent by people reviewing code, developing using common standard static tools, and shared frameworks, goes right to the bottom line. Plus the code gets better, the stress of reviews go away, and all developers can be more creative and stumble upon the “right” thing quicker. It’s all about getting to the “right” thing for the users of software as fast as possible!
Developer Story
For a developer there may be nothing more stressful then having peers inspect and scrutinize their code. In most cases the need for manual inspection of code can be replaced by automation and better development methodologies. Unit / load testing can help point out bottlenecks and verify that the code is doing what it’s supposed to do. Standard coding styles can be enforced by static analysis. Advanced coding techniques can be encapsulated within abstracted frameworks that simplify and enforce common usage. Instead of saying that all should use try / catch / finally / log, build some utility classes that use the strategy pattern and have everyone use those. Enforce that every public method, especially api / service entry points, adhere to this usage via static analysis.