I still remember the little dopamine hit of opening that pull request. Eight hundred lines. A clever abstraction I was quietly proud of. I'd solved the problem and made it elegant.
Then the review came back. Not cruel. Just honest. And it took me about a week to admit it was completely right.
That PR taught me more about being a senior engineer than any promotion ever did. Here's the uncomfortable version.
The PR that humbled me taught one core lesson: code that is clever for the author is often hostile to the reader. Good engineering isn't measured by how impressive your solution is — it's measured by how easily the next person can understand, change, and trust it. Humility in code review means optimizing for the team's future, not for your own ego in the present.
The task was real but not glamorous: clean up how we handled a bunch of slightly different notification types. The existing code was repetitive. Ugly. Begging to be unified.
So I unified it. Beautifully, I thought. A single generic engine with a config-driven type system, a clever bit of metaprogramming, a couple of higher-order functions that collapsed six files into one. It felt like real engineering. The kind you read about.
I added a paragraph to the PR description explaining the architecture, because I was sure people would admire it.
I hit submit and waited for the praise.
The first comment was from an engineer I respected. It said, roughly:
"This is genuinely clever. I've read it three times and I'm still not sure I could safely add a new notification type next week. Can we talk about that?"
My first reaction was defensive. It's not that hard. You just have to understand the pattern. I actually started typing a reply explaining the pattern.
And somewhere in the middle of typing that explanation, the lesson landed.
If the code needed me to write a paragraph explaining it, and a senior teammate still couldn't confidently extend it, then the code had failed at its actual job. Its job was not to be admired. Its job was to be safely changed by someone who isn't me, on a day I'm not around.
My clever abstraction had made the code shorter and the understanding longer. I'd optimized the wrong variable. I'd written code for an audience of one — me, right now — instead of for the team, forever.
That's the whole lesson, and it stung because I'd genuinely believed cleverness was the point. Unlearning that belief is, for my money, most of the brutal truth about becoming a senior developer — the job quietly stops being about looking smart.
Here's the trade I hadn't seen. Every clever abstraction is a loan. You feel rich at write-time. The team pays interest at every read-time, forever.
My generic engine saved maybe a few hundred lines. But it added a tax to every future change: you couldn't touch notifications without first reverse-engineering my mental model. The repetitive code I'd "fixed" was dumb, but dumb is readable. Anyone could have added a notification type to the ugly version in five minutes without understanding anything global.
I'd traded six obvious files for one ingenious bottleneck.
The best code isn't the code that shows how smart you are. It's the code that makes the next person feel smart.
I see this everywhere now. The senior engineers I most admire don't write the most impressive code. They write the most boring code — the kind you can skim at 2am during an incident and immediately trust. Their cleverness goes into the design that makes the code able to be boring. That's a much harder and quieter skill. It's also the heart of the code review rule that changed my team: optimize for the reader, every time. Martin Fowler has been making essentially this case for years — that readability and changeability matter more than surface cleverness.
We talked it through, and I rewrote it. The final version was longer than my clever one and far shorter to understand. Here's what changed and why.
Here's the mindset shift, side by side:
| What I optimized for before | What I optimize for now |
|---|---|
| Fewest lines of code | Easiest future change |
| Showing I understood the pattern | The reader needing no pattern |
| Cleverness | Obviousness |
| My pride at submit time | The team's safety at read time |
| Zero duplication | Zero confusion |
That PR changed how I sit in a review, on both sides of it.
When I'm the author: I treat every confused comment as data, not insult. If a smart reviewer is confused, the code is confusing — full stop, even if I could explain it. My job is to make the explanation unnecessary, not to win the argument. The defensiveness I felt that day was the ego trying to protect a thing that didn't deserve protecting.
When I'm the reviewer: I lead with the question, not the verdict. "Can you walk me through why this is generic?" opens a door. "This is over-engineered" slams it. The goal is to help the code get better, not to prove I'm right. The reviewer who humbled me did it without a single harsh word, and that's exactly why it landed.
And the biggest shift: I no longer feel embarrassed when a review changes my code. That's the system working. The embarrassing outcome is the clever, opaque thing shipping unchallenged and detonating six months later in someone else's lap.
I also changed what I look for first. I used to scan PRs for correctness — does the logic work? Now my first pass is for legibility — will the next person understand this without a tour guide? Correctness bugs get caught by tests and by users, eventually. A legibility problem is forever, silently taxing everyone who reads the code, and no test will ever flag it. So that's the thing I now spend my reviewer attention on, because it's the thing nothing else will catch.
The hardest part was unlearning the reflex that being challenged means being wrong as a person. It doesn't. The best engineers I know want their code challenged, because they've internalized that the code isn't them. A review that improves your code is a gift someone spent their time on. The version of me that took it as an attack was protecting an ego that wasn't worth the protection — and was, ironically, making me a worse engineer to work with.
Q: Isn't some abstraction necessary? Won't "just repeat yourself" create a mess? Of course. The skill is timing. The rule I use: don't abstract until you've seen the pattern three real times, and never abstract in a way the team can't easily read. Premature, clever abstraction is the trap — not abstraction itself.
Q: How do I stop taking code review personally? Reframe it: the review is about the code's future readers, not about you. A comment isn't "you're bad," it's "this will trip someone up." Separating yourself from the diff is the single most freeing habit in this job.
Q: What if the reviewer is actually wrong? Then explain, kindly, and if your explanation requires a paragraph — notice that. Sometimes you're right and the code is fine. But if defending it takes that much effort, that effort is itself a signal worth heeding.
Q: How do I give humbling feedback without crushing people? Lead with a genuine compliment if one's true, ask questions instead of issuing verdicts, and make it about the reader's future experience. "Could the next person extend this easily?" is a kindness. "This is bad" is not.
Q: Does this mean clever code is always wrong? No. Cleverness in the design that lets the code stay simple is great. Cleverness in the surface that the reader has to decode is the problem. Put your intelligence where it makes things simpler, not where it makes things shorter.
I went into that PR wanting to look smart. I came out of it understanding that looking smart and being a good engineer are often opposites.
Junior engineers write code they're proud of. Senior engineers write code other people are grateful for.
The humility wasn't in being wrong. It was in finally seeing that I'd been measuring the wrong thing for years — and that the fix made me both a better teammate and, quietly, a better engineer.
If this made you rethink one clever abstraction you've been proud of, that's a good day's work — try the question on your next PR, and the senior-developer pillar has more of these ego-bruising-but-useful lessons.
So next time you're about to ship something clever, ask the question that PR taught me: not "is this impressive?" but "could the next person change this safely without me?"
Leaving my job wasn't a leap of faith. It was a spreadsheet. Here's the runway math that turned a terrifying gamble into a boring, calculate…
No following, no network, no luck. Just an unglamorous system I ran for eighteen months. Here's exactly what I did.
I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!