Fordel StudiosA junior engineer submits a PR on Monday. It is not perfect. It solves the problem it was designed to solve. By Thursday, it has twelve comments: three about variable naming, four about code style that the linter should catch automatically, two about approaches the commenter would have taken personally, one about a test case that should be added, and two comments that say "not sure about this" with no elaboration. The junior engineer spends Friday trying to understand what "not sure about this" means. The PR merges the following Tuesday.
This is not code review. This is senior engineers using junior engineers' work as a venue for their preferences.
What Code Review Is Actually For
Code review has one primary purpose: catching things that will cause real problems before they reach production. Bugs that will break user workflows. Security vulnerabilities. Performance issues at scale. Architectural decisions that will make the next feature significantly harder to build. These are the things that deserve review attention.
Code review has a secondary purpose: knowledge transfer. The reviewer explains why a pattern is preferred. The author understands a constraint they did not know existed. Both learn something. This is valuable and it requires communication, not just comments in a diff.
“If your review comment would not have caught a production bug and does not teach the author something they will use again, it is noise.”
The Power Dynamics Nobody Discusses
Code review is the primary mechanism by which senior engineers exercise taste on a codebase. That is legitimate. The problem is when taste is exercised without explanation, when "I would not have done it this way" is treated as a blocking comment rather than a starting point for conversation, and when junior engineers learn that getting a PR merged requires satisfying the personal preferences of whoever reviews it rather than meeting objective quality criteria.
The result is junior engineers who write code to pass review rather than code that solves problems well. They learn the reviewer's idioms rather than developing judgment. The review process, which was supposed to transfer knowledge, becomes a ritual of compliance. The senior engineer feels like they are maintaining quality. What they are actually maintaining is their own preferences at scale.
What Functional Code Review Looks Like
Automate everything automatable. Formatting, import ordering, naming conventions — all of this should be caught by tooling before a human ever sees the diff. The human reviewer should be looking at logic, not style. Every blocking comment should be grounded in a concrete consequence: "this will fail when the list is empty," not "I would handle this differently." The review should take less than 30 minutes for any PR under 200 lines. If it takes longer, the PR is too large.
Most importantly: the review should end with the author understanding something they did not before. If the author fixed every comment and learned nothing, the review failed its secondary purpose. The senior engineer's job is not to protect the codebase from junior engineers. It is to make junior engineers capable of protecting it themselves.
