Care Deeply, Expect Nothing: A Developer's Survival Guide
Embrace the Process, Release the Outcome
You just spent three weeks building the perfect abstraction. Clean interfaces, thoughtful error handling, documentation that doesn’t suck. You’re proud of this one. Your tech lead reads it for thirty seconds and says, “Let’s just add another if statement to the existing function.”
Or maybe it’s the junior developer you spent six months mentoring, the one you stayed late helping debug their first production issue, the one you vouched for in their performance review. They just accepted an offer at another company.
Or it’s Friday afternoon, and leadership just killed the project you’ve been pouring your soul into for the past year. “Shifting priorities,” they say. Your code will never see production.
This hurts.
The Problem with Caring
Here’s the thing about being good at what you do: you care. You care about writing clean code. You care about doing things right. You care about the craft.
And that caring makes you vulnerable.
Because in software development, effort and outcome have this frustrating habit of not lining up. You can write brilliant code that gets rejected. You can build something beautiful that gets shut down for business reasons. You can invest in people who leave. You can do everything right and still watch it all fall apart.
So what do you do?
The obvious answer is to protect yourself. Stop caring so much. Phone it in. Write the shitty code they’re asking for and collect your paycheck. Become the cynical developer who responds to every suggestion with “whatever, it’s all getting rewritten anyway.”
And you know what? I get it. I’ve been there. There are days when cynicism feels like the only rational response to the chaos.
Why Cynicism Doesn’t Actually Work
But here’s what happens when you go down that road: you lose the thing that made you good in the first place.
The cynical developer stops learning because “what’s the point?” They stop mentoring because “people just leave anyway.” They stop suggesting improvements because “no one listens.” They write code that works today and becomes tomorrow’s technical debt.
And worst of all? They’re miserable. Because humans aren’t wired to spend forty-plus hours a week doing something they don’t give a shit about. The armor you built to protect yourself becomes a prison.
The Stoics saw a different way through this. And it’s not about caring less, it’s about caring differently.
The Dichotomy of Control (or: Stop Fighting Battles You Can’t Win)
Marcus Aurelius spent a lot of time thinking about what was in his control versus what wasn’t. As emperor of Rome, you’d think everything would be under his control, right? But even emperors can’t control whether their policies succeed, whether their generals stay loyal, or whether the barbarians decide to invade.
What he could control was his own thoughts, actions, and effort.
Same deal in software development.
You control:
The quality of code you write
The thoroughness of your reviews
The clarity of your documentation
The patience you show when mentoring
The integrity you bring to technical decisions
Whether you refactor that mess or add to it
You don’t control:
Whether your PR gets approved
Whether your project gets greenlit
Whether your carefully considered architecture gets adopted
Whether the people you mentor stick around
Whether your code survives the next reorg
Whether anyone appreciates the extra effort you put in
Your sphere of control ends at the PR button. After you hit submit, you’ve done your part. Everything after that? Not yours.
What the Reserve Clause Actually Means
The Stoics had this concept called the “reserve clause”, basically adding “fate permitting” to your intentions. Not as a cop-out, but as a mental tool.
So instead of “I’m going to get this architecture approved,” you think “I’ll propose this architecture, fate permitting it gets adopted.”
This isn’t lowering your standards or half-assing your proposal. You still do the research, write the compelling RFC, make the case. You give it your best shot. But you’ve mentally prepared yourself for any outcome.
Here’s what this looks like in practice:
Without the reserve clause: You spend a week on an RFC for microservices migration. You’re convinced it’s the right move. The architecture review meeting rolls around. They reject it. You’re furious. You take it personally. You spend the next month bitter and checked out.
With the reserve clause: Same RFC, same effort, same conviction. But you go in thinking “I’ll make the best case I can, and whatever happens happens.” They reject it. You’re disappointed, sure. But you move on. Because you did your part. The decision is out of your hands.
The difference isn’t in the outcome, it’s in how much of your peace of mind you’ve tied to things you can’t control.
Impermanence as Freedom
Everything we build in tech is temporary. That codebase you’re maintaining? It’ll be replaced or rewritten. The framework you just learned? It’ll be legacy in five years. The project you’re grinding on? Might get cancelled next quarter.
This used to depress the hell out of me. Why bust my ass if it’s all going to be thrown away?
But here’s the reframe: impermanence is freedom.
When you know your code is temporary, you can stop clinging to it desperately. You can stop getting defensive in code reviews because someone dared criticize your precious abstraction. You can actually listen to feedback because your identity isn’t wrapped up in whether this specific implementation survives.
You’re a steward, not an owner. The company can cancel your project like the library can recall a book. That’s not a tragedy, that’s just how it works.
What matters is that you do your best work right now, with what you know right now, for the situation you’re in right now. Not because it’s going to last forever, but because that’s what being good at your craft means.
Measuring Yourself by Internal Standards
When you tie your self-worth to external outcomes, you’re fucked. Because outcomes in software development are chaotic. Market conditions change. Leadership changes. Priorities change. Budgets change.
But you can always measure yourself by internal standards:
Did I think clearly about this problem? Did I act with integrity in that meeting? Did I give honest feedback in the code review? Did I help that struggling teammate instead of just being annoyed? Did I do my best with what I knew at the time?
These things are always in your control. And they’re what actually matter.
I’ve written code that got deleted six months later, and I’m still proud of it because I know it was good work. I’ve mentored people who left, and I don’t regret a minute of it because I know I showed up for them. I’ve had projects cancelled, and I can still look back at the craftsmanship I brought.
The work has value independent of the outcome. The virtue is its own reward.
What This Actually Looks Like
The rejected PR: You spent hours refactoring that god-awful service. Made it testable, removed the global state, cleaned up the error handling. Senior dev rejects it: “Too risky right now, let’s just fix the bug.”
Old you: Seethes with resentment. Stops suggesting improvements. Becomes the “I told you so” person when technical debt inevitably bites the team.
Stoic you: Disappointed, but you know you did good work. You learned from the refactoring. Maybe you salvage parts of it for future PRs. You continue caring about code quality because that’s who you are, not because you need approval.
The cancelled project: Six months of work. Dead. Leadership pivot.
Old you: Bitter spiral. “They never finish anything around here.” Updates resume, checks out mentally.
Stoic you: Process the disappointment, then ask: “What did I learn? How did I grow? Was I a good teammate?” The skills you built aren’t wasted. The relationships you strengthened remain. The work had value while you were doing it.
The junior who leaves: You invested time, energy, patience. They got better. Now they’re gone.
Old you: “Never again. Not worth it.”
Stoic you: You helped someone grow. That’s good in itself. The fact that they left doesn’t negate the value of the mentorship. Maybe you stay in touch. Maybe they come back someday. Maybe you never hear from them again. You still did the right thing.
The Long Game
Software development isn’t about necessarily completing projects. It’s about doing your best with what you have at the time. Understanding that what you’re building today will probably be replaced in five years. Hell, maybe next year.
But at this moment, at this time, you make it as good as you can make it.
Not because you’re guaranteed a return on that investment. Not because management will definitely appreciate it. Not because it’s going to last forever.
Because excellence in your craft is how you show up in the world. Because integrity matters more than outcomes. Because you can’t control what happens to your work, but you can control the work itself.
Love the work, not the outcome. When your identity is in the craftsmanship rather than the results, you become resilient to the inevitable disappointments of software development.
You’ll still care deeply. You’ll still fight for what you believe is right. You’ll still feel disappointed when things don’t work out.
But you won’t be destroyed by it.
Because you’ve learned to put your effort and excellence into the things you control, and hold everything else with an open hand.
That’s not resignation. That’s freedom.
Your Turn
I’m curious about your experience with this:
What’s a time you did great work that didn’t get the outcome you hoped for? How did you handle it?
Do you struggle more with caring too much or protecting yourself by caring too little?
What helps you stay committed to quality when the external rewards aren’t there?
Drop your thoughts in the comments. Because chances are, your experience is exactly what someone else needs to hear right now.
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