Building a Hypervisor for AuDHD: Containerising My Dual-OS Mind

unexcitement — Mon, 28 Sep 2026 15:56:51 +0000

If you have ever stared at your IDE completely paralyzed screaming internally to write a single line of code but physically unable to move society probably told you that you lack discipline. As a software engineer recently diagnosed with AuDHD (Autism + ADHD), I realized this isn't a failure of willpower. It is a catastrophic hardware and software conflict.

I am currently organizing my research into a project titled "Debugging the human condition - Through the eyes of an AuDHD Software Engineer” by applying a systems theory lens to practically apply philosophy and psychology to learn to make the opposing forces work for you instead of pulling you a part leveraging my IT experience and specialisation in Software Engineering to use metaphors and systems diagrams comparing the metaphor to the real system.

Through that systems theory lens, the default state of AuDHD makes perfect mechanical sense: it is exactly like dual-booting two entirely different operating systems without a bootloader to manage the switch, or a hypervisor to allocate resources. Because these systems have completely conflicting resource management protocols, they fight for the exact same constrained bare-metal hardware.

However, as engineers, we do not simply accept failing architecture. We build the missing infrastructure. Here is how these two operating systems compete, and how I built a hypervisor to containerise the workloads.

The Two Competing Operating Systems
OS 1: The Autistic Monolith (State Management)
The autistic side of the brain is a monolithic architecture optimized for deep processing and pattern recognition. It requires a rigidly controlled environment to function without throwing errors.
Bottom-Up Compiling: A neurotypical brain relies on cached templates to quickly render a situation without heavy computation. The Autistic OS compiles everything from the source code, taking in every raw pixel of data and environmental variable to build the big picture.
Dependency on cron Jobs: Because this is computationally expensive, the system relies on strict routines and predictable states the human equivalent of cron jobs. It needs to know exactly what is executing and when to manage its power draw.

OS 2: The ADHD Event-Loop (Resource Allocation)
The ADHD side is an event-driven architecture. Because its baseline fuel (dopamine) is chronically under-provisioned, the system constantly seeks out high-stimulation inputs.
The Interest-Based Network: It prioritizes tasks by urgency, novelty, or genuine interest rather than logical importance.
Asynchronous Polling: It relies on asynchronous polling, constantly spinning up new threads ("sidequesting") to chase stimulation.
Aggressive Process Killing: It mercilessly kills long-running processes the exact moment the dopamine reward drops.

The System Hang (An Out-Of-Memory Error)
The climax of this systemic failure happens when OS 1 and OS 2 try to dictate the schedule simultaneously.

Imagine building a perfectly structured weekly routine to keep the Autistic side regulated. By Wednesday, the ADHD side finds the lack of novelty physically repulsive and hijacks the main thread to research a brand new, unrelated project. The routine breaks, the Autistic side panics at the unhandled exceptions, and the system hangs.

Your working memory acts as your system RAM. As the unhandled exceptions multiply, your mental RAM hits 100% utilization, and the biological Out-Of-Memory (OOM) Killer activates to save the hardware. The crushing exhaustion you feel is the cognitive equivalent of a CPU running at 100% just to resolve an internal conflict, leaving zero processing power for actual tasks.

Deploying the Hypervisor: Containerisation and Load Balancing
You cannot permanently run conflicting dependencies on bare-metal hardware without causing a server crash. To stop the system from thrashing, I had to build a cognitive hypervisor to isolate the environments.

Cognitive Containerisation (Docker for the Mind) When you attempt to write code, apply for jobs, and decompress all at the exact same desk using the same browser, your brain struggles to switch states because the environmental dependencies collide. I deployed digital "bind mounts" to isolate these workloads. This means using strictly separate browser profiles and user accounts for different goals (e.g., one profile strictly for job hunting, another entirely for business logic). By enforcing these rigid containers, the Autistic OS receives a hardware-level signal that the context has safely shifted, completely eliminating cognitive dependency conflicts.
The Strict Load Balancer (Serialised Execution) The brain is a single-core processor; human multitasking is actually just rapid context switching (concurrency), which incurs a massive RAM overhead.

Attempting to run the ADHD desire for novelty concurrently with the Autistic need for structure causes severe thread thrashing.
To fix this, I implemented a strict architectural load balancer. I no longer allow the system to spin up a new workload until the active container is cleanly shut down and its state is saved.
By executing tasks serially, the friction of deciding what to do next drops to zero.

The Patch
If your application crashes due to a memory leak, you do not call the server lazy. You profile the leak, isolate the failing subroutines, and write a patch.
You are not lazy, you are not undisciplined, and you are not worthless. You possess an incredibly powerful, highly specialized dual-OS architecture. Once you stop judging yourself for missing standard societal metrics and start actively building the hypervisors, containers, and load balancers your hardware requires, it will change your life for the better.

DEV Community: unexcitement

Building a Hypervisor for AuDHD: Containerising My Dual-OS Mind