I Treated Myself Like an Infinite Resource

I spent an enormous amount of effort carefully optimizing every part of the system, and almost none of it on the single most important and least reliable component running all of it: me. I treated myself as an infinite, always-available resource — a machine that could run at full output indefinitely — and the project paid for that mistake, repeatedly and expensively.

This is the lesson I resisted the longest, because admitting it felt like making excuses. It is not an excuse. It is just an accurate description of a constraint I refused to model, and refusing to model a real constraint does not make it go away. It only makes it surprise you.

The one component I never modeled

I prided myself on thinking carefully about limits. I reasoned about the capacity of every part of the system, its failure modes, how it would behave under load, where it would break. Every part, that is, except one. I never once applied that same engineering honesty to myself.

Implicitly, without ever stating it, I had assumed I could run at full output forever — that my energy and focus were unlimited and permanently on tap, that the person doing the work had no capacity ceiling and no failure modes worth planning around. No competent engineer would ever model a component that way. You would never design a system on the assumption that one critical part has infinite throughput and never needs maintenance. And yet that is precisely how I modeled myself, without noticing I was doing it.

Sprints that ended in craters

The pattern was always the same, and it took me an embarrassing number of repetitions to see it. There would be a burst of intense, exhilarating work — long stretches of total focus, running far past any sustainable limit, because it felt productive and urgent and good. And then, with complete predictability, the crash. Days, sometimes weeks, where I could barely work at all, where the well was simply dry and no amount of trying refilled it.

And every single time, I blamed myself. My discipline, my weakness, my failure to push through. I treated the crash as a personal moral failing, a thing a tougher person would not have suffered. It never occurred to me, for a long time, that the crash was not a failure of character at all. It was the entirely mechanical consequence of running a finite resource past its limit. The resource did what finite resources always do when you overrun them. The only surprising thing was that I kept being surprised.

Burnout is a systems failure, not a willpower failure

This is the reframe that finally changed something. I had been treating my collapses as failures of will — I should have been stronger, should have pushed through, should have wanted it more. But burnout is not a character flaw, and treating it as one guarantees you will keep causing it.

Burnout is simply what happens when you run any system past its sustainable capacity for long enough. It is a systems failure, not a moral one. Calling it a willpower problem is like calling an overheated engine a cowardice problem — it fundamentally misdiagnoses what went wrong, and so it prescribes exactly the wrong fix. The answer to an overheating engine is not to demand it be braver. It is to stop running it past the limit it was always going to have. More willpower applied to an exhausted operator does not produce more output. It just produces a worse crash.

The math of pace

Underneath this is an arithmetic I had completely ignored. A long, hard project is not won by peak output in any single moment. It is won by total output integrated over a very long time. And here is the thing that should have been obvious: the sum of a moderate, sustainable pace held steadily for many months vastly exceeds the sum of heroic sprints punctuated by craters.

The sprint feels faster. In the moment, it genuinely is faster. But over the actual distance of the project, it is far slower, because the crashes cost more than the bursts ever gained. Every spectacular week of overwork bought a dismal fortnight of recovery, and the trade was always a loss when you did the honest accounting across the whole span. I had been optimizing for how fast I felt in the moment, which is precisely the wrong variable when the race is measured in months.

Rest is an input, not a betrayal

Part of what kept me trapped was how I thought about rest. I treated it as the absence of work — time stolen from progress, an indulgence to feel guilty about, evidence of insufficient dedication. So I minimized it, and felt virtuous for minimizing it.

But for a finite resource doing sustained cognitive work, recovery is not the opposite of output. It is a required input to output. The rest is not time taken away from the work; it is part of what makes the work possible at all. Refusing to rest is not dedication. It is running a machine without maintenance and then treating the inevitable breakdown as bad luck rather than the direct, foreseeable result of skipping the maintenance. I had mistaken the neglect of a requirement for a virtue.

Designing for the operator

So eventually I started doing the obvious thing I had avoided for so long: designing the project around the actual constraints of the person running it, exactly the way I would design around any other real limitation. A pace I could genuinely hold, rather than one that looked impressive and ended in collapse. Deliberate buffers for the bad days, because there will always be bad days. An honest accounting of my own capacity as a finite, variable, maintainable thing — not an infinite engine I was failing to live up to.

This felt, at first, like lowering my standards. It was the opposite. It was finally taking the real system seriously, including the part of it made of a person, instead of pretending that part was something it could never be.

The deeper lesson: you are the bottleneck you refuse to model

What it comes down to is this. In any project carried mostly by one person, that person is the most important component in the entire system — and, perversely, the one we are most reluctant to treat as a real, limited, maintainable thing. We will lovingly optimize the code and ruthlessly abuse the operator, and then wonder why the whole thing keeps stalling.

But the project only ever moves while the operator moves, and the operator is not infinite. Sustainability is not a soft, optional, self-indulgent nicety to get to once the real work is done. It is the hard constraint that all the rest of the work has to fit inside. I spent a long time treating the most critical part of my system as the one part that did not deserve to be engineered. The project could not outrun that mistake, and neither, it turned out, could I.

— No signals, no returns, not investment advice.