My Brain Runs 47 Background Threads: How ADHD Taught Me Distributed Systems

“How many browser tabs do you have open right now?”

My friend asked this during a video call, noticing my visible browser showing 73 tabs. She seemed concerned.

I laughed and explained: that was just one window. I had four more windows. And three different browsers.

She thought this was chaos. I thought: this is just how my brain works, externalized.

The ADHD mind doesn’t run one process at a time. It’s running dozens of concurrent threads, each holding partial state, ready to be swapped back into active memory whenever something triggers relevance.

This used to feel like a problem. Then I started designing distributed systems for a living. And realized my brain had been training me for this all along.

The 47 Background Threads

Here’s what’s actually happening in my head during any given moment of “focus”:

Active thread (foreground): The task I’m supposedly working on Background threads (sample):

• That email I need to send (holding: recipient, vague topic, no body)
• A half-formed idea for improving our deployment pipeline
• Wondering if I turned off the stove (periodically elevated to near-foreground)
• A code pattern I saw yesterday that might solve a different problem
• Mental note to look up that research paper someone mentioned
• Partial solution to bug I abandoned three days ago
• Song fragment on loop (consuming minimal resources but non-terminable)
• Remembering I need groceries (linked to: hunger, which is also running)

Each of these is a partial computation held in memory, waiting for either: relevant input that triggers continuation, or attentional resources becoming available.

Sound familiar? This is literally how concurrent systems work.

The Distributed Systems Analogy

When I first studied distributed systems architecture, I had an immediate reaction: “Wait, this is just how I think.”

Concurrent processes: Multiple independent threads of execution → My brain: Multiple thoughts running simultaneously

Context switching: Saving state, loading new state, resuming later → My brain: Constantly, involuntarily, all day long

Event-driven architecture: Responding to events as they arrive → My brain: Attention triggered by stimuli, not by plan

Eventually consistent: State propagates over time, may be temporarily inconsistent → My brain: Information updates gradually, not atomically

Message queues: Buffering work until it can be processed → My brain: Every notification, idea, and task waiting for attention

The analogy isn’t perfect. But it’s close enough that my experience with my own brain translated directly into intuition for systems design.

Context Switching Costs

Anyone with ADHD knows context switching is expensive. When you switch from one task to another, there’s a real cost: you lose the mental state you’d built up, and rebuilding it takes time.

This is true in distributed systems too. Context switching between processes has measurable overhead. Loading state from disk is slower than keeping it in memory. Network latency adds cost to distributed operations.

But here’s what ADHD taught me that many engineers miss: you can’t eliminate context switching, so you need to optimize for it.

My brain switches context whether I want it to or not. I can’t stay on one task for eight hours through willpower. So I’ve learned to:

• Keep task state externalized so reloading is fast
• Break work into atomic chunks that can be completed between context switches
• Build systems that assume interruption rather than requiring continuous focus

These same principles make distributed systems resilient:

• Checkpoint state frequently so recovery is fast
• Design for resumability at any point
• Assume failure and design for graceful recovery

Engineers who’ve never experienced involuntary context switching often design systems that require continuous operation. They’re surprised when things fail. I’m never surprised—I know from personal experience that everything gets interrupted.

Event-Driven by Default

ADHD brains don’t run on schedules. They run on events.

Trying to focus on a scheduled task? The brain says no. Responding to an urgent ping? Suddenly fully engaged. New, interesting problem appears? Hyperfocus activates without consent.

This used to feel like a failure of discipline. Now I recognize it as natural affinity for event-driven architecture.

In my bug bounty multi-platform post, I describe building systems that process events across multiple platforms simultaneously. The architecture felt intuitive because it mirrors how my brain naturally processes: multiple input streams, prioritization based on urgency and interest, responses triggered by events rather than scheduled polling.

Event-driven systems resonate with ADHD brains because they work the same way:

• Reactive, not proactive: Respond to what’s happening, not what’s planned
• Interrupt-driven: New inputs preempt current processing
• Priority queues: Some events demand immediate attention, others can wait
• Backpressure handling: Too many events requires throttling or shedding

When I design event-driven systems, I’m essentially designing for a brain like mine. Which means the systems handle human interaction patterns well—because humans are also event-driven, just less extremely than ADHD brains.

The Tab Problem is a State Management Problem

Back to those 200+ browser tabs.

Each tab represents a thread of thought I haven’t finished processing. An article I need to read. A tool I want to try. A reference I might need later. A half-completed purchase.

I can’t close them because closing means losing the state. And I can’t hold the state in my head because my working memory is limited. So the tabs stay open—external storage for mental state.

This is exactly what happens in distributed systems that need to maintain state across operations:

The naive solution: Keep everything in memory → Doesn’t scale, crashes when memory fills up

The better solution: Externalize state to durable storage → Browser tabs, notes, task managers, external memory systems

The optimal solution: Organized state management with retrieval systems → Bookmarks, notes with search, task systems with context

My browser tabs are a distributed state management problem. And like most state management problems, the solution isn’t “just remember everything”—it’s building systems that handle state properly.

This insight transfers directly to system design. When I see a system struggling with state management, I recognize the pattern: they’re trying to hold everything in memory instead of building proper externalized state systems.

Async All The Way Down

Synchronous processing requires waiting. Start task, wait for completion, start next task.

ADHD brains don’t wait well. When a task blocks, attention wanders to another task. By the time the first task unblocks, I might be three tasks deep in a different direction.

This is basically async programming.

// How neurotypical focus might work
const result1 = await doTask1();  // wait for completion
const result2 = await doTask2();  // then next task
const result3 = await doTask3();  // then next task

// How ADHD focus actually works
const promise1 = doTask1();  // start task
const promise2 = doTask2();  // start another (got distracted)
const promise3 = doTask3();  // start another (squirrel!)
// eventually resolve whichever finishes first

I’m not advocating for chaotic programming. But ADHD taught me to think in async by default. I naturally design systems where operations don’t block unnecessarily, where work can proceed in parallel, where the system doesn’t grind to a halt waiting for one slow operation.

When I build AI pipelines at work, they’re deeply async. Multiple agents processing in parallel. Events flowing through queues. Nothing blocking on nothing unless absolutely necessary. Because that’s how my brain naturally conceptualizes workflow.

Load Balancing Attention

Here’s something ADHD teaches that’s directly applicable to system design: not all tasks are equal, and the scheduling algorithm matters.

My brain has a terrible scheduling algorithm for routine tasks. Important but boring? Deprioritized indefinitely. Urgent but uninteresting? Somehow still deprioritized. Novel and engaging? Immediately promoted to highest priority regardless of actual importance.

This is a broken scheduler. But understanding why it’s broken taught me a lot about scheduling in general:

Priority inversion: High-priority tasks get starved because lower-priority but more engaging tasks hog resources → Same thing happens in systems without proper priority queues

Starvation: Some tasks never get processed because other tasks always jump the queue → ADHD brain starvation looks like never doing laundry, ever

Thundering herd: When stimulation is low, all tasks suddenly compete for attention simultaneously → Every task becomes urgent when you’ve been avoiding all of them

Backpressure: When queue fills up, new tasks get dropped or the system crashes → ADHD overwhelm and shutdown

Understanding these failure modes in my own brain helped me design systems that avoid them. Proper priority queues with fairness guarantees. Backpressure handling that degrades gracefully. Scheduling algorithms that prevent starvation.

My dysfunctional attention taught me what good attention management requires—lessons that transfer directly to resource management in distributed systems.

Consensus Is Hard (In Brains Too)

Distributed systems face the consensus problem: getting multiple nodes to agree on a single truth. This is fundamentally hard because messages can be delayed, nodes can fail, and there’s no global clock.

ADHD brains face a similar problem: getting multiple threads of thought to agree on what to do next.

My brain constantly has competing priorities. Part of me wants to continue the current task. Part wants to check email. Part is suggesting we should really look up that thing from earlier. Part is hungry. Part is generating new ideas.

Getting consensus among these competing processes is hard. Often, no consensus is reached, and I end up doing nothing while my brain argues with itself.

This taught me to value systems that handle consensus failure gracefully:

• Leader election: Sometimes one priority needs to win, not all need to agree
• Timeouts: If consensus isn’t reached quickly, pick something and move forward
• Split-brain handling: When parts of the system disagree, have a tiebreaker

In practice, this means building systems—both technical and personal—that don’t require perfect consensus to make progress.

The Queue That Never Empties

Every ADHD person knows the feeling: an infinite backlog of things to do, with new items arriving faster than old items are completed.

This is a queue problem. And like any queue problem, the solution isn’t “work faster”—it’s proper queue management:

• Capacity limits: Accept that the queue will never be empty; stop trying to empty it
• Pruning: Regularly remove items that are no longer relevant
• Priority processing: Process high-value items even if low-value items arrived first
• Overflow handling: When the queue is too full, stop accepting new items

My task management system isn’t about completing everything. It’s about keeping the queue at a manageable size while ensuring important items actually get processed.

The same principles apply to message queues, work queues, and event streams in distributed systems. You can’t process everything. You need a strategy for what not to process.

Living Distributed

After years of working with my ADHD brain, I’ve stopped trying to make it sequential. Instead, I’ve embraced the distributed nature:

Multiple contexts: I have different workspaces for different contexts, each with their own state. Like separate services with their own databases.

Event buses: Notifications, reminders, and triggers that fire when relevant, not on a schedule. My environment sends me events.

External state: Everything important is written down. My working memory is like RAM—fast but volatile. Persistent storage is external.

Graceful degradation: When overwhelmed, I shed load. Some things don’t get done. The system doesn’t crash.

Observability: I track what I’m doing, what I’ve done, what’s waiting. Like system metrics, but for my brain.

These aren’t just productivity hacks. They’re the same architectural patterns that make distributed systems robust.

Why This Matters for System Design

The point isn’t that ADHD is somehow better than neurotypical thinking. Different brain architectures have different strengths.

But ADHD brains come pre-loaded with intuitions about concurrency, event-driven processing, state management, and system failure. We’ve lived these concepts before learning their formal names.

When I design a distributed system, I’m not just applying theoretical knowledge. I’m applying lived experience of what it feels like when:

• Context switches are expensive
• Scheduling algorithms fail
• Queues overflow
• Consensus can’t be reached
• State is distributed and inconsistent

This intuition doesn’t replace formal knowledge. But it provides a visceral understanding that pure theory doesn’t capture.

---

This is part 2 of the ADHD Architect series:

1. Pattern Recognition
2. Parallel Processing (You are here)
3. Novelty Seeking
4. Abstraction
5. Chaos Management

---

My 200+ browser tabs aren’t chaos. They’re a distributed state management system built by a brain that thinks in parallel.

The same patterns that make ADHD challenging in a sequential world make it strangely well-suited for designing systems that aren’t sequential at all.

Maybe the problem was never the brain. Maybe it was the expectation that brains should work like single-threaded processes in the first place.