People have compared minds to machines for as long as we've had machines: clockwork, telephone switchboards, and then computers. It's an old comparison, and it isn't perfect. But it's very good at one thing: making something invisible easier to see. As an autistic software engineer with ADHD, I think it shows something important about masking, and about why its cost is so easy to miss.
This essay is also published on dev.to.
Every person runs their own build
Start with the simplest version. The body is the hardware. Our internal wiring (the way our brain processes, connects and responds) is the software.
The hardware is broadly similar from person to person. The software is not. Every human runs their own build, shaped by their own neurology, their own memories and their own history. That build is their internal landscape, and it's their reality.
This is where I want to use a word carefully: ego.
I don't mean arrogance or self-importance. I mean the ordinary fact of being a separate person. You have your own body, your own neurological wiring and your own memories, so you have your own perception of the world. Nobody else can stand exactly where you stand.
That isn't a flaw. It's how being human is supposed to work. Individuality is not a bug in the system. It is the system.
Software can't pretend
When we build software, we build it around requirements. It's meant to do certain things, under certain conditions, in a certain way.
And software can't pretend. If a function doesn't handle an input, writing "handles all inputs" in the documentation doesn't change that. If a service falls over under load, a green badge on the README doesn't stop it falling over. What the system does is what the system does, whatever anyone says about it.
The same is true for people. Pretending your wiring is something it isn't doesn't change the wiring. It only changes what other people can see.
There's no spec sheet for a person
Here's where software and people really differ.
With software, we can look inside. We have source code, documentation, logs, tests and metrics. When something behaves unexpectedly, we can trace why.
With a person, we have almost none of that. Nobody can open up someone's neural pathways and read them like a blueprint. Neuroscience can say a lot about brains in general, but it can't produce an accurate, individual map of one person's internal wiring that anyone else could check.
So people fill the gap with assumptions. And the easiest assumption is to use yourself as the reference implementation: if I'd react that way, so would they. When someone behaves differently, it gets read as a defect instead of a different build.
That's often how bias forms: not from malice, but from missing information and an unspoken default.
The autistic researcher Damian Milton described a version of this as the double empathy problem (2012). When people with different ways of experiencing the world misunderstand each other, the gap runs in both directions. It isn't one side's fault for being "wrong".
Masking is a swallowed exception
Masking means hiding your natural responses so you come across the way other people expect. Many autistic and ADHD people do it every day, often without fully choosing to.
In software terms, it looks like this:
def get_through_the_day(situation):
try:
return respond_naturally(situation)
except SensoryOverload:
return look_fine()
except SocialMismatch:
return look_fine()
except Exhaustion:
return look_fine()
Every call returns something that looks like success. From the outside, nothing went wrong. But the errors still happened. They were simply hidden, every single time.
That's what masking feels like from the inside. You try to do something, and your system throws an error. Too much noise, too much light, a conversation that doesn't fit how you process things. You keep going, and you act as if it didn't happen. Then it happens again. And again.
Anyone who has debugged a production system knows that swallowed errors rarely come alone. Something wasn't cleaned up. A resource wasn't released. The leak grows quietly, until the process runs out of memory and stops.
In a person, that stop is often called burnout.
The research matches this picture. In "Putting on My Best Normal" (Hull and colleagues, 2017), autistic adults described masking as exhausting and said it blurred their sense of who they were. A later study by the same group found that masking was associated with more anxiety and depression (Hull and colleagues, 2021), and the authors called it a risk factor for mental health problems.
In a study that set out to define autistic burnout (Raymaker and colleagues, 2020), autistic adults described chronic exhaustion, loss of skills and serious effects on their health and quality of life. They also named doing things in an autistic way, including unmasking, among the things that helped them recover.
If it were a machine, we'd see the damage
Imagine a server that swallowed thousands of errors a day while reporting that everything was fine. Even then, we'd have ways to notice. Memory would creep up on a dashboard. Response times would drift. Eventually an alert would fire.
A physical machine forced to run against its design shows its wear too. It gets hot. It makes noises. Parts wear out, and you can measure it.
A person has no dashboard. The only real signal is what they show and tell you. And masking switches that signal off. The very thing that causes the harm is also the thing that hides it.
That's the trap. Looking fine is easy to mistake for being fine. By the time the damage becomes visible from the outside, it has usually been building for a long time on the inside.
Where the comparison stops
Like every analogy, this one has limits, and the limits are worth naming.
In a computer, hardware and software are separate. You can wipe a disk and install something new. In a brain, the software is the hardware. The wiring is physical, built over a lifetime.
A brain does learn and change. But learning is not the same as becoming a different kind of brain. Masking doesn't rewrite the wiring. It adds a layer on top that has to run all the time.
If there's a closer software picture, it's a compatibility layer: running a program built for one system on another. It can work, but every operation costs extra, and the native system underneath never goes away. You can't patch your way into a different build. You can only spend more and more to look like one.
Design around the real system
When a system keeps throwing errors, good engineers don't respond by hiding them. They read them. They ask what the system actually needs, and they change the inputs, the environment or the design to fit.
People deserve at least that much care. That can look like:
- Letting the errors show. Making it safe for someone to say "this is too much" without it costing them.
- Believing the report. If someone tells you how their system works, that is the most accurate data you will get. There's no other source.
- Adjusting the environment. Quieter spaces, written instructions, more time, fewer surprises. Small changes often remove the error entirely.
- Looking at outcomes, not appearances. What someone delivers matters more than how "normal" they looked while delivering it.
I also want to be honest: not everyone can safely stop masking. For many people it is protection in places that don't feel safe. That isn't their failure, and the responsibility for changing it shouldn't sit with them alone.
My whole approach to software rests on one line: software should never fail a person in silence. I think the same is true of the world we build around people. Nobody should have to run in silent-failure mode just to be accepted.
A system that hides its errors doesn't become healthy. It just becomes harder to help. That's as true for a mind as it is for a machine.