Stop Looking for Bugs in Code Reviews
Add the cost of the context switch, which research shows takes ~23 minutes to recover from, and that comment about a variable name just cost the company $100 to $500 in lost productivity.
Last week, we talked about “Career Survival.” Survival isn’t just about writing code; it’s about leverage.
And right now, your leverage is bleeding out in the comments section of a Pull Request.
Here is a scenario I see in high-growth startups every day
A Senior Engineer opens a PR.
Another Senior Engineer stops their deep work, pays the cognitive tax of a context switch, and opens the diff.
They spend 15 minutes debating
camelCasevssnake_caseor pointing out a missing semicolon.
Let’s do the math.
A Principal Engineer’s fully loaded cost (salary, equity, benefits, overhead) is easily $200+ per hour.
Add the cost of the context switch, which research shows takes ~23 minutes to recover from, and that comment about a variable name just cost the company $100 to $500 in lost productivity.
If you are a human being and you are commenting on syntax, you are wasting the company’s money.
You are doing a job that a script does better, faster, and for free.
The Lint Barrier
I have a strict rule for my teams
If a machine can catch it, a human shouldn’t see it.
A Pull Request should never reach a human reviewer unless it has already passed a gauntlet of cold, unfeeling robots.
This is the Lint Barrier.
ESLint/Pylint - Catches syntax errors and unused variables.
Prettier/Black - Enforces formatting.
Static Analysis - Catches potential type errors.
If a PR fails any of these, I don’t want a notification. I don’t want to see it.
The “Nitpick” Ban
“Nits” (minor, non-blocking suggestions) are poison.
They clutter the feedback loop. They make the author feel defensive.
Worst of all, they distract the reviewer from the structural flaws hiding in the logic.
When you flood a PR with 20 comments about indentation, you feel productive.
You aren’t. You’re just being a spellchecker.
The Hierarchy of Review
So, if you can’t complain about whitespace, what are you supposed to do?
You do the job we actually pay you for. You look for the things a computer cannot understand.
Your review should follow this hierarchy
1. Architecture and Design
Does this fit our existing design patterns, or is it a bespoke snowflake?
Is this over-engineered? (The “YAGNI” check).
Does this introduce a circular dependency?
2. Data Integrity
The Database Lock - Will this migration lock the
userstable for 10 minutes during peak traffic?Race Conditions - What happens if two requests hit this endpoint simultaneously?
State Management - Are we mutating state that should be immutable?
3. Security
Is there an IDOR (Insecure Direct Object Reference) vulnerability here?
Are we sanitizing inputs?
Are we logging PII (Personally Identifiable Information)?
4. Maintainability
Will the next person understand this in 6 months?
Is the business logic exposed, or is it buried in 5 layers of abstraction?
“LGTM” is not Lazy
There is a stigma that a fast “LGTM” (Looks Good To Me) implies laziness.
In a mature engineering organization, LGTM is a badge of honor.
It means the automated pipeline did the heavy lifting. It means the tests passed, the linter is happy, the style is compliant, and the architecture is sound.
It means the reviewer trusts the system.
The Bikeshedding Trap
Cyril Northcote Parkinson coined the “Law of Triviality” (Bikeshedding).
He observed that a committee would approve a $10 million nuclear power plant in 10 minutes but spend 45 minutes debating the color of the bike shed.
Why?
Because nuclear physics is hard, but everyone has an opinion on paint.
Engineering teams are the same.
We argue about tabs vs. spaces because understanding a distributed race condition is hard.
Syntax is easy. Do not fall into the trap of low-leverage debates.
Here what you should do
You want to stop wasting $500 on variable name discussions?
Implement this today
Agree Once, Then Never Again
Sit the team down.
Argue about the Linter Config for one hour.
Pick a standard (Airbnb, Google, whatever).
Commit that config file.
The discussion is now closed forever.
The Husky Hook
Add a pre-commit hook (using tools like Husky) that prevents a developer from even committing code that violates the style guide.
The “Style” Ban
Make it a team policy.
If a reviewer comments on code style in a PR, the reviewer is in the wrong, not the coder.
Update the linter instead.