The double-empathy problem lands in your pull requests

There’s a moment every autistic software engineer knows. You open a pull request you spent three days on. The first review comment lands: “this doesn’t handle retry; backoff unbounded; rewrite with capped exponential backoff.” No greeting. No “nice work on the refactor.” No emoji. You stare at it and feel your chest tighten. What did I do wrong? Why is he angry at me? You draft a defensive reply, delete it, draft another, ask a teammate if this person has a problem with you. Two days of anxious cycling before you realize the comment was just — correct. The reviewer saw a bug and said so. That’s it.

Now reverse it. A neurotypical engineer opens a PR. The autistic reviewer writes: “Race condition in the connection pool. Two callers can acquire the same handle. Fix.” The neurotypical author reads hostility, arrogance, a power move. They complain to their manager that the reviewer “has an attitude.” The autistic reviewer is confused — they reported a defect in the shortest path between observation and fix. They don’t understand what attitude has to do with anything.

Both communicators failed to read the other. Both projected pathology onto the other. And the asymmetry — the part that matters operationally — is that the autistic reviewer will be the one asked to “work on communication skills.”

That asymmetry is the whole game.

The double-empathy problem, precisely

Damian Milton’s 2012 formulation is deceptively simple: mutual understanding between autistic and non-autistic people breaks down bidirectionally across the neurotype boundary. The breakdown is not an autistic deficit in empathy or social cognition. It is a mutual failure rooted in differing experiential worlds. Neurotypical people are, by the same logic, equally poor at reading autistic affect, autistic intent, autistic communicative structure. Both sides project meaning that isn’t there. Both fill gaps with their own defaults. The empirical picture has grown since 2012: Crompton and colleagues found that autistic people communicate efficiently with other autistic people, neurotypicals communicate efficiently with other neurotypicals, and cross-neurotype pairs perform worse — the friction lives at the boundary, not inside the autistic person. Fletcher-Watson and colleagues have extended this: the “theory of mind” deficit framing, where autistic people are presumed unable to model others’ minds, doesn’t hold up when you flip the test and ask neurotypicals to model autistic minds. They’re terrible at it. The deficit was never asymmetric. It was labeled asymmetric.

I want to be honest about evidence boundaries here. The double-empathy construct has growing empirical support as a description of what happens at cross-neurotype boundaries. The specific protocol interventions I’m about to propose — PR templates, async-first standups, tone-extraction norms — are my reasoning from the construct, not results from randomized controlled trials in software workplaces. Nobody has run that trial yet. I run these protocols because they follow logically from the construct and because I’ve watched them reduce friction in practice. That’s practitioner evidence, not experimental. I’ll take the construct as far as it goes and tell you where I’m extrapolating.

The pull request as empathy boundary

A pull request is a communicative artifact stripped of nearly every channel humans use to disambiguate intent. No prosody. No facial expression. No timing. What remains is text — and text is where neurotype defaults collide hardest.

Consider the terse autistic review: “this doesn’t handle retry; backoff unbounded; rewrite with capped exponential backoff.” To the autistic reviewer, this is high-bandwidth, low-noise communication. They’ve identified the defect, stated the consequence, and prescribed the fix in one sentence. Adding “great work overall!” or “I love what you did with the abstraction layer!” would dilute the signal. Terseness is bandwidth, not aggression. The information density is the courtesy.

To the neurotypical author, the same comment reads as curt, dismissive, possibly hostile. Where is the acknowledgment of effort? Where is the relationship-maintenance signal that says “we’re still on the same team”? The absence of warmth is filled in with its opposite: the neurotypical reader projects coldness, judgment, hierarchy. They’re not reading the comment. They’re reading the gap in the comment and pouring their own default into it.

Now the reverse. A neurotypical reviewer writes: “Hmm, this is really interesting! I wonder if we’ve thought about the retry behavior here? Maybe there’s an opportunity to look at the backoff strategy? 😊” To the neurotypical author, this is warm, collaborative, face-preserving. To the autistic engineer, it’s evasive and possibly manipulative. Is there a bug or isn’t there? Is the backoff wrong or are you just musing? Why are you smiling about a potential defect? Hedging is relationship-preservation, not concealment — but the autistic reader fills the missing directness with suspicion. They project dishonesty where the neurotypical projected hostility.

