Reviewing Code Without Acting Like ESLint

The problem

Some code review helps.

And some code review only wears people down.

You have seen the second kind.

It is the review that turns into:

• a style war
• personal taste dressed up as standards
• comments on every irrelevant line
• micro-fixes that the IDE, formatter, or linter should already handle

Meanwhile, bigger issues sail through:

• wrong behavior risk
• bad coupling
• confusing names
• unnecessary complexity
• a flow that will be hard to maintain

The result is terrible.

The reviewer thinks they are being careful.

The author feels punished for details that do not matter.

And the real quality of the change barely improves.

Mental model

Think about it this way:

code review is not there to prove that you can spot defects. It is there to increase the quality of the change before it enters the system.

That shift matters.

Because it moves review out of personal performance and into usefulness.

The question stops being:

• “what can I comment on?”

and becomes:

• “what here actually deserves human attention?”

That alone already improves review quality a lot.

Breaking the problem down

The linter, formatter, and tests should already carry the mechanical work

If human review is spending too much energy on:

• indentation
• quotes
• trivial ordering
• repeated conventions

something is wrong in the process.

Those things, when they are standard for the team, should ideally be automated.

Not because they never matter.

But because human attention is expensive.

And it is better spent on:

• understanding
• risk
• clarity
• trade-offs

than on mechanical correction.

Not every comment has the same weight

This point is central.

A comment with no priority is just noise.

In practice, a better review usually separates things like:

• real blocker
• important concern
• optional suggestion
• cosmetic nit

Without that distinction, everything looks urgent.

And when everything looks urgent, nothing is readable.

A good comment talks about consequence

A lot of weak review sounds like this:

• “I would do it differently”
• “I think this should change”
• “I do not like this name”

That is weak.

Because it does not explain the impact.

A strong comment usually has a more useful shape:

• what stood out
• why this could be a problem
• what risk or cost it creates
• which direction would make more sense

Example:

instead of:

“This helper looks weird.”

something like:

“This helper merged two flows that look similar, but they change for different reasons. My concern is that we would hide different rules behind the same abstraction and make future maintenance harder.”

The difference is large.

Good review protects future readability

Not every problem shows up as a bug.

Sometimes the damage is:

• slow reading
• hard-to-predict behavior
• expensive future change
• more confusing onboarding

That belongs in review too.

But it needs to be explained with judgment, not with a vague line like:

“This does not feel clean.”

“Clean” by itself means nothing.

Readability with context does.

Review is not the place to perform superiority

This needs to be said directly.

Some review becomes ego performance.

The reviewer makes too many comments to show off repertoire, strictness, or sophistication.

But the goal is not to look like the most critical person in the thread.

The goal is to improve the change.

Sometimes the most mature review is short and sharp.

A few comments, but only on what really matters.

Blocking is expensive

Some people block PRs too early.

Almost as a reflex.

But blocking means:

• delaying delivery
• pulling in another round of context
• increasing the emotional cost of review

So blocking is worth it when the problem is truly important, for example:

• likely bug
• operational risk
• behavior too ambiguous
• design that locks the team into high future cost

If it is a light preference, the better answer may be a suggestion, not a block.

The best review considers stage and context

This matters a lot.

The same change may deserve different strictness depending on:

• how critical the flow is
• the real deadline
• the maturity of the module
• how reversible the change is
• how much risk is involved

A mature review does not use the same ruler for everything.

It adjusts depth without giving up judgment.

Simple example

Imagine a PR that extracts a generic function to reuse logic across two flows.

Weak answer:

“I would rather not abstract. This is overengineered.”

That might even be right, but it is still weak.

Better answer:

“My concern here is not abstraction itself, but the timing of it. The two flows still have important rule differences and different paths of evolution. If we merge them now, it may become harder to change one without affecting the other. I would lean toward keeping things explicit for now and revisiting the abstraction once the pattern is more stable.”

That answer does a few things right:

• identifies the real point
• explains the consequence
• avoids empty authority tone
• suggests a practical direction

Common mistakes

• Treating review like a hunt for cosmetic details.
• Commenting without explaining impact or priority.
• Blocking because of personal taste.
• Making technical comments to sound sophisticated, not to help.
• Ignoring risk, deadline, and the criticality of the change.

How a senior thinks

People who have grown usually ask:

“If I have limited attention to spend on this review, where does it reduce the most risk and add the most clarity?”

That is a very good question.

Because it forces prioritization.

And good review is that too:

prioritization.

You are not reading code to comment on everything.

You are reading to improve what matters most before the merge goes in.

What the interviewer wants to see

When this topic comes up in an interview, the evaluator is usually trying to understand whether you:

• can tell automation apart from human judgment
• know how to prioritize review problems
• give feedback with clarity and respect
• understand that review is part of delivery quality, not social ritual
• can balance judgment with pragmatism

A strong answer should show:

1. what you look at first in a PR
2. what would make you block it
3. what would become a suggestion
4. how you write feedback so people actually use it

If that shows up, the answer is already far above the usual “I review clean code and best practices.”

Good review does not try to comment on everything. It tries to hit what matters most.

People who act like ESLint too much usually miss the things only human judgment could catch.