Chapter 6: Burnout is a Broken Loop

“And once the storm is over, you won’t remember how you made it through, how you managed to survive. You won’t even be sure whether the storm is really over. But one thing is certain. When you come out of the storm, you won’t be the same person who walked in.”
— Haruki Murakami

I didn’t recognize it while it was happening. That’s the part nobody tells you. You’d think something that significant would announce itself, that there’d be a clear moment where you could say, “Ah, this is burnout. I should do something about this.” There isn’t. The color drains out of the world so gradually that you don’t notice until everything is gray.

What I noticed instead was irritation. Small things that shouldn’t have bothered me started to feel unbearable. A flaky test. A meeting that ran long. A pull request with too many comments. Each one scraped against something raw. I told myself I was just tired, just stressed, just going through a rough patch. I kept pushing, because that’s what you do. You push through.

The logic felt airtight: things are hard now, but if I just keep going, I’ll get to the other side. There’s a deadline, a release, a milestone. Once I clear it, I’ll rest. I’ll recover. Things will feel normal again.

This is the broken loop. This is recursion without a base case. You keep calling the same function, expecting a different result, but there’s no exit condition. The stack grows. The resources deplete. Eventually, something gives.

For me, it gave on an ordinary Tuesday. I don’t remember what triggered it, some minor frustration that would have rolled off me in a healthier state. I stood up, told my manager I was done, and walked out. Not in a dramatic rage, but with a strange calm that felt more like surrender than decision. I didn’t have a plan. I just couldn’t do it anymore.

I didn’t write code again for over a year.

The Shape of It

Burnout isn’t exhaustion, though exhaustion is part of it. Exhaustion you can sleep off. Burnout is more like numbness, a persistent inability to care about things you know you should care about.

I remember staring at problems that would have fascinated me a year earlier and feeling nothing. Not frustration, not confusion, just a flat absence of engagement. The work that used to pull me into flow became a series of motions I moved through mechanically. I was phoning it in, and I knew I was phoning it in, and knowing didn’t help. If anything, it made it worse. Now I was burned out and disappointed in myself for being burned out.

The joy in problem-solving was the first thing to go. Then the satisfaction of a clean solution. Then the interest in learning anything new. What remained was obligation and irritation, the sense that I had to keep doing this thing I no longer wanted to do, surrounded by problems I no longer wanted to solve.

Flow, the state we talked about in Chapter 3, started to feel like something that had happened to someone else. I remembered it the way you remember a vacation from years ago: yes, that was nice, but it has nothing to do with the present. The idea that I might feel that way again seemed not just unlikely but almost physically impossible, like being told I might one day breathe underwater.

Why You Can’t See It

The cruelest part of burnout is that it compromises exactly the faculties you’d need to recognize and address it. You can’t think clearly about your own thinking. You can’t feel accurately about your own feelings. The instrument you’d use to diagnose the problem is the thing that’s broken.

From inside, it doesn’t feel like burnout. It feels like the world has changed. The work has gotten worse. The codebase has gotten more frustrating. The colleagues have gotten more annoying. Everything external seems to be the problem because the internal lens is too foggy to examine itself.

I spent months thinking I was just in a bad job, or a bad team, or a bad phase. If I could just fix the external thing, the internal thing would resolve. So I pushed for process changes, complained about architecture decisions, argued in meetings I would previously have let go. I was trying to solve the wrong problem with increasing desperation, and the desperation made everything worse.

Looking back, the signs were obvious. The irritability. The loss of joy. The inability to be present even when I wasn’t working. The way weekends stopped feeling like recovery and started feeling like just a different texture of exhaustion. But you can’t see the signs when you’re standing inside them. They’re not signs; they’re just the way things are now.

The Exit

Walking out wasn’t a decision I made rationally. It was more like a circuit breaker tripping. The system had exceeded its capacity, and something shut off to prevent further damage.

In the months that followed, I didn’t miss coding. I didn’t think about it much at all. I started a small business, something completely unrelated to software, and poured myself into the tangible problems of physical inventory and local customers and cash flow that didn’t abstract into anything. It was exhausting in a different way, but it was a clean exhaustion, the kind that sleep actually fixes.

I’m not recommending this path. Quitting on the spot with no plan is a privilege not everyone has, and even for me it was reckless. But it was also necessary. The loop wasn’t going to break from inside. I had to exit the function entirely.

The Return

The business needed software. Nothing fancy, just tools to track inventory and manage orders, things I could have bought off the shelf but that didn’t quite fit my workflow. So I started building them, reluctantly, in the margins of my actual work.

Something strange happened. The code was easy. Not technically easy, but emotionally easy. I wasn’t building it for a deadline or a manager or a performance review. I was building it because I needed it to exist, and nobody else was going to make it for me. The problems were mine, which meant solving them felt like solving something real rather than satisfying someone else’s abstraction of what mattered.

More than that: I controlled the scope. I decided when it was done. For the first time in years, I had authority over the exit condition. No one could move the goalposts because I owned the goalposts.

I’d stay up late adding features no one had asked for, just because they seemed useful. I’d refactor functions that were working fine, just because they could be clearer. I recognized this feeling. It was the feeling I’d had as a kid, when I first learned that I could make the computer do things, that problems I couldn’t solve any other way could be solved by writing code.

The joy snuck back in sideways. I wasn’t trying to recover from burnout. I wasn’t following a wellness plan or practicing self-care. I just needed to build something, and in building it, I remembered why I’d started doing this in the first place.

Eventually, I closed the business and went back to the software industry. Not because the business failed, but because I realized I wanted to write code again. Wanted to, not had to. That distinction mattered more than I can say.

What I Learned

I wish I had something prescriptive to offer, some set of practices that prevent the loop from breaking. I don’t. What I have is this: the loop breaks when the work stops meaning something, when you’re pushing toward a goal that keeps receding, when the rest you’re promised keeps getting deferred.

The recursion needs a base case. There has to be a point where you stop calling the function and return something. A milestone that actually ends. A rest that actually restores. A success that actually registers as success instead of just clearing the way for the next demand.

If you’re lucky, you notice before the stack overflows. You notice the color draining, the joy fading, the irritation building. You notice that you’re pushing toward a finish line that doesn’t exist. And you build in a base case: a boundary, a stopping point, a condition under which you return instead of recursing.

If you’re not lucky, if you’re like me, the circuit breaker trips on its own. You exit the function involuntarily, and you spend a long time in the call stack of recovery, not sure if you’ll ever want to come back.

I came back. Not everyone does. Some of the best engineers I’ve known left the industry during burnout and never returned. They’re doing other things now, things that don’t deplete them the same way. That’s not failure. That’s a different kind of base case.

Still Running

I still burn out sometimes, in smaller ways. I’ve learned to recognize it faster now, to notice when the color starts to fade. The practice isn’t preventing burnout; it’s catching it earlier, building in the base case before the stack gets too deep.

The chapters in this section have been about the self: humility, identity, flow, simplicity, silence. They’ve been about the internal conditions that shape the code we write. Burnout is what happens when those conditions are neglected for too long, when you optimize for output and ignore the system producing it.

You are the system. The code is just the output. If you run yourself without maintenance, without rest, without the things that restore your capacity to care, the output degrades. Not immediately, but inevitably. The loop breaks.

Take care of the system. Build in the base case. And if the color starts to drain, pay attention. It’s not the world getting worse. It’s a signal from somewhere deeper, asking you to stop recursing and return.