Mastering Code Reviews | Article 5: Pragmatism Over Perfection — Picking Your Battles
One of the hardest lessons I learned in my years is that perfect code is a myth.
When I was a mid-level dev, I wanted every Java class to be a masterpiece of design patterns. I would block PRs for days over a slightly “smelly” abstraction. Now, as a seasoned guy, I realize that my job is to balance Technical Health with Business Velocity.
Sometimes, the most “Senior” thing you can do is hit the “Approve” button on code you don’t like.
1. The “Two-Way Door” Test
I’ve learned to categorize every code change into two types:
- One-Way Doors: Decisions that are hard to undo (e.g., changing the database schema, picking a new core library, or changing a public API contract). I fight hard on these.
- Two-Way Doors: Decisions that are easy to refactor later (e.g., a messy private method, a slightly inefficient loop, or a confusing variable name). I let these slide if we are in a hurry.
2. Identifying “Strategic” Debt
Not all technical debt is bad. Sometimes, you “borrow” time from the codebase to hit a critical market deadline.
- The Seasoned Move: If a dev writes a “hack” to get a feature out for a major trade show, I won’t block it. Instead, I’ll ask them to add a TODO with a linked Jira ticket to fix it next sprint.
- The Line in the Sand: I only “stop the line” if the debt is Toxic—meaning it introduces a security hole, a data corruption risk, or makes the system fundamentally unstable.
3. The “Good Enough” Rule
I ask myself: “Is this code better than what is currently in production?”
If the answer is Yes, and we are under pressure, it’s probably good enough to merge. We are engineers, not artists. Our goal is to solve problems, not to write poetry in Java.
4. Respecting the “Author’s Choice”
If a developer chooses a while loop and I would have used a Stream, but both are equally performant and readable—I say nothing.
As a Staff Engineer, you have to kill your ego. If you force everyone to write code exactly like you, you’ll end up with a team of “order-takers” who can’t think for themselves.
Why this matters for your career
If you are the guy who blocks everything, people will stop coming to you for advice. They will start trying to “get around” you.
But if you are the guy who understands the business pressure and helps the team ship—while only stepping in when things are truly dangerous—you become a Trusted Leader.
The Bottom Line
Don’t be a perfectionist; be a pragmatist. Save your “No” for the things that will actually break the company. For everything else, give feedback, but let the team move.
In the next article, we’ll talk about how to use this whole process to Scale Yourself. I’ll show you how to turn your PR comments into a Mentorship Platform so your team eventually stops needing you to catch their mistakes.