Both readers are wrong. Both are confident they’re right. Both blame the other. The PR thread becomes a conflict not about code but about what communication is.

The standup, or: how are you isn’t a question

“How are you?” is the canonical neurotypical protocol failure. It is a greeting that performs social bonding without requesting information. The neurotypical speaker expects a brief positive or neutral acknowledgment — “good, you?” — and then the conversation proceeds. The question is not a question. It is a ritual handshake.

The autistic engineer hears a question and answers it. “I slept poorly, I’m anxious about the migration, and my commute was disrupted.” This is treated as oversharing, social clumsiness, “not reading the room.” The team has built a protocol — the standup greeting — that is structurally hostile to literal communication, then penalizes the literal communicator for following the protocol’s surface instructions rather than its hidden social contract. The autistic person is “not a team player” because they answered the question the team asked.

This is a protocol design failure, not a social-skills failure. The standup asks a question it doesn’t want answered, then blames the person who answers it. The fix is never “teach the autistic person that ‘how are you’ means ‘hello.’” That’s teaching someone to fluent-decode a protocol designed to exclude them. The fix is to make the protocol say what it means. If you want a greeting, greet: “Morning everyone, let’s get started.” If you want a status check, ask for status. Stop hiding one inside the other and then grading people on their performance of the hidden layer.

Async isn’t automatically safer

There’s a common belief in engineering culture that async, text-based communication is inherently more autistic-friendly. I want to push on this. Async removes the real-time performance pressure of live interaction — no eye contact demands, no rapid turn-taking, no in-the-moment masking. That’s real. But async also strips every disambiguating channel except text, which means both neurotypes fill the missing-tone gap with their own defaults, and the defaults are incompatible. The neurotypical reads terse as hostile. The autistic reads hedged as evasive. Async doesn’t solve the double-empathy problem — it concentrates it into the artifact.

Async is safer not because text is neutral but because text is editable. You can design the artifact to carry the intent the missing channel would have. You can structure the PR template so terseness is disambiguated by required fields. You can write review norms so “don’t read into tone” is an explicit, shared instruction rather than an implicit expectation. The safety is in the protocol design, not the medium.

The assimilationist fix is the problem

Here’s what usually happens after the friction becomes visible: the autistic engineer gets pulled aside. Maybe it’s a formal “communication skills” workshop. Maybe it’s a well-meaning mentor who models how to soften feedback — “Have you considered…”, “I wonder if…”, “One thing we might explore…”. Maybe it’s just the ambient pressure of a performance review category called “collaboration” that quietly means “make neurotypical people comfortable.”

This is the assimilationist fix, and it’s exactly backwards.

The autistic burnout and masking literature — Raymaker and the AASPIRE team’s work most directly — documents the cumulative cost of sustained masking: the constant cognitive labor of monitoring your output for neurotypical palatability, suppressing your natural communication style, calibrating tone for an audience whose expectations you have to reverse-engineer in real time. This isn’t an inconvenience. It’s the mechanism that produces autistic burnout, a state of functional collapse that takes months to recover from and that knowledge workers routinely push through until they can’t. We have a longer treatment of this pattern — the masking labor that drives autistic burnout in knowledge work — but the operational point is simple: when your “accommodation” is “learn to sound like us,” you are prescribing the harm.

And the framing is insidious. The team calls it inclusion. HR calls it professional development. The autistic engineer calls it exhaustion. The bridging labor — the work of translating across the empathy gap — has been moved entirely onto one party, and the org has labeled that arrangement “fairness.” It’s the double-empathy problem’s resolution through unilateral assimilation. One side doesn’t change at all. The other side performs fluency in a communication register that isn’t theirs, every working day, until they leave or break.

I’m being direct about the mechanism because I’ve watched it happen, including in teams I’ve been responsible for before I understood what I was looking at. The engineer who writes the most technically precise review is the one who gets flagged for tone. The one who flags real risk early is the one who “isn’t collaborative.” The system is doing exactly what it’s designed to do. It’s just designed wrong.

The fix is protocol design

The alternative isn’t to coach the autistic employee. It’s to change the artifact so the human doesn’t have to perform the bridging labor.

Start with the PR template. Require structured fields: what this changes, why it’s needed, what the impact surface is. When the reasoning is structurally present in the artifact, terse comments stop reading as hostility because the intent was already declared upstream. You’ve disambiguated terseness without asking anyone to perform warmth.

Replace the live standup — a protocol that forces real-time interpersonal processing and punishes literal communication — with written async updates that have a template and a time boundary. The status is the status. Nobody has to decode “how are you” on the clock.

Score reviews against a checklist that evaluates the change, not the commenter’s tone. Make “don’t read into tone; evaluate the technical content” a team norm that’s stated, not assumed. Separate technical critique from interpersonal signal so thoroughly that the category error — hostile comment, evasive comment — becomes structurally harder to make.

What you’re doing is absorbing the empathy load into the protocol. The masking that currently offloads onto the autistic employee — the constant self-monitoring, the tone calibration, the “will this read as aggressive” pre-flight check before every comment — gets taken up by the artifact’s design. The PR template says what the change is. The review checklist says what counts. The written norm says don’t infer intent from style. The human writes the technical content, and the protocol carries the rest.

This is also why disclosure safety in software workplaces is a protocol question, not a courage question. Whether an autistic engineer can say “I’m autistic, I communicate literally, please take my comments at face value” without it becoming a career event depends on whether the team’s protocols already assume that literal communication is normal. Disclosure into a team that structurally punishes directness isn’t brave; it’s self-injury. The protocol has to be safe before the disclosure is safe.

I’ll be honest about the evidence: these protocol interventions are practitioner reasoning, not RCTs. I can’t cite you a controlled study showing that structured PR templates reduce autistic burnout. What I can tell you is that I’ve run these protocols and watched the “not a culture fit” flag stop appearing on the best reviewers’ files. That’s not data. It’s also not nothing.

The cost of not fixing it

The cost has two shapes, and most teams only track one.

The first: masking → autistic burnout → attrition. The engineer leaves. Exit interview says “looking for a better culture fit,” which is true in a way that conceals the actual problem. The org loses institutional knowledge and a senior technical reviewer and treats it as ordinary turnover. If you’re tracking autistic employees specifically — most orgs aren’t — the rate is quietly devastating.

The second is less visible and arguably more expensive: neurotypical-led teams systematically misread their best technical reviewers as interpersonal risks. The engineer who flags the architectural problem early, in plain language, before it’s expensive — that’s the one who gets the “difficult to work with” reputation. The team pays a capacity tax nobody measures. Risk that should have been surfaced sits unspoken because the person who would have said it plainly has learned that plain speech has a cost. The org doesn’t know what it’s losing because the loss is the absence of something that was never said.

Both costs are the double-empathy problem, operationalized. One party bears the bridging labor until they break. The other party misreads the signal and discounts the source. The gap produces real, measurable engineering harm, and nobody connects it back to the empathy boundary it came from.

Where the construct ends and the design begins

This isn’t “design around autistic people.” That framing misses the point.

When you build a PR template that carries intent structurally, it helps the neurotypical team too. The terse reviewer isn’t actually hostile — now the artifact says so. The hedged reviewer isn’t actually evasive — now the reasoning field says what they meant. The protocol does the bridging for both directions, and nobody has to hallucinate the other’s inner state from a two-line comment.

The double-empathy reframe’s operational lesson isn’t “accommodate autistic communication.” It’s stop locating the friction in one party. The friction is in the gap, and the gap is a design problem. Design the shared artifact so neither side has to fill it with a guess — because they will, and they’ll guess wrong, and the person who was right about the architecture will be the one who pays for it.