When a Fire Goes Out: On Overwhelm and Burnout
Part of a "Software Engineering Enchiridion"
I have a confession: Overwhelm and burnout used to be my constant companions. Not enemies per se, more fellow travellers always trying to entice me to do “just a little more, and then you’ll be done.”
For me, and perhaps for many in software development, this comes from a place of addiction. Addiction to approval. An intoxicating relationship with the next pat on the back from someone. Anyone. Even just me.
I used to think it was just a need for success. That perhaps this was a healthy drive and I just needed the right recipe to harness it. Then I realised that, without fail, every few months I hit a wall. I’d have to stop. I’d burn out, taking everything around me with me.
This stopped me in my tracks. Literally. I hit illness; in my case I hit cancer.
When asked about my lifestyle I honestly had to list off a collection of ills that all contributed to my risk profile. But the one the doctors highlighted was not the ones I thought were obvious. They centred on my addiction to work. They centred on years of bouncing from one burnout to the next. They focussed on chronic stress.
I had no idea that my addiction to approval could threaten my life, but that’s exactly what it did.
This entry in the software engineering enchiridion comes from the heart. One small note to you to tell you that you’re not alone if you too struggling with overwhelm and burnout, whatever might be your reasons and factors. It is a hope to help you avoid those risks. Maybe even save your life.
These days they are my travelling companions no longer. I had to reset to recover, to come back from a brink of my own making.
Take your own wellbeing as a software developer seriously. Watch for your own signals of overwhelm and burnout. Not just “sucking them up” and not treating them as “just normal.”
Seeing overwhelm and burnout as the system alerts they are. As a real threat to you. One to trigger an L2 incident of your own to learn from, before they become an L1.
On Overwhelm and Burnout
You don’t notice it at first.
It creeps in like bad weather over the ocean.
A deadline here.
A late-night push there.
Your inbox fills. Your pulse quickens. Your calendar turns into a minefield.
At first it feels good. The rush of being needed. The glow of approval. The strange glamour of chaos. Like an L1 on-call incident at full tilt on a Friday night, and you’re the team member with the answer after hours of log wrangling.
But soon the rush curdles.
You wake up already tired. You stare at code that looks like hieroglyphs. The joy that once lit your work is gone, replaced by the dull thud of obligation.
This is overwhelm: the slow drowning in a sea of JIRA tickets, demands and cognitive burden. The constant context switch with nowhere for your attention to settle.
This is burnout: the fire that dies because nobody remembered to feed it.
Maxim
Burnout is not proof of dedication. It is proof of neglect — of your body, your mind, your team, your craft.
Rationale
We confuse exhaustion with effort, and overwhelm with importance. The truth is harsher: you are not more valuable broken. You are just breaking.
Practices
Work in sprints, not marathons.
Respect the limits of attention as you respect the limits of CPU.
Learn how your cognition works, everyone is unique.
Create slack in schedules, because no system survives at 100% load.
Invest in real recovery: rest, reflection, and renewal are not luxuries but requirements.
The Lies We Tell Ourselves
Believing burnout only happens to “weaker” developers.
Romanticising the all-nighter.
Thinking you’ll fix your exhaustion “after this one release.”
Checklist
Did you sleep at least 7 hours last night?
Can you recall, without hesitation, the last time you felt joy at work?
Do you have at least one full day off per week, with no code, no slack, no guilt?
Further Reading
Christina Maslach, Burnout: The Cost of Caring
Cal Newport, Deep Work
Software is built by people, not machines. It’s built by you, and you can burn out.
When you overheat the system, it crashes. When you keep pulling from the well without pouring anything back, it runs dry. Overwhelm turns sharp minds blunt. Burnout turns good developers bitter. In time, both destroy the very platforms, products, teams and people they were meant to support.
They can kill, slowly but surely.
Burnout is not a badge of honour. It is the corrosion of craft, the undoing of teams, and the silent killer of quality and people. Guard your fire. Set boundaries. Learn to say “no” with the same clarity as you say “yes.”
The world will take every ounce you give it; you must be the one to leave something in reserve.
If you enjoyed this article in the Software Engineering Enchiridion series you might also enjoy:
