Code Reviews are an integral part of our job as a Frontend developer. A lot of Senior developers waste their leverage in code reviews. Years of judgment about what actually matters get funneled into comments about formatting and variable names, while real architectural risks slip through unnoticed. The result is tidy code sitting on top of shaky decisions.
The difference between a Senior developer who’s good at code review and someone who’s just experienced is not just about spotting “more issues”, rather I think it is about knowing which bugs are worth catching, which fights are worth having, and what actually needs to change before code ships.
In this article, I’ve tried to cover key code review practices designed to improve both our skills as developers and the overall quality of our codebase.
Starting With Why, Not How
Most reviews start by looking at the code. That’s backwards. The first question shouldn’t be “is this code good?” I would say, it should be “should this code exist?”.
When a PR shows up, the Senior move is to read the description and ticket first, understand what problem is being solved, and then ask whether this is the right solution. Not the right implementation of a solution, rather the right solution at all.
Learn more about How Senior Developers Actually Do Code Reviews