Being a dyslexic software engineer: 4 coding tasks and what works

The sprint starts. Someone drops 30 pages of API documentation into Jira and the team dives in. Everyone else is pulling out the key bits in minutes. You're on paragraph three, re-reading it, losing the thread, starting again.

The code? You can write it. You've always been able to write it. But everything around the code (the docs, the PR comments, the spec tickets, the Confluence page nobody has updated since 2023) is where the extra work goes.

This is what the research actually describes. In November 2025, Cruz, Verma and Liebel published the first qualitative study of dyslexic software engineers (arxiv.org/abs/2511.00706, Reykjavik University). They interviewed 10 dyslexic developers, analyzed 3 blogs, and coded 153 relevant Reddit posts. Across all sources, the finding is consistent: documentation is the main pressure point, not programming itself.

What the research shows

McChesney and Bond ran a series of eye-tracking studies on dyslexic programmers between 2019 and 2021. Their finding: dyslexic programmers do not show significantly lower code comprehension scores than non-dyslexic colleagues. Code reading appears to be structurally different from prose reading, because programming syntax is highly constrained, indented, and uses limited keywords. The visual structure of code does some of the parsing work that phonological processing normally handles in text.

Cruz et al.'s 2025 study confirms the same picture from a different angle. One participant described their experience directly: "I've always felt like my dyslexia or at least some of the ways it's shaped me were part of what suited me so well to programming." Another reported failing third grade, dropping out of school, attending a 4-month coding bootcamp, and working as a lead engineer three years later.

The study also found that existing IDE tools (autocomplete, linters, syntax highlighting, compilers) function as accidental but effective accommodations. These tools catch the specific errors (misspellings, wrong variable names, type mismatches) that dyslexia would otherwise let through. One participant noted: "In coding I misspell 'length()' about four times a day, and the compiler finds each time — so no real problem." (DYS090, Cruz et al. 2025)

If you've assumed dyslexia rules out a software career, the evidence points the other way. A more useful question: which parts create friction and what adjustments are available.

Task 1: Reading technical documentation

Documentation is the consistent top complaint. Cruz et al. quote one participant directly: "Oh no, I need to go through 30 pages of reading just to figure out what I need to do. I fear documentation the most." (I2) A Reddit contributor adds: "my main problem is that everything I need to learn is in documentation." (DYS023)

Reading speed under time pressure is the mechanism. A dyslexic developer who takes twice as long to absorb a technical spec is not less capable; they're carrying extra cognitive overhead on the input side of a task that most people assume is trivial.

The fixes that work are practical. Multiple participants in the Cruz et al. study reported using AI tools to cut documentation down to essentials: "I can take a paragraph, or whatever I'm trying to write, and I can run it through there. Ask it to highlight the bullet points." (I6) Text-to-speech software is a second option that several participants use for long technical documents; Microsoft's screen reader is specifically mentioned as improving productivity for one senior engineer.

Visual documentation formats help significantly, too. Several engineers described requesting or creating diagrams alongside text documentation: "I do try to illustrate a lot of things visually, even if it's organizational structures and processes." (I4, Cruz et al. 2025) Asking your team to produce architecture diagrams, flowcharts, and UML alongside written specs is a reasonable adjustment under the Equality Act 2010 and the ADA.

If reading documentation is consistently adding 20-30 minutes per ticket, that's an unquantified overhead across your entire career. Put a number on it with the masking cost calculator, then use that figure when making a case for Access to Work software or a team documentation convention.

Task 2: Reading other people's code

Writing your own code is one thing. Code review is a different challenge. Cruz et al. found this is one of the most commonly cited friction points for dyslexic engineers, separate from general reading speed.

Two participant quotes capture it precisely: "Understanding code that I haven't written I find very hard." (DYS100) And: "I find it much harder to make sense of someone else's code." (PROG038) The issue is that unfamiliar code lacks the semantic anchors your own code has. You wrote your variable names to be memorable. Someone else's code doesn't have that.

Syntax highlighting in IDEs helps significantly: "I use text editors that are syntax highlighted — it highlights certain keywords and that helps me to visually process the code." (I6, Cruz et al. 2025) The visual color-coding does part of the structural work that slow decoding makes hard.

A number of participants also described using diagrams to understand code before reading it: "I understand the code better when it is pictographically displayed." (PROG019) Working out an algorithm in pseudocode or drawing it as a flowchart before diving into the implementation is described as a core strategy. "A lot of the time words just can't describe what is happening well enough, so by making little 'code clouds,' it helps with the memory aspect of working these algorithms out." (DYS094)

For code review specifically: asking reviewers to add comments explaining intent (not just what the code does, but why) is a low-friction adjustment that benefits the whole team. Many teams already do this as good practice. Framing it as a personal adjustment request gives it more traction.

If code review takes you noticeably longer than your colleagues, that's worth raising as a formal adjustment. Pair programming is also worth considering; multiple participants and the Cruz et al. authors note it as a strategy that lets dyslexic engineers contribute strengths while getting support on the high-friction reading steps.

Task 3: Writing technical documentation and specs

Writing is the other side of the documentation problem. Commit messages, pull request descriptions, Confluence pages, Jira ticket details, architecture decision records: the written output of a software engineering job is substantial, and it's all prose, not code.

Cruz et al. found that multiple participants use Grammarly consistently: "I have Grammarly, which helps with writing in English." (I3) For technical writing specifically, an AI tool (ChatGPT or Copilot) that can take bullet points and produce a coherent spec paragraph removes a significant step. The participant who described using ChatGPT for documentation added: "AI tools really helped me as someone with dyslexia for the reading part. And most of the documentation." (I7)

