Your Broken Promises Aren't Failures, They're Just Reality
The Mental Shift That Frees You From Deadline Guilt
You estimated two days for that feature. Your team lead approved it. You felt pretty good about yourself. You’ve built this kind of thing before, you know what you’re doing.
Then production explodes.
Suddenly you’re pulled into firefighting mode. Three hours of debugging turns into three days. The QA environment goes down. The designer decides – oh, by the way – the whole flow needs to change. And that “simple” API integration? Yeah, the documentation was lying. The endpoints don’t work how they say they do.
Now you’re three sprints behind on something you promised would be done by Friday. And you feel like shit about it.
Not because you didn’t try. Not because you slacked off. But because in your head, you made a commitment, and you failed. You’re a professional who can’t even estimate their own work properly. What kind of developer are you?
The Weight of Broken Promises
Here’s the thing that eats at you: it wasn’t even your fault. The production incident wasn’t something you could have predicted. The designer changing requirements wasn’t in your control. The API being broken? That’s on someone else’s poor documentation.
But you still feel guilty. Because somewhere along the way, you internalized this idea that a “good developer” should be able to predict the future. That giving an estimate means you’re making an iron-clad promise. That if you can’t deliver exactly what you said, exactly when you said it, you’re somehow letting everyone down.
We put this pressure on ourselves. Management puts it on us too. There’s this whole mythology around the 10x developer who can see around corners, who never misses a deadline, who can account for every possible dependency and blocker.
It’s bullshit. And it’s making us miserable.
What the Stoics Knew About Uncertainty
The ancient Stoics had a practice that would’ve saved us a lot of Sunday night anxiety. When they made any commitment, they silently added a reserve clause: “fate permitting.”
“I’ll finish this by Friday... fate permitting.” “This feature will take two days... fate permitting.” “We’ll ship this sprint’s work... fate permitting.”
This isn’t about being pessimistic or making excuses. It’s about maintaining your sanity in a job where uncertainty is the only constant.
The reserve clause is mental freedom from the guilt that comes when reality refuses to cooperate with your plans. Because here’s what every developer knows but somehow forgets when giving estimates: you’re making a prediction about a future you don’t control.
The Things You Can’t Control
Think about everything that can derail your estimate:
The production database that decides to corrupt itself at 2 AM on Thursday. The teammate who gets sick right when you need their code review. The VP who swoops in with “just one small change” that rewrites half your architecture. The vendor API that goes down. The deployment pipeline that breaks. The security vulnerability that gets discovered and suddenly becomes everyone’s top priority.
That “two day estimate” you gave? It was based on a world where none of those things happen. And that world doesn’t exist.
The Stoics, particularly Marcus Aurelius and Epictetus, were obsessed with this distinction between what you control and what you don’t.
You control your effort. You control your focus. You control how thoroughly you communicate blockers.
You don’t control dependencies failing. You don’t control requirements changing mid-sprint. You don’t control emergencies that pull you away from your work.
The reserve clause isn’t an excuse for poor planning. It’s not permission to sandbag your estimates or half-ass your work. It’s a realistic acknowledgment that between “I’ll start this task” and “I’ll finish this task” lies a vast ocean of uncertainty.
How This Actually Works
Let me give you a real example. You’re planning sprint work, and someone asks how long it’ll take to build the new payment processing flow.
Without the reserve clause: “Two weeks.” (Internal pressure: “I said two weeks, so it HAS to be two weeks, no matter what happens.”)
With the reserve clause: “Two weeks, assuming nothing prevents it.” (Internal reality: “I’m committing to two weeks of focused effort, but I’m not a fortune teller.”)
See the difference? The second one doesn’t change your external commitment, you’re still saying two weeks. But internally, you’re not setting yourself up for irrational guilt when the QA environment is down for three days, or when the product manager realizes halfway through that they forgot about a critical edge case.
When those interruptions happen – and they will – the reserve clause lets you pivot without the internal narrative of “I’m a failure who can’t keep promises.” Instead, it’s just: “Well, circumstances changed. Let’s adjust.”
The Paradox of Letting Go
Here’s what’s weird: releasing that rigid attachment to guaranteed outcomes often improves your results.
When you’re not defending an estimate like it’s your personal honor at stake, you become more flexible. You communicate blockers earlier because you’re not trying to hide them. You ask for help sooner because you’re not treating the estimate as a referendum on your competence. You’re more honest with stakeholders about risks because you’re not over-promising from ego.
You stop playing this exhausting game of pretending you have more control than you actually do.
And stakeholders? They trust you more. Because instead of the developer who says “two days” and then goes radio silent when it’s taking longer, you’re the developer who says “two days, barring any surprises” and then keeps everyone updated when surprises happen.
You can commit fully to the work while releasing attachment to guaranteed results. The only thing you can actually guarantee is that you will do the work necessary to try to achieve the goal as much as possible. Everything else – the timeline, the exact outcome, the smooth sailing, that’s outside your control.
Baking in Reality
Over time, this mental habit trains you to think differently during planning. You start identifying what’s actually in your control:
Your effort. Your focus. Your communication. The quality of your code. The thoroughness of your testing.
And what’s not in your control:
Dependencies on other teams. Third-party services staying up. Requirements staying stable. Emergencies not happening. The exact amount of time something will take once you account for all the unknowns.
Does this mean you stop giving estimates? No. Does it mean you pad everything to ridiculous levels? Also no.
It means you give honest estimates based on what you know, while acknowledging, to yourself if not out loud, that there’s always some outside thing that can happen that is unforeseen. The QA environment going down. The API changing without notice. The production incident that pulls you away.
That’s not pessimism. That’s reality. And acknowledging reality is the first step to not letting it destroy your mental health.
The Only Constant
As developers, we deal with constant change. We get used to it, eventually. The framework that was hot last year is old news this year. The architecture that made sense six months ago needs refactoring. The requirements that were set in stone last sprint are somehow different now.
But we still try to plan everything like we’re building a bridge, where all the variables are known and the materials behave predictably. Software development isn’t bridge building. It’s more like trying to build a bridge while the river is flooding, people are changing the blueprint mid-construction, and someone keeps yelling about how the other bank moved.
The reserve clause – “fate permitting” – is how you stay sane in that chaos. It’s how you commit to doing great work without committing to controlling things you can’t control.
Quote of the Day:
“Do every act of your life as though it were the last act of your life.” — Marcus Aurelius
👉 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