Preface
I started making my living quite early, mostly by playing and teaching guitar. Growing up in emerging Poland, watching my parents work relentlessly just to get by, taught me one thing: if you want to succeed, you do more, faster, better. That conviction followed me everywhere – from music to programming.
To be fair, it landed on fruitful ground. Being overly ambitious is definitely a part of my personality that makes me both stronger and fragile. It’s also the part to which I owe my greatest successes – and the part that makes it hard for me to accept when things don’t go as planned.
When I reflect on those almost two decades of professional work, one pattern emerges clearly: doing more doesn’t always mean achieving more.
The Hustle Culture
I heard it constantly: over-deliver to build value. Go above and beyond.
And you know what? It works. Until it doesn’t.
I’d commit to improving everything I saw that needed fixing. The recognition came. I built a reputation as someone who got things done. The person who stayed late. Who took ownership.
But then people got used to it. My extraordinary became ordinary. The rewards stopped coming, but the exhaustion didn’t.
It is not enough to be busy. So are the ants. The question is: What are we busy about?
— Henry David Thoreau, letter to Harrison Blake (1857)
In software development, this has a specific flavor: pushing hard on a feature to meet a deadline, only to watch it get deprioritized right after. Staying until midnight to finish a “late” project, discovering the next morning it’s delayed anyway. The refactoring you do because the code “should” be better while your actual commitments slip.
You’re taking on debt to pay the interest on previous debt. Eventually, something breaks.
What Changed
Let me be clear: I haven’t figured this out. I’m still learning. I still work hard. I still care deeply about quality and delivering value. But now I’m more intentional about where I invest my energy.
It started with urgent requests—production fires that “no one owns,” cross-team asks, legacy code emergencies that somehow became my responsibility.
I started evaluating them differently. Not refusing automatically, but asking:
- Does this align with actual priorities?
- Is this the highest-impact problem I can solve right now?
- Who really owns this?
At first, I felt guilty. But then I realized: not all problems are my problems. And trying to solve all of them means solving none of them well.
Sometimes just flagging an issue is valuable. Sometimes a conscious decision not to do something brings more value by creating space for higher-impact work.
Besides the noble art of getting things done, there is the noble art of leaving things undone. The wisdom of life consists in the elimination of non-essentials.
— Lin Yutang, The Importance of Living
In practice, the shift isn’t dramatic. It’s in small, deliberate decisions:
- Shipping good code instead of perfect code when it matters.
- Evaluating whether urgent work aligns with priorities before jumping in.
- Protecting focus time so I can deliver better work, not just more work.
Redefining what “meaningful work” means has been key. Sometimes it’s staying late to unblock a teammate. Sometimes it’s stopping your own work to review a PR that moves the project forward. Sometimes it’s saying no so you can focus on higher-impact problems.
The key is making it a conscious choice, not an automatic response.
And yes, I still give in sometimes. I still feel tempted to fix everything I see. But at least now I’m aware of it.
Still Figuring It Out
When I see code that should be better but I ship it anyway, something inside me resists. The voice that says “just this once” is loud. The fear that I’ll be seen as lazy creeps in. I’m writing this and I can already feel the pull. There’s a refactoring I want to tackle. A colleague who needs help. A process that “someone should fix.”
The instinct doesn’t go away. The ambition that got me from teaching guitar at 16 to staff engineer – it’s still there. I don’t want to kill it. I just want to point it somewhere that actually matters.
Some days I get it right. I think about priorities. I focus on what actually has impact. I protect time so I can do good work.
Other days I fall back. Stay too late. Take on too much. Say yes without thinking.
But I remember: the midnight deploys that didn’t matter. The perfect code that got deleted. The projects I killed myself for that got dismissed anyway. Over-delivering didn’t save me from any of that. It just made me more tired when it happened.
Burning out doesn’t help anyone – not me, not my team, not what we’re building. You can’t sprint forever.
At least now I see the pattern. Tomorrow I can choose differently.
Because that’s what I’ve come to believe: over-delivering isn’t about doing more. It’s about doing less, but making it matter. Finding purpose instead of chasing the next urgent thing. Being calm and focused, not scattered and reactive.
Real over-delivering isn’t about heroic effort. It’s about intentional impact – and sustaining yourself along the way.
