The Pull Request That Taught Me Humility

The Pull Request That Taught Me Humility

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.

Quick Answer

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 PR I was so proud of

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.

Photo by Negative Space on Pexels

The review that rearranged my brain

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.

Clever is a cost the whole team pays

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.

What I actually changed in that PR

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.

• I killed the metaprogramming. The magic that collapsed everything became three plain, explicit functions. More lines. Zero mystery.
• I let some repetition live. A little duplication that's obvious beats a clever abstraction that's opaque. I stopped treating every repeated line as a crime.
• I optimized for the diff, not the file. I asked: "what will adding a new type look like as a future PR?" In my clever version, that diff was scary. In the rewrite, it was a few obvious lines. That's the metric that matters.
• I deleted my explanatory paragraph. Because the code no longer needed it. That deletion felt better than the paragraph ever had.

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

Photo by Lukas Blazek on Pexels

How I take code review now

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.

The bottom line

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?"

Key Takeaways

• Optimize code for the team's future readability and changeability, not for your own ego or cleverness at write-time—clever abstractions often create hidden costs for every future reader.
• Replace clever metaprogramming or generic engines with explicit, repetitive-but-obvious code when the abstraction forces teammates to reverse-engineer your mental model to make changes.
• Treat every confused code review comment as data, not insult: if a smart reviewer struggles, the code is confusing—rewrite to eliminate the need for explanations, not to win the argument.
• Prioritize 'boring' code that can be skimmed and trusted at 2am during an incident over impressive-but-opaque solutions—senior engineers design simplicity, not complexity.
• Use the 'future PR diff' test: if adding a new feature or type looks scary in the diff, the code has failed—rewrite until changes are obvious, even if it means more lines or repetition.
• Reframe code reviews as gifts, not attacks: the goal is improving the code’s future maintainability, not proving who’s right—separate your ego from the diff to grow as an engineer.