Technology Aug 31, 2026 · 8 min read

You are not a software engineer: how I protect myself from burnout

Someone asked me at the end of a talk recently whether I'd ever burnt out. I said no. I put it down to still loving the work, and to communicating pressure rather than absorbing it, and we moved on to the next question. It was a true answer and a useless one. So I've spent a while since unpicking w...

DE
DEV Community
by Ollie Church
You are not a software engineer: how I protect myself from burnout

Someone asked me at the end of a talk recently whether I'd ever burnt out. I said no. I put it down to still loving the work, and to communicating pressure rather than absorbing it, and we moved on to the next question.

It was a true answer and a useless one. So I've spent a while since unpicking what I actually do, to see whether there's anything in there someone could use.

Positive thinking won't fix your manager

In the Q&A I described two friends. The first up until 3am building side projects because they were too excited to stop. This is a choice, and stopping is available. Nobody is waiting on a hobby project. If it's costing you your sleep and sanity, go to bed.

The second friend was ground down by corporate deadlines, they felt their employer was a source of constant pressure. What I said at the time was that my friend could have taken some responsibility for communicating those choices instead of holding it all themselves. I still think that, and I've written before about bringing stakeholders into a trade-off rather than sulking about a decision you've been handed. Don't accept the impossible deadline, don't refuse it outright either, find the version where you're both after the same outcome.

But some deadlines aren't negotiable and some managers aren't collaborators. When you've pulled every lever on your side and nothing moves, the question worth asking is what actually happens if the impossible demand goes unmet. Is it broadly fine to do your best and finish at your normal time? Often it is, and the pressure was never as solid as it felt.

If the answer is no, and the consequences are genuinely severe, then dust off the CV and get ahead of what looks like the inevitable end of your time there. Sometimes the money makes up for it, and that's a perfectly legitimate personal choice about how much pain a person is willing to endure in return for the compensation. But if that balance comes out negative, staying put is unlikely to yield a better outcome than exploring something new.

Epictetus, a Stoic teaching in the Roman empire, split the world in two. Some things are up to us, our judgements and our responses and what we choose to do next. Most things aren't. We suffer, he reckoned, from our judgements about events rather than from the events themselves.

In Derren Brown's Happy, he supports this but goes after the misinterpretation presented as the self-help promise that belief and the right attitude will deliver the outcome you wanted. His objection is that it overpromises, ignores how much of any outcome is chance, and quietly hands you the blame for results you were never holding. He points at prisoners of war who came through captivity on Stoic acceptance, while the optimists waiting on a release date that kept not arriving were the ones who broke.

So a bad workplace is not an attitude problem, and no amount of positive thinking will make an uncollaborative manager collaborate. What the split does is stop you spending yourself on the part that was never going to move, and put that energy into the part that is yours: the conversation you haven't had, the trade-off you haven't written down, the CV you haven't updated. Acceptance without passivity.

I am not a software engineer

The other thing I put my lack of burnout down to was the joy and satisfaction of the craft: the problem that's been beating you all week finally coming apart, the thing that was broken now working. That part is real, but I have been doing a lot of thinking about how I sustain that joy.

When I was training for my previous career as an actor, I came across the idea that you shouldn't fuse who you are with what you do, and I waved it off. I was an actor, I liked being an actor, and I had no problem with that being the whole of it. Then I left drama school, and I was acting less and less, and it turned into an identity crisis for me. If I am an actor and I am not acting, what is left?

Referring again to Brown's Happy: we are a story we tell about ourselves, and the story is ours to edit. Once I accepted that being an actor was only one line in my story, changing career stopped reading as a loss and started reading as a new chapter. I was still me.

If my identity were tightly wound up and inseparable from being a software engineer, every rough patch would carry the threat of an existential crisis rather than just being a tough moment, and the only available response would be to push harder. The people I've watched struggle worst are the ones where the work and the person had merged, leaving no version of adjusting that didn't feel like disappearing.

The separation of self from job protects the joy I find in code, because nothing existential rides on it.

When the fun stops, stop

The UK gambling industry ran that slogan for years, and the addiction parallel for some coding hobbyists is unfortunately apt.

Every hobby has frustrating stretches, and finally cracking something that's eluded you for a week is most of the point. But if the overarching feeling when you think about coding is no longer enjoyment, and you find yourself pushing on with hobby and side projects, that is self-destructive behaviour that is likely to end in burnout.

Handling a job that doesn't provide joy is harder, because you can't apply the same fix. Nobody gets to shut their laptop on a Tuesday because the fun has gone, but there are still some choices, some control, you can take.

  • What you volunteer for
  • What you say yes to when your plate is already full
  • Whether it stays inside the hours you're paid for
  • Whether you take the leave you've accrued instead of banking it for a someday that never arrives

The standard burnout advice is a dramatic stop. Step away, take leave, go and do something else entirely. But that is only a necessity when nobody noticed anything until it was an emergency. Check in often enough, with small calibrated corrections, and I believe you can spare yourself the extreme.

A hard month is a hard month

My general advice to junior engineers is to take on the work nobody else wants, because that's where you learn the system and get noticed.

Which could sound like a burnout recipe. It's telling someone at the start of their career to volunteer for extra work that nobody asked them to do, on top of the work they were hired for.

One of the many skills we have to develop as a junior is judgement. Don't take it all on at once. Not on day one. Start with something small.

It's easy to misjudge your workload tolerance, ending up stressed and working late for a few weeks. That's a hard month, and I'd be careful about relabelling every hard month as burnout in itself. Have the hard month, work out what you took on that you shouldn't have, do it differently. Having the same hard month multiple times in a row, from your own ambition, points to a serious lack of self awareness that is unsustainable.

What I should have said

Burnout is a real condition and a serious one, and it seems to land on software engineers acutely. Nothing here is meant to suggest that every person who has had it made an avoidable error, or that a better frame of mind would have spared them. Plenty of it comes out of workplaces that would break anyone.

I don't think I've avoided burnout by just loving the work. What I've actually got is a job title I can put down, a hobby I'm willing to walk away from mid-problem, and a well-practised habit of asking what I'd change rather than what I'd endure.

I'm not immune, but I work on noticing the signs early, which is cheaper than recovering late.

Human written, AI assisted

References

DE
Source

This article was originally published by DEV Community and written by Ollie Church.

Read original article on DEV Community
Back to Discover

Reading List