Quality of Hire

How Senior Engineers Actually Think About Code Reviews

They won’t comment on variable names unless the name is misleading. They won’t disagree about code formatting issues unless the team has infrastructure for that already in place. They won’t hinder a Pull Request based on personal preference in the name of “best practices.”

Code reviews are one of the most critical components in the work routine and probably the most misinterpreted.

Many senior developers find their impact being diluted when it comes to code reviews. Hard-won experience based on live learning from all those years gets shrunk down into comments about spacing, variable names, or the fact that a function could have been made one line shorter. Meanwhile, actual architectural hazards, performance pitfalls, and maintainability leaks slip by unnoticed into production
.

And the final state? Clean and tidy code layered over questionable design decisions.

The difference between a senior engineer who is good at code reviewing versus those who are experienced isn’t how many bugs they point out. It’s what matters in those bugs, which battles to fight, and what must be fixed before it ships.

This is how senior engineers actually think about code reviews, though they may not verbalise this thought process.

Starting With Why, Not How

Almost all code reviews kick off in the wrong place: code.

“The senior mindset begins one step earlier. Prior to scanning the first line of code, the question itself is not “Is this code good?” but “Should this code even be written?””

“When a pull request comes in, senior review team members read the pull request description, the ticket, and the context surrounding it. They strive to know the problem that’s being solved. Not the implementation, but the solution.”

There exist plenty of pull requests with gorgeous abstractions, comprehensive tests, and impeccable code formatting, all resolving the thoroughly incorrect problem. One might create a custom virtualisation layout solution for their table when the problem was merely paginating instead of rendering too much data on initial page load. The codebase itself might be considered spotless. The design? Flawed.

“Code smells of junior reviewers tend to be about ‘how it does something,’ while those of senior reviewers tend to be about ‘why it exists at all,’”

Looking for Risk, Not Perfection

What senior engineers strive to create is not perfect code. They strive to create safe code. Not faster code.

An effective review isn’t really about polish, but about risk. How well will this stand up to scale? Is this coupled in a place where the thing on the other side of the coupling is likely to end up somewhere else? Is this logic where it belongs, or is this logic leaking responsibilities up or down the layers?

Misalignment in formatting can be corrected at little cost. Mistakes in architecture cost more. Senior reviewers value this.

They ask such questions as: