Disclosure in software workplaces, beyond the negativity bias · Neuro

If you ask a neurodivergent developer whether they should disclose at work, and they go looking for advice before answering you, the advice they will find is calibrated to the worst version of the story. The forums that shape these decisions run on negativity bias — not because the advice is wrong, but because of who posts, why they post, and what a platform rewards. Meanwhile, the largest study we have of neurodivergent software engineers says the median experience is markedly less grim than the ambient advice suggests. Both of these things are true at once, and holding them at once is the only way to make a decent decision. This piece is about the gap between the measured reality and the received wisdom, why the gap exists, and what it should change — for people deciding whether to say anything, and for the managers and tool-builders on the receiving end.

The surprising finding

Newman et al. (ASSETS 2025) ran a mixed-methods study of 493 software engineers, 299 of them neurodivergent — autism, ADHD, dyslexia, dyspraxia, and combinations thereof. It is the biggest look we have at how disclosure actually plays out in this industry, and the headline number is this: 85% of disclosures had positive or neutral outcomes. Positions did not evaporate. Teams did not freeze people out at scale. In most cases, people said the thing and were met with support, indifference, or quiet relief from someone who had been quietly doing the same mathematics themselves.

Only nine disclosures in the entire sample ended outright negatively. Nine is not zero — nine careers took real damage, and if you are playing the odds with your livelihood, “only nine” is a statistic; if you are one of the nine, it is the whole story. But the ratio matters more than the count. The negative outcome is the tail event, not the median. The advice market behaves as if the tail is the median. That inversion is the problem.

And then there is the finding I think matters most, the one almost nobody designs for: the biggest motivation to disclose was not accommodations. The dominant reasons were social — transparency, empathy, shared values, solidarity with other neurodivergent people. People disclose because they are tired of performing a second, invisible job alongside the visible one, and they want the people around them to stop misreading the signals they can’t help sending. “Understand me, don’t make me mask” outpolls “give me a formal adjustment” by a wide margin. The accommodation frame — the one HR departments, conference talks, and most neurodiversity-at-work programs are built around — is solving for the minor motivation.

The negativity-bias problem

Where does a developer go when they are weighing whether to tell their manager they have ADHD? Mostly to r/ADHD_Programmers and places like it — roughly 79k users, real war stories, real advice, a genuine community. And the corpus there skews violently negative. When Sasportes et al. coded how the community’s disclosure framing applied to real scenarios, they found 118 negative code applications against 35 positive or neutral ones. Read the forum in one sitting and you will come away convinced disclosure is how careers end.

That corpus is not lying. It is sampling. Three forces stack the deck, and each is well-documented in other domains:

Selection. People post when something went wrong. A disclosure that went fine is not a story; it is Tuesday. The same way you would never learn from a hotel review site what a normal uneventful night at the hotel is like, you cannot learn the base rate of disclosure outcomes from a venue where the act of posting is triggered by a problem. The 85% are largely silent because silence is what success sounds like.

Negativity bias proper. Bad outcomes are more memorable, more narratively load-bearing, and more emotionally urgent to warn others about — even for the people telling their own stories. A thread titled “I disclosed and then had a perfectly ordinary relationship with my manager” does not get written, and if it did, it would not get engagement. The forum’s content is therefore not even a representative sample of interesting stories; it is a representative sample of cautionary ones.

Platform dynamics. Upvote economies amplify whatever provokes a reaction, and warnings provoke reactions. “Don’t do it, here’s what happened to me” travels. “It was fine” sinks. Over years, the community’s collective memory compacts into advice calibrated to the worst decile. The people asking for advice do not know this is happening; they read the thread, they take the median of the visible posts, and they use that median to make an irreversible decision about their own career.

So the forum’s negativity is real, rational, and systematically biased. The study’s positivity is measured, messy, and systematic in the other direction. The actual decision-relevant quantity sits between them — and the study is the only one of the two that even attempts to measure a denominator.

What this changes for the person deciding

The asymmetry I want neurodivergent developers to internalize is not “it’s safer than you think.” It is “where and to whom you disclose matters far more than whether.” The study is blunt about this: disclosing to managers carries substantially more career risk than disclosing to coworkers. A coworker can misunderstand you; a manager can act on a misunderstanding in your performance review. The same sentence, the same diagnosis, the same workplace — the outcome distribution moves with the power asymmetry of the person hearing it.

