Why Your Best Work Will Never Get Recognized
The Pursuit of Excellence in Coding (When Nobody's Watching)
It’s 8 PM on a Friday. Everyone else logged off hours ago. You’re staring at a payment processing module that works fine, no bugs, no complaints, no tickets. You could close the laptop right now and start your weekend.
But you don’t.
Instead, you’re refactoring error handling that’s been bugging you all week. You’re cleaning up variable names. You’re adding defensive checks for edge cases that’ll probably never happen. And here’s the kicker: there’s a pretty good chance no one will ever notice this work. Not your manager. Not your teammates. Hell, this entire module might get replaced in the next architectural pivot.
So why do we do this to ourselves?
The Recognition That Never Comes
Let’s be real about how this usually plays out. You spend three days building a comprehensive logging system for transaction reconciliation. You document every edge case. You make the error messages actually helpful for whoever gets paged at 2 AM. You write it like someone’s going to read it, because someone will, eventually.
Three months later, that logging catches a payment mismatch that would’ve taken weeks to track down manually. Your manager mentions it in passing: “Good job finding that bug quickly.” Nobody asks how you found it so fast. Nobody notices the logging infrastructure that made it possible. They just see that you solved a problem.
Meanwhile, the developer who ships fast and messy just got promoted. Their code breaks constantly, but they’re “high velocity.” They’re “getting shit done.” And you’re sitting there wondering if you’re the only one who actually gives a damn about code quality.
This is where most of us hit that wall. That moment where we think, “Why am I even trying?”
The Trap of External Validation
Here’s the thing that took me way too long to figure out: if you’re writing good code for recognition, you’re playing a game you can’t win.
External validation—promotions, praise, those little dopamine hits from code review approvals—they’re all outside your control. You can write the most elegant solution possible and still get passed over for a promotion. You can refactor a critical system and have it go completely unnoticed. You can do everything right and still have clients be unhappy, projects go over budget, or your carefully crafted code get deleted in the next rewrite.
The Stoics figured this shit out two thousand years ago. They called it the dichotomy of control: you don’t control outcomes, you only control your effort and approach. Marcus Aurelius was literally running the Roman Empire, dealing with wars, plagues, and political backstabbing. If anyone had reasons to expect external validation for good work, it was him. But he kept coming back to this same idea: the value is in doing the work with integrity, not in who notices.
And I’m not telling you this as some philosophical thought experiment. I’m telling you this because it’s the only thing that’s kept me from burning out over 25 years in this industry.
What You’re Actually Building
When you write clean code that no one’s watching, when you add those defensive checks, when you document the “why” and not just the “what”, you’re not building a feature. You’re building yourself.
Every shortcut you take, every “I’ll fix it later” that you don’t fix, every time you ship code you know is questionable, that’s not just technical debt. That’s erosion of your own standards. You’re training yourself to accept mediocrity. You’re teaching your brain that quality is optional, that it only matters when someone’s looking.
And here’s what that leads to: developers who can’t tell the difference anymore. Who genuinely don’t see the problem with nested try-catches seven levels deep. Who think “it works” is the same as “it’s done right.” Not because they’re bad developers, but because they’ve spent years optimizing for speed over quality, and their internal compass is screwed up.
The opposite is also true. Every time you do the work right, especially when no one’s watching, you’re strengthening that internal standard. You’re building the kind of developer who can look at code and just know it’s wrong, even if it passes all the tests. You’re developing instincts that become your competitive advantage.
The Work That No One Sees
Some of my best work has been completely invisible. I once rebuilt the error handling in a legacy .NET payment system that had been held together with duct tape and prayers for years. Spent two weeks on it. Made sure every exception was caught at the right level, every error message actually helped diagnose the problem, every failure mode was logged with enough context to figure out what went wrong.
You know how many times that error handling prevented catastrophic failures? I have no frickin idea. That’s the point. Good defensive code prevents problems that never happen. No one writes you a thank-you email for the database deadlock that didn’t occur because you properly implemented transaction isolation. There’s no Slack message celebrating the race condition that never materialized because you understood thread safety.
But I sleep better knowing that code is out there. And when shit does hit the fan, because it always does eventually, I know I’ve given whoever has to debug it the best chance of actually understanding what went wrong.
Building Intrinsic Motivation
How do you maintain standards in an environment that often doesn’t reward them?
You have to find satisfaction in the craft itself. Not in some precious, artisanal bullshit way, but in the basic human satisfaction of doing something well. The same satisfaction you’d get from cooking a good meal even if you’re eating alone, or fixing something around the house that no one else will notice.
Here’s how I think about it: Every line of code I write is a choice about what kind of developer I want to be. Not what kind of developer I want others to think I am, what I actually want to be when no one’s looking.
When I’m tempted to ship something I know is questionable, I ask myself: Is this the standard I want to live with? Not “will anyone notice?” Not “will this come back to bite me?” Just: Is this acceptable to me?
Most of the time, that’s enough. Not always—sometimes the deadline is real and the tradeoff is necessary. But even then, I’m making a conscious choice, not taking a shortcut out of laziness or because I think quality doesn’t matter.
This is what the Stoics meant by virtue ethics. Virtue wasn’t about being a good person so others would praise you. It was about having internal standards that didn’t depend on external validation. It was about being able to look yourself in the mirror and know you’re living according to your own principles.
The Long Game
The beautiful thing about intrinsic motivation is that it makes you sustainable. You can’t burn out from lack of recognition when recognition was never the point. You can’t be demoralized by office politics when you’re not playing the political game. You can’t have your motivation destroyed by a bad manager when your motivation doesn’t depend on their approval.
This doesn’t mean you become some zen master who doesn’t care about anything. You still get frustrated. You still wish people noticed your good work. You still want the promotion and the raise. But those things become bonuses, not the foundation of your motivation.
And here’s the thing nobody tells you: over the long term, this approach actually tends to work out better career-wise too. Because the developers who consistently do good work, who have strong internal standards, who can be trusted to do the right thing even when no one’s watching—those developers become valuable. Maybe not immediately, maybe not as flashy as the person who ships fast and breaks things, but over years? That reputation matters.
But even if it doesn’t work out that way, even if you end up at a company that truly doesn’t value quality, you’ve still built something they can’t take away from you. You’ve built your own skills, your own standards, your own sense of what good work looks like. That’s portable. That stays with you.
Conclusion
This is hard. It’s hard to care about code quality when you’re the only one who seems to give a shit. It’s hard to maintain standards when the team is cutting corners and shipping faster. It’s hard to write good code when the entire codebase is a dumpster fire and your contribution feels like pissing on a forest fire.
The code you write shapes who you become as a developer. Every decision, every shortcut, every moment of “good enough”, it all adds up. You’re either building the kind of developer who can take pride in their work, or you’re building the kind who’s just collecting paychecks until retirement.
Your internal standards are the one thing in this entire industry that you actually control. The recognition, the promotions, the perfect codebase, the appreciative users, it’s all outside your control. But how you approach the work? That’s yours.
Quote of the Day:
“Make the best use of what is in your power, and take the rest as it happens.” - Epictetus
👉 If you enjoy reading this post, feel free to share it with friends!
Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏
You can find me on X and Instagram.
Also, I just launched a new YouTube channel - Code & Composure