A while back I wrote that you don't need perfect code — you need a safety net that talks back. People read it as an engineering post, which it was. But I left something out. I don't build those systems only because they're good engineering. I build them because they're how I stay functional as a developer with ADHD and autism. The clear error messages, the validation that runs before anything else does, the tests that fail loudly and specifically — those aren't just reliability features to me. They're external memory. They're the structure my own brain doesn't reliably hold on its own.
I think good engineering and accommodation are, quietly, the same thing. Here's what I mean.
What breaks me isn't difficulty. It's silence.
The hard part of a bug, for me, is almost never the logic. I can sit with a hard problem for a long time. What wrecks me is ambiguity: the silent failure, the config that loads fine and then falls over three steps later with no clue why, the "it just doesn't work" with nothing to grab onto.
That's not a character flaw and it's not laziness. It's what happens when a system asks me to hold its entire state in my head at once. My working memory doesn't do that well. So a system that fails quietly is asking me for something I can't reliably give and a system that fails loudly, early, and specifically is handing the context back to me instead of demanding I reconstruct it. Here is the difference a message makes:
This is the whole thing in miniature. Two versions of the same failure:
Error: invalid configuration
versus:
Error: 'timeout' must be a positive integer (got: "30s")
in pipeline.yaml, line 14
hint: use a number of seconds, e.g. timeout: 30
The first one asks me to become a detective. The second one just tells me what's true and where to go. For any developer that's a nicer experience. For a brain that struggles to hold a stack of context, it's the difference between staying in the work and losing the whole thread.
Once you notice that, you start seeing accessibility everywhere in ordinary engineering. Good defaults reduce decisions. Loud tests remove the "did I break something?" background anxiety. Reproducible environments mean I don't have to remember the fourteen steps that make the thing run. None of that is a special accommodation bolted on for disabled developers. It's just good design that happens to help most where people have the least slack to spare.
Where AI actually fits
AI landed in the middle of all this as, essentially, one more thing that talks back. And I want to be honest about it, because the hype and the doom are both exhausting. Where it genuinely helps:
- Activation energy. The blank page is a real, physical barrier for me. Getting from nothing to something I can react to is the expensive part, and reacting is much cheaper than initiating. A rough first draft I can push against gets me moving in a way willpower never has.
- A software that answers. Talking through a design out loud, even to a model that's sometimes wrong, helps me externalize the thought instead of looping on it internally.
- Turning vague intent into a starting structure. "I want a validator that does roughly this" into a skeleton I can then correct. The correcting is where I'm actually good.
But also AI is confidently wrong in exactly the way that hurts me most. It papers over the silent-failure problem by inventing a plausible answer, which is the one thing my whole workflow is built to prevent. So I don't let it replace the safety net. I put the safety net around it. Types, tests, and validation gatekeep its output the same way they gatekeep mine. It's a drafting partner working inside a system that checks its work. That distinction matters more for me than for most, but I'd argue it's the healthy way for anyone to use these tools. The model isn't the source of truth. The system that verifies the model is.
The pattern underneath all of it
If disability taught me one thing as an engineer, it's this: don't rely on willpower or memory to hold a system together. Externalize it. Make the system carry the load, so that being tired, or distracted, or in a fibro flare, or just human, doesn't quietly break everything.
For a long time I thought of it as the compromised version of how a "real" developer works. I don't anymore. It's just good design. The system that fails loudly, explains itself, checks its own state, and doesn't depend on a perfect operator is more reliable for everyone who touches it. Building for the constraint made the thing better in general.
There's a well-worn version of this idea: curb cuts were fought for by wheelchair users and now everyone with a stroller, a suitcase, or a bad knee uses them without thinking. Software is full of curb cuts waiting to be built. A clear error message is one. A config that validates before it runs is one. An environment that sets itself up is one.
The part I don't usually put in my bio
I'll be plain about this, because pretending otherwise doesn't help anyone reading it who's in the same place. I've been rejected by essentially every traditional developer route I've tried. And the one role I did land, I didn't lose because I couldn't do the work, I lost it because the environment couldn't bend even slightly to how I work. No adjustments, an inflexible structure, and a slow, predictable slide into burnout that had nothing to do with the code I was writing. For a long time I read that as a verdict on me. It isn't. It's a mismatch between real ability and a role built to accept only one shape of person.
And here's the thing I most want to land: asking for adjustments is not asking for charity. Nobody calls a good error message a favor. Adjustments are simply the conditions under which I can do the work at all. Predictable hours, a manageable load, an environment that doesn't run me into the ground — those aren't perks that make a comfortable job nicer. They're the difference between me producing something real and me producing nothing. Remove them and you don't get a diminished version of the work. You get no work, from someone who was entirely capable of doing it.
That's the same principle as everything above. Externalize the structure. Don't build a system — or a job — that only functions if the operator runs on willpower and never has a bad day.
Building sideways
Here's where I've landed, and I don't say it with bitterness. We all function differently. Until the job market becomes more humane about that, until "can you do the work" stops being quietly replaced by "can you do the work in exactly this shape, these hours, this room", a lot of us are going to have to build sideways. Make our own way in. Contribute through the routes that don't have a broken filter standing at the door. That's what open source has been for me. It's how a merged contribution to a tool used across the industry, or a tool released alongside a European Space Agency project, exists at all not because a hiring funnel let me through, but because the work itself was open to anyone willing to do it. Non-traditional isn't lesser. For a lot of us it's the only door that was never locked.
And there's an irony I can't get past. So much of this field was built by minds that work the way mine does, the deep, narrow focus; the pull toward systems and patterns; the need to understand a thing completely before trusting it. The traits being screened out at the top of the funnel now are, in a lot of cases, the same traits the industry was built on. We didn't wander into tech by accident. In a real sense the culture of it was ours first. Being filtered back out of it stings precisely because of that. I don't have a tidy fix for an entire hiring market. But I know what I can do: keep building in the open, keep making the systems I touch talk back, and keep writing this down — so the next person who's heard "no" more times than they can count knows the problem was never them.
What I'd actually leave you with
You don't need perfect code, and you don't need a perfect brain either. What helps — what actually holds up on a hard day — is a system that talks back:
- Make failures loud, early, and specific. Assume the person reading the error has zero context, because sometimes that person is you in six months, or you at 4pm with nothing left in the tank.
- Externalize state instead of trusting memory. If the setup has fourteen steps, that's fourteen chances to fall off. Automate them.
- Let AI reduce activation energy, but never let it be the safety net. Put the checks around it.
- Design for your worst day, not your best one. The version of you with full focus and energy doesn't need the help. Build for the other version.
None of that is charity for the neurodivergent. It's how I ship reliable software, and the fact that it also makes the work survivable for a brain like mine isn't a coincidence. It's the point. The safety net was an accessibility feature the whole time. I just didn't have the words for it until I stopped being embarrassed about needing one.
I'd really like to hear from you on this one. If you build differently because of ADHD, autism, chronic illness, or anything else about how your particular brain and body work, what's the adjustment or the habit that actually makes the work possible for you? And if you've had to build sideways into this industry rather than through the front door, I'd love to know what that looked like. Drop it in the comments. I read all of them, and I suspect a lot of us are quietly solving the same problems alone.
Top comments (1)
"What breaks me isn't difficulty. It's silence." I don't share your neurotype, but I've spent a year arriving at your engineering conclusions from a completely different road, and reading this felt like someone naming the thing out loud.
I'm a physical therapist who builds internal tools for a hospital with AI — no formal training. My most expensive bugs were never hard, they were quiet: a health check returning 200 while the database behind it was dead, a backup exiting 0 without writing a file. Same enemy you named. I ended up building the same defenses — loud specific errors, automated setup, tests that fail early — not out of discipline but out of the same need: my working memory can't hold the whole system either, so the system has to tell me the truth without being asked. You framed as accessibility what I'd been treating as personal weakness, and that reframe is a gift.
Your line about AI — "a drafting tool, not a source of truth, wrapped in validation layers" — is the exact conclusion I keep re-learning. I depend on AI to write the code, and the single hardest lesson was that its confidence is not evidence. The wrapper that validates its output is doing the real work; the model is just the first draft. "Wrapped in validation layers" should be printed on the box.
The deepest thing here is that none of your accommodations are special-casing. A system that explains itself is more reliable for everyone — you just can't afford to pretend otherwise, so you build it right. That's not a limitation. That's a forcing function most teams never get.