🧠 Why a computer science perspective?
Neurodivergence is often framed only in medical or social terms. But if you think like an engineer, you start to see something different: multiple valid architectures, each with its own performance profile, edge cases, and optimization strategies. Instead of asking “what’s wrong with this brain?”, we can ask “what workloads is this brain optimized for, and how do we design systems around that?”.
📚 From “disorder” to “design space”
In classical software engineering, you rarely call a different architecture “disordered”—you call it specialized. A GPU is not a broken CPU; it’s a device tuned for parallel workloads. Many autistic and otherwise neurodivergent people function like highly specialized compute nodes: exceptional at some tasks, overloaded by others.
🧬 Signals from research, mapped to systems
Research on thalamic gating, excitation/inhibition balance, and sensory processing can be read as low-level “kernel behavior”: how the system routes interrupts, prioritizes signals, and filters noise. Community spaces—parents, autistic adults, global disability networks—are like real-world telemetry showing how these kernels behave under production load.
This page doesn’t replace medical or social models; it overlays a systems model to generate new metaphors, design patterns, and practical “algorithms to live by”.
🎛 Three guiding metaphors
- Architecture: Different brains as different compute stacks (latency, throughput, caching).
- Protocol: Social interaction as API design—clear contracts reduce friction.
- Observability: Self-awareness and community feedback as logs, traces, and metrics.
🧮 Algorithms to live by (neurodivergent edition)
Computer science gives us a library of algorithms that can double as life strategies—especially for neurodivergent minds navigating noisy, underspecified environments. Think of these not as rules, but as reusable patterns you can tune to your own “runtime”.
Protecting your bandwidth
Many autistic and ADHD brains have limited “I/O bandwidth” for social interaction, sensory input, or context switching. In distributed systems, we use rate limiting to prevent overload and cascading failures.
In real life: pre-agree on “quiet hours”, use status indicators (Teams/Slack presence, phone focus modes), and normalize “I need to pause this conversation and come back later.”
Scripts, templates, and mental macros
When working memory is limited or easily flooded, precomputing is powerful. Engineers cache expensive computations; neurodivergent people can cache common phrases, routines, and checklists.
- Pre-written email templates for common situations (“need more time”, “clarify requirements”).
- Standard scripts for phone calls, appointments, or conflict de-escalation.
- Visual checklists for transitions: leaving the house, starting work, ending the day.
One-step-ahead planning for ADHD/AuDHD
Optimal long-term planning is hard when time-blindness and executive dysfunction are in play. A greedy algorithm—always choosing the next best small step—can be more realistic than a perfect plan.
Tools like Microsoft To Do, Planner, or Loop components can embody this: surface just a few “next best” tasks instead of a wall of obligations.
Designing for failure, not perfection
Distributed systems assume things will fail and build in retries, fallbacks, and graceful degradation. Neurodivergent life benefits from the same mindset: routines that survive bad days.
- “Minimum viable day” checklists: 3 non-negotiables when everything else collapses.
- Redundant reminders across devices (phone, PC, smart speaker) instead of a single point of failure.
- Backup communication channels: text if calls are hard, email if meetings are overwhelming.
🏗 Architectures, networks, and protocols
Research talks about thalamic gating, sensory processing, and connectivity; communities talk about overload, shutdown, and burnout. In systems language, we’re looking at routing, buffering, and protocol mismatch.
🌐 Different brains, different stacks
Imagine three broad “stacks” (oversimplified, but useful as metaphors):
- High-sensitivity stack: Incredible detail resolution, low noise tolerance, high interrupt cost.
- High-parallelism stack: Many threads open, context switching cheap, prioritization hard.
- Deep-focus stack: Hyperfocus throughput high, task switching expensive, startup latency large.
📡 Social interaction as API design
Many autistic people describe social life as undocumented APIs: hidden parameters, inconsistent responses, and breaking changes with no release notes. Good API design principles map surprisingly well:
- Explicit contracts: Say what you mean, state expectations, avoid “guess what I’m thinking.”
- Idempotent requests: It’s okay to ask the same question twice; the answer shouldn’t punish you.
- Clear error codes: “I’m upset because X” beats silent timeouts or vague disapproval.
Workplaces and families can adopt “human API guidelines” the way engineering teams adopt REST or gRPC conventions.
🧵 Threading & context switching
Many neurodivergent people pay a high cost for context switches. In OS terms, their “task switch” involves flushing large caches and reloading state. That’s not laziness; it’s expensive memory management.
🧩 Special interests as optimized workloads
What gets called “special interests” can be seen as highly optimized workloads: domains where the system achieves extraordinary throughput and low error rates. Instead of trying to throttle them, we can route more value through them.
- Let autistic employees own documentation, testing, or research in their interest domains.
- Use deep-focus strengths for long-horizon projects, not constant firefighting.
- In education, align curriculum with interests to reduce “context-switch tax.”
🔍 Debugging, observability, and safety
In complex systems, you don’t guess what’s wrong—you instrument, observe, and iterate. Neurodivergent lives deserve the same respect: less blame, more observability; less “try harder”, more “let’s inspect the system.”
📊 Logs, metrics, and traces for humans
Think of self-knowledge as observability:
- Logs: Journals, chat histories, and notes about what happened and how it felt.
- Metrics: Sleep hours, sensory load, number of meetings, time-on-task.
- Traces: “What led up to this meltdown/shutdown?”—a sequence of events, not a single moment.
🧯 Incident response, not moral failure
In SRE culture, an outage triggers an incident review, not a character assassination. The same mindset can apply to autistic burnout, shutdowns, or social conflicts.
- Run blameless postmortems: “What conditions made this outcome likely?”
- Identify systemic contributors: noise, ambiguity, unrealistic expectations, lack of recovery time.
- Implement small, testable changes: fewer interrupts, clearer instructions, sensory accommodations.
This aligns with neurodiversity-affirming practice: the problem is often the environment, not the person.
🛡 Safety as a first-class requirement
For many families and autistic people—especially those with high support needs—safety is not an abstract concern. In systems terms, it’s a non-negotiable SLO (Service Level Objective).
- Physical safety: predictable environments, secure housing, reliable caregivers.
- Psychological safety: no punishment for stimming, honest communication about needs.
- Data safety: privacy around diagnosis, control over who knows what and when.
🪟 Microsoft, tooling, and inclusive engineering
A tech-centered view isn’t just metaphorical. The Microsoft ecosystem—Windows, Office, Azure, GitHub, and accessibility tooling—can be treated as a neurodivergent support stack: a set of services that help different brains run their workloads more safely and sustainably.
📂 OneNote, Loop, and externalized working memory
Many neurodivergent people offload memory to survive. In systems terms, they’re extending RAM with fast, reliable external storage.
- Use OneNote as a “brain extension”: topic dashboards, checklists, scripts, and resource maps.
- Loop components for living documents: tasks, decisions, and notes that stay in sync across apps.
- Pin critical pages to Start or taskbar for one-click access during overload.
🧩 GitHub & version control for identity
Identity for many autistic people is iterative: late diagnosis, unmasking, changing language. Version control is a surprisingly apt metaphor.
- “Branches” of self: masked vs unmasked, work vs home, online vs offline.
- Commit messages: journaling what changed and why (“Started using ‘autistic’ instead of ‘has autism’”).
- Pull requests: inviting trusted people to review changes in boundaries, routines, or communication styles.
🧑💻 Copilot as a cognitive co-processor
Large language models can act like a co-processor for planning, wording, and sense-making—especially for neurodivergent users who struggle with initiation, summarization, or social phrasing.
- Drafting emails that match your intent but soften or clarify tone.
- Turning scattered notes into structured plans, checklists, or dashboards.
- Simulating perspectives (“How might a teacher read this?”, “How might a manager interpret this?”).
The goal is not to replace your voice, but to give you more ways to express it safely and clearly.
♿ Accessibility as core engineering, not add-on
Microsoft’s accessibility work—narrators, high-contrast modes, keyboard navigation, sensory-friendly settings—embodies a key neurodiversity principle: design for the edges, and everyone benefits.
- Quiet UI modes, focus sessions, and notification controls reduce sensory and cognitive load.
- Customizable input (speech, pen, keyboard, eye tracking) respects different motor and cognitive profiles.
- Enterprise policies can encode accommodations: flexible hours, remote work, written instructions.
🔭 Where this perspective fits in the bigger map
This “Neurodivergence Systems Lab” page is one tile in a larger mosaic: medical research, lived experience, global disability policy, VR social practice, parent communities, and skeptic debates. The computer science lens doesn’t override those; it gives engineers, technologists, and system-builders a language they can act on.