For the first two years of my backend engineering career, I had a habit I didn't even know was a problem.
Every time I wrote code, there was an invisible audience in my head. Not the engineers who'd inherit the system. Not the on-call person who'd debug it at midnight. Not the junior who'd join the team six months later.
Just my code reviewer.
I optimized everything for that one person reading my PR. And I told myself it was good engineering.
It wasn't.
What "Writing for the Reviewer" Actually Looked Like
I was obsessed with looking senior in a diff view. Here is what that looked like in practice.
Instead of a simple, obvious method name like this:
public List<Order> getActiveOrders(String userId) {
return orderRepository.findByUserIdAndStatus(userId, OrderStatus.ACTIVE);
}
I'd write something like this because it looked more "architectural":
public <T extends BaseEntity> List<T> fetchEntitiesByPredicate(
Class<T> entityClass,
Predicate<T> filterPredicate,
Comparator<T> sortStrategy
) {
return entityRegistry.stream()
.filter(e -> entityClass.isInstance(e))
.map(e -> entityClass.cast(e))
.filter(filterPredicate)
.sorted(sortStrategy)
.collect(Collectors.toList());
}
Reviewer loved it. Called it "elegant generics usage" in the review.
Six months later that method caused a production incident because nobody could figure out what it was actually supposed to do.
The Friday Night That Changed Everything
A service went down on a Friday evening.
The on-call engineer wasn't me. It was a teammate who had joined three months earlier. He had to debug my code, under pressure, at 9 PM, without me available.
He called me after an hour.
He couldn't follow it.
Not because it was messy. Because it was written for an audience of one: the person approving it, not the person fixing it in the dark.
That call changed how I think about code permanently.
4 Questions I Ask Now Before Every PR
After that Friday night, I stopped asking "will this look good in review?" and started asking:
1. Can someone who didn't write this understand it at 2 AM?
If the answer is "probably not," the abstraction is wrong. Not the person reading it.
2. If this fails, will the error explain why or just that it failed?
Silent failures and generic exceptions are not clever engineering. They are traps with no map out.
3. Is this clever or is this clear?
Clear wins. Every single time. Clever code gets praised in review and cursed in production.
4. Would I be comfortable debugging this without the author next to me?
If not, it's not ready.
What Production-Ready Code Actually Looks Like
Here is what I changed that over-engineered method to:
public List<Order> getActiveOrders(String userId) {
log.info("Fetching active orders for userId={}", userId);
List<Order> orders = orderRepository.findByUserIdAndStatus(userId, OrderStatus.ACTIVE);
log.info("Found {} active orders for userId={}", orders.size(), userId);
return orders;
}
Boring in a PR? Absolutely.
Debuggable at 2 AM by someone who's never seen this code before? Yes.
That's the point.
The Mindset Shift Nobody Tells You About
Impressing your reviewer is a junior mindset. Not because reviewers don't matter. They do. But because the real audience for your code is production: the system running it, the logs trying to explain it, and the engineer at midnight trying to fix it.
The engineers I respect most write code that looks obvious. Every variable name says exactly what it is. Every method does exactly what it says. Every failure message tells you exactly where to look next.
Nobody taught me this explicitly. I had to get a 9 PM phone call to figure it out.
If you are a junior or mid-level engineer reading this: the goal is not to write code that makes you look smart. The goal is to write code that makes problems obvious and solutions clear.
That is what seniors actually trust. That is what gets you into production-critical systems.
What changed your approach to writing code: a code review, or a production incident? Drop it in the comments.
Top comments (0)