One finding that surprised the Cruz et al. researchers: Slack-style communication tools help in an unexpected way. Short-form messaging platforms encourage brevity as a cultural norm. One engineer noted: "I like how Slack works, because if it is written, if it's in a conversational form and real time, it kind of encourages people to keep things short." (I8) For a dyslexic engineer, a culture of short written messages reduces the pressure of long-form technical prose on every interaction.

For longer documents, asking for a structured template to fill in (rather than writing from scratch) is a simple and defensible reasonable adjustment. Templates reduce the organizational overhead of writing, which for dyslexic employees often takes as much effort as the writing itself.

AI writing tools (ChatGPT Plus at $20/month or Microsoft Copilot at £22/month standalone) give the highest return for technical writing, based on what participants in the Cruz et al. study reported using daily. Both are claimable through Access to Work in the UK at no cost to your employer. The Access to Work calculator gives you a personalised breakdown of what you could claim.

Task 4: Variable naming, code structure, and language choice

This is the one that tends to surprise non-dyslexic engineers. Variable and function naming is a bigger deal for dyslexic developers than for most colleagues, and the research is specific about why.

Short, cryptic variable names and abbreviations are harder to recognize quickly. One participant put it directly: "I just make sure to make my variables and function names not too long and words that are not hard to remember to spell." (DYS085, Cruz et al. 2025) Another described a related approach: "Favour well thought out names and functions." (DYS098) Both are pointing at the same preference: descriptive names over compact ones.

Language choice matters more than most engineers discuss. Cruz et al. found a clear pattern of preference for statically-typed languages. TypeScript over JavaScript, Java or C# over Python. The reason is specific: statically-typed languages catch errors at compile time or as you type, in the IDE. You don't have to hold the type system in your head; the editor tells you immediately when something is wrong.

Python came up negatively in multiple accounts. One participant described it as "too forgiving" for dyslexic coders. (CS019, Cruz et al. 2025) Another noted: "Sometimes indentation is challenging for me, given that indentation is very important in Python. I occasionally get confused with it." (I3) The absence of explicit block delimiters (brackets) removes a visual anchor that helps with code structure scanning.

If you're working in a team that uses a dynamically-typed language, a reasonable adjustment request to configure the IDE with maximum linting and type-checking extensions is both cheap and effective. TypeScript adoption in JavaScript projects is increasingly common for this reason across the industry anyway.

If your team's codebase uses a language or conventions that create consistent friction for you, document the specific tasks where it shows up and raise it as an adjustment. Getting a linter configured or a type annotation policy adopted takes one engineering meeting; the cumulative benefit over months is substantial.

What dyslexic engineers are actually good at

The Cruz et al. study identifies two consistent strengths across its participants. Both are genuinely useful in software engineering roles.

Visual and systems thinking. Multiple participants described seeing code architecturally rather than linearly: "I think in patterns. Software is patterns. I see the big picture easily. Large software projects require you to understand the big picture." (DYS018) Another: "I think about software almost as like a tree... it is possible to think about code in 3 dimensions, visualizing it to identify issues in areas." (I6) This kind of architectural thinking tends to show up in system design, debugging, and spotting cascading failure points.

Divergent and creative problem-solving. Several participants noted an ability to approach problems from angles their colleagues didn't take: "I'm able to solve problems that others can't think about and think about more logical ways to solve software problems." (I6) The Cruz et al. paper notes this was more frequently reported in blog posts, which tend to be more positive in framing, so read it with some caution. But the pattern is present across the interviews as well.

A word on framing: the researchers explicitly caution against inflating these strengths beyond their evidence base. They're cognitive patterns that happen to be useful in a specific context. Worth knowing, worth mentioning when relevant, but not a substitute for getting the adjustments in place.

The practical takeaway: if you're in a role that's documentation-heavy and review-heavy with minimal system design or architecture work, that's the worst combination for a dyslexic engineer. Worth knowing when choosing roles or raising with a manager.

Disclosure and adjustments in tech roles

Software engineering roles are, on average, better positioned for dyslexia adjustments than most professions. The tools are software. They're cheap. Many are free. And the culture in many tech companies already defaults to async text communication, AI writing tools, and IDE customization, so individual adjustments sit naturally against a backdrop of tooling preferences.

Under the Equality Act 2010 (UK) and the ADA (US), your employer must make reasonable adjustments once they know about your dyslexia. Formal diagnosis is not required before you can raise the issue. What's required is that you describe the specific difficulties and ask for support. The reasonable adjustments builder turns your specific challenges into a conversation plan and a draft email in about 2 minutes.

For UK developers: Access to Work can fund assistive technology, text-to-speech software, and AI writing tools. The application is straightforward and the employer pays nothing for the software itself. Given that the tools likely to help you (ChatGPT Plus, Grammarly, text-to-speech, screen readers) cost between £100 and £400 per year, the Access to Work route is almost always worth pursuing. Use the Access to Work calculator to see what applies to your situation before you start an application.

For US developers: accommodations under the ADA are requested through an interactive process with your employer, typically via HR. The Job Accommodation Network at askjan.org has a specific section on learning disabilities and technology roles that covers the most common accommodation requests.

One decision that comes up repeatedly in tech: whether to disclose to HR or to your manager first. The legal picture matters here. In the UK, HR knowledge counts as employer knowledge under the Equality Act 2010, which means the adjustment duty is triggered from the moment HR knows. Going to your manager informally first is more common, but creates no formal paper trail and creates no legal obligation until something is written down. The full analysis is in Tell HR or your manager first? The post-diagnosis decision tree.

The math points toward disclosure in most tech roles. The tools are cheap, the culture is generally more accepting than many industries, and Access to Work or ADA accommodation removes cost as a reason for your employer to push back. Name the specific tasks, name the adjustments, put it in writing.