// March 9, 2026
Shipping Software While Disabled
4 min read
workflowaccessibilityproductivity
// March 9, 2026
4 min read
I build software on an energy budget I don't set. Some days the budget is full. Some days it's a fraction of that, and no amount of coffee or willpower changes the number. I'm not going to itemize the medical side here, because it doesn't change the engineering problem: how do you ship real software when your capacity changes without notice?
[FILL: bio anchor — confirm phrasing before publishing; draft had "I came to development late, after the military," which isn't in the Book Bible or README] I learned this the slow way. Here's what actually works.
Most productivity advice assumes your tank refills overnight. Mine doesn't always. So I stopped budgeting time and started budgeting energy — and the first thing that taught me is that everything spends it, not just writing code.
Deciding spends energy. Context-switching spends energy. Fighting a flaky build spends energy. Reading clever code spends a lot of energy. On a bad stretch — and mine can run [FILL: personal specific, e.g. "days at a stretch with only an hour or two of usable focus"] — those hidden costs are the difference between shipping something and shipping nothing.
Once you see energy as a budget, the rule gets simple: the problem gets the focus, and the plumbing around it gets as little as possible. Everything below follows from that.
In the book I'm writing there's a concept called the Minimum Viable Day: the floor version of your day, defined in advance, that keeps the system alive when capacity is low. The same idea runs my dev work.
My floor for a bad workday is three moves: read the note I left myself, complete one small thing, leave the next note. That's the whole day, and it counts. A ten-line commit that ships is a working system. Zero is the only number that breaks the streak.
Two habits make the floor reachable:
Small, resumable chunks. I break work so that every stopping point is a clean one. Never leave a task in a state that demands an hour of reloading context before you can touch it again — on a bad day, that hour is the whole budget, and the work simply won't happen.
The next-action note. The last five minutes of every session go to writing exactly where to start next time. "Keep working on auth" is a useless note. "Wire the 401 handling in api.ts — the error type is already defined, just needs the redirect" is one a tired version of me can act on without thinking.
The floor exists so that low-capacity days still produce forward motion instead of stalling the whole project.
Every clever choice in your stack is a loan, and future you pays the interest on a day you can least afford it.
I choose boring on purpose:
Mainstream tools with big communities. My site is React and TypeScript — the documented, default path. When something breaks at thirty percent capacity, I want the answer sitting on the first page of search results. Exotic tools cost you exactly when you're least equipped to pay.
Automate anything you do twice. Formatter on save. Linter and type checks in CI. Deploy on push. Every automated check is a decision I no longer have to make and a mistake I no longer have to catch by being sharp. The machine is consistent on days I'm not.
Scripts and checklists over memory. If a task has more than three steps — release, database migration, environment setup — it gets a script or a written checklist. Memory is expensive on a bad day. A text file is free, and it doesn't have bad days.
Write code for exhausted-you. The person reading this function next might be me at forty percent. So: plain structure, obvious names, no smart abstractions that require holding four things in your head at once. If I can't follow the code on my worst day, it's too clever to keep.
None of this is exciting. That's the point. Boring choices don't spend the budget, and whatever the tooling doesn't spend, the actual problem gets.
A rough week will tell you nothing happened. Feelings on low-capacity days are unreliable narrators — they report the effort and skip the output.
The commit log doesn't do that. Neither does a closed-issue list or a simple done-list in a text file. At the end of a week that felt like a loss, I can look at the record and see the floor held: small commits, one fix, a note trail that means Monday starts warm instead of cold. Evidence over feelings. Judge the week by what shipped.
If your capacity varies — disability, chronic illness, caregiving, anything that makes energy a variable — the fix isn't pushing harder on the bad days. It's building a workflow that assumes the bad days are coming: an energy budget instead of a time budget, a defined floor for the worst days, tooling boring enough to run on pocket change, and a record that tells you the truth when your energy won't.
Slower than you'd like, some weeks. But it ships. And a system that ships on your worst day will ship on all the others too.