Sustaining Passion Over a Decade in Tech: Avoiding Architect Burnout

Boredom and burnout feel identical when you are inside one of them. Flat affect, dread before opening the laptop, the sense that nothing is worth starting. So people reach for the same fix for both, and half the time it is the wrong one. Boredom is capacity sitting idle. Burnout is capacity overdrawn. One wants a harder problem. The other wants the load taken off. Pile a side project onto someone running a deficit and you push them further under. Tell a bored engineer to rest and they keep rotting at a slower rate.

Eleven years in backend work, and the thing that wore me down was never the hard problems. It was the months where every problem had the same shape.

Around year six I was the on-call architect for a Laravel monolith three teams deep. My week was reviewing other people's pull requests, explaining for the fortieth time why a Redis lock kept expiring before the job finished, and sitting in meetings where I already knew the answer and waited for the room to get there. None of it was hard. All of it drained me. High volume, zero novelty. Bored and overloaded at the same time, which sounds contradictory until you have spent a quarter living in it.

What pulled me out was not rest. It was a problem nobody had assigned.

We had a CAD automation pipeline that generated manufacturing geometry from a web app. The round trip to a cloud-hosted CAD kernel cost two to four seconds per operation, slow enough that the shop-floor operators stopped trusting the output and went back to drawing by hand. I spent a few weekends moving the kernel call to a local agent on the floor machine, talking to it over a WebSocket instead of HTTP. Latency dropped under 200 milliseconds. Along the way I learned how Babylon.js handles on-demand rendering, broke it three times, and read the Swoole source to figure out why my connections kept dropping.

That work was harder than my day job and it cost me nothing. I came back to the PR queue with more in the tank, not less. The hard problem was the rest.

So I started managing the two states on purpose, as separate things. When I notice the draining-but-easy feeling, I cut load. I hand the lock-expiry question to someone who has not answered it forty times, partly because they will explain it better and partly because I should not be the one explaining it again. I decline the meeting where I am furniture. I stop reviewing every PR and review only the three that touch code paths that can lose data.

When I notice the idle feeling, I add a genuinely hard problem, and I make sure it is one where I might fail. The CAD latency work mattered because I did not know going in whether it would work. A problem you are certain you can solve does nothing for boredom. It is just more volume wearing a different label.

For years I had it backwards. I reached for rest when I was bored and reached for a new project when I was burned out. Rest does nothing for an idle mind, and you cannot heal an overdrawn one by spending more.

The signal I watch now is small and specific. When I open a familiar ticket and feel a flicker of dread that has nothing to do with how hard it is, that is overload, and the move is to subtract. When I open a hard ticket and feel nothing at all, no pull toward it, that is the idle state, and the move is to go find something I am not sure I can do.