That reframes the practical question. This is not a binary, once-ever event where you “come out” to the company and live with the result. It is a set of local, reversible judgments: you tend to disclose informally, to the people you actually work with, long before (or instead of) anything formal and recorded. Start with peers. Start on a small team. Start with the specific — “I read aloud terribly in live meetings, give me the doc beforehand” beats “I have dyslexia” as both an opener and a self-advocacy move. Test how the environment handles information about how you work before handing anyone information about how you’re diagnosed. The study’s 85% is the aggregate; your job is to find out which cell of the table you personally inhabit, cheaply, before you make the expensive version of the move.

And use the social motivation finding as a diagnostic. If what you actually want is for people to stop misreading you — to stop having to mask, to stop being read as rude or aloof or disorganized when you are none of those things — then the formal disclosure letter may not even be the instrument. The accommodation process is a legal mechanism for extracting adjustments. The social need is met by being known. Those are different problems with different tools, and conflating them is how people end up filing paperwork when what they needed was one honest conversation with a teammate.

What this changes for managers and builders

If you manage engineers, the finding to sit with is that the ask arriving at your desk is usually not “adjust my workload” or “restructure my interview.” It is “understand me, don’t make me mask.” Masking is real labor — we wrote about what it does to knowledge workers in autistic burnout and masking — and it is labor your team members are doing in addition to the job you’re measuring them on. The cheapest, highest-yield intervention available to you is making your team a place where someone does not have to do that second job. That costs you nothing budget-wise; it costs you the willingness to let people be legible on their own terms.

Concretely, the tools and processes that matter are the ones that reduce the extra labor of explaining neurodivergence. Written-first communication, where the spec exists before the meeting rather than after it. Asynchronous defaults, so that nobody has to disclose a processing-speed difference to explain why they go quiet in a standup. User-manual practices — “how I work” docs as a normal team artifact — where writing one is not a confession but a norm everyone participates in, neurotypical included. Every one of these is also just good engineering practice, which is the point: the accommodations frame makes this sound like special treatment, and it isn’t. It’s removing a tax. (The formal-accommodation side of this argument, for the record, holds up beautifully too — see the accommodation tax is a myth.)

The double-empathy extension, in code

There is a second thread in this research area that I think will matter more over the next five years than the disclosure question itself. Sasportes et al. hypothesize that the double empathy problem — the finding that neurotypical and autistic people misunderstand each other mutually and symmetrically, rather than autistic people simply having a deficit — extends from conversation into code and abstraction. Autistic engineers struggle with abstractions written by neurotypical engineers, not because the abstraction is hard, but because it encodes a theory of mind about what the reader will find obvious. And the reverse holds.

If that’s true — and anyone who has watched a senior engineer defend an interface as “intuitive” while a colleague reads it as an encrypted threat has seen the mechanism — then the consequences are architectural, not interpersonal. It means team composition is a bigger lever than individual accommodation. A mixed team doesn’t just distribute perspective; it changes which kinds of explanations, abstractions, and interfaces get built, and how much translation labor each engineer silently performs to use them. Pairing stops being a style preference and becomes an accessibility technology. We chase this thread all the way into code review in double empathy in your pull requests.

The disclosure question and the double-empathy question are the same question at different altitudes. Disclosure is whether you can tell your team how you read. Double empathy is whether your teammate’s code can be read by you. A workplace that works for neurodivergent engineers has to answer both, and the second one is answered in the codebase, not in HR.

What I’m taking into Mneurix

Two commitments fall out of this for what we build.

First, learning design for neurodivergent learners is not a feature; it is the default good design. Every pattern above — written-first, asynchronous, explicit-over-implicit, evidence over vibes — is how you’d design assessment and credentialing if you took the 85% finding and the social-motivation finding seriously. If you design for the person who needs clarity, async time, and explicit rubrics, you build something better for everyone; if you design for the imagined median learner, you build something marginal for everyone and hostile at the edges. The follow-up on the learning side is learning design for neurodivergent learners.

Second, the assessment should reduce masking, not reward it. An assessment system that penalizes you for reading slowly, that requires live performance over asynchronous demonstration, that grades the social packaging of the answer rather than the answer, is measuring the mask. That’s an assessment-validity bug, and it makes the credential that comes out the other end less informative for everyone. The credential should certify the skill, not the performance of not being neurodivergent.

The forums will keep telling the scary stories, because scary stories are what forums are for. The data says the majority of disclosures end fine and that what people mostly want is to be understood rather than accommodated. Build — and manage — for that. It is a smaller, stranger ask than the paperwork suggests, and it pays better.

Sources: Newman et al., ASSETS 2025 (n=493 software engineers, 299 neurodivergent); Sasportes et al. on r/ADHD_Programmers (79k users; 118 negative vs 35 positive/neutral code applications) and the double empathy hypothesis extended to code.