I Can't Remember Details But I See the Whole System: ADHD and Architectural Abstraction

“Can you walk me through the data flow from user input to database?”

I stare at the architecture I designed. I know it works. I know it’s good. I cannot, at this moment, remember how any of it fits together.

This happens constantly. I build complex systems, understand them deeply during construction, and then forget the details within days. Not the concepts—I remember those. But the specifics? Gone.

For years, this felt like a devastating failure. How can you be a good architect if you can’t remember your own architecture?

Then I realized: the fact that I can’t remember the details is exactly why my architectures are good.

The Working Memory Problem

ADHD involves differences in working memory—the mental scratchpad that holds information during active processing.

Neurotypical working memory might hold 7±2 items. ADHD working memory? Often less. And the items held are more volatile, more likely to be overwritten by incoming stimuli.

In practice, this means:

• Complex instructions don’t stick
• Multi-step processes get jumbled
• Details fade faster than they should
• Returning to a task requires rebuilding context

This is genuinely a problem in many contexts. It’s hard to follow detailed instructions when you keep forgetting the middle steps.

But in architecture work, it creates an unexpected strength.

Forced Abstraction

When you can’t hold all the details, you can’t work at the detail level. You’re forced to work at a higher level of abstraction.

Here’s what happens when I try to understand a complex system:

Neurotypical approach (I imagine):

• Read through the code
• Hold the details in memory
• Build understanding from details up

My approach (necessity):

• Get overwhelmed by details immediately
• Fall back to finding the conceptual structure
• Understand at the abstraction level
• Only dive into details when absolutely necessary

I can’t hold “function A calls function B which modifies state C which triggers event D.” My brain just refuses to maintain that chain.

But I can hold “the input layer validates and transforms, the processing layer applies business logic, the output layer formats and delivers.” Abstract concepts stick. Concrete details evaporate.

This forced abstraction is frustrating when I need the details. But it’s powerful when designing systems, because good architecture IS abstraction.

Seeing Forests, Missing Trees

“You’re good at seeing the big picture” is something I’ve heard my whole life.

It sounds like a compliment. It’s partially a disability. I literally cannot focus on trees when there’s a forest. My brain defaults to pattern and structure rather than instance and detail.

In conversation, this means I often miss specifics while grasping implications. In system design, it means I naturally think about:

• What’s the shape of this problem?
• How do the components relate?
• What’s the essential complexity vs. accidental complexity?
• What abstraction would make this simpler?

I’m not choosing to think abstractly. I’m incapable of thinking concretely for extended periods. The abstraction is where my brain can actually operate.

Building for a Forgetful Creator

Here’s the key insight: I design systems assuming I’ll forget how they work.

Because I will. Definitely. Within weeks.

So my systems must be self-explanatory. They must have:

• Clear naming that reveals purpose
• Obvious structure that shows organization
• Minimal hidden state that requires remembering
• Documentation that makes re-learning fast

When I write systems like my quality gates, I’m not just writing for other people. I’m writing for future-me who won’t remember what present-me was thinking.

This constraint makes the systems better for everyone. If the creator can re-understand the system without remembering it, anyone else can understand it too.

External Memory Systems

My architecture work is inseparable from my external memory systems.

I cannot hold the current system state in my head. So I maintain external state:

• Architecture diagrams that show component relationships
• Design docs that explain decisions and tradeoffs
• ADRs (Architecture Decision Records) that capture why, not just what
• Living documentation that stays current as systems evolve

These aren’t optional supplements. They’re how I function. Without them, I’d forget my own decisions and remake them inconsistently.

The dev docs workflow I described for AI context management is the same pattern applied to human context management. We both have limited working memory. We both need external systems to compensate.

The Abstraction Ladder

One framework that helps: thinking in terms of abstraction levels.

Level 0: Concrete implementation details → I can visit, but can’t live here

Level 1: Component behavior and interfaces → I can operate here for moderate periods

Level 2: System structure and data flow → My natural home

Level 3: Architectural patterns and principles → Comfortable indefinitely

My brain naturally climbs this ladder. Given concrete details, I immediately start looking for patterns. Given patterns, I remember them for months.

This creates a specific architectural strength: I think in terms of patterns, interfaces, and structure. The implementation details get delegated—either to external memory (documentation) or to others who can hold more detail.

The Leaky Abstraction Problem

This approach has a significant weakness: abstractions leak.

When you design at the abstraction level, you can miss implementation details that violate your abstractions. The beautiful clean interface assumes the underlying implementation behaves a certain way—and sometimes it doesn’t.

I’ve been bitten by this repeatedly:

• Designed a clean async interface, forgot that one underlying service is actually synchronous
• Created elegant error handling abstractions that didn’t account for a weird edge case in the implementation
• Built caching strategies that broke because I forgot how the underlying data source handles cache invalidation

The solution isn’t to hold more details—I can’t. It’s to:

• Test abstractions against reality
• Document known limitations and edge cases
• Build validation that catches when abstraction and implementation diverge
• Rely on others to catch detail-level issues I miss

Abstraction as Interface Design

The best outcome of forced abstraction: I think about interfaces constantly.

When you can’t hold both sides of an interaction in your head, you need clean interfaces that let you think about one side at a time.

This translates directly to API design:

• What does this component need to know about its dependencies?
• What can be hidden behind an interface?
• What’s the minimal communication surface?

I’m not intellectually choosing good interface design. I need good interface design to function. Bad interfaces force me to hold more context than I can manage.

The Resumability Requirement

Every system I build must be resumable—I must be able to pick it up after forgetting how it works.

This constraint drives many design decisions:

• Stateless where possible: Reconstructing state is easier than remembering it
• Clear entry points: Where do I start when I come back?
• Self-documenting code: Names and structure that explain themselves
• Checkpoint-friendly design: Can I stop anywhere and resume?

In my post on parallel thinking, I described how ADHD makes context switching expensive. Resumability is how I minimize that cost—make re-entry easy because I know I’ll need to re-enter.

Designing for Humans Like Me

When I design systems, I’m designing for users who might think like me.

This means:

• Don’t require memorizing configuration sequences
• Provide clear feedback about system state
• Make operations idempotent where possible (re-running doesn’t break things)
• Offer multiple entry points for different mental models

Systems designed this way are often called “user-friendly.” Really, they’re “working-memory-friendly.” They don’t assume users can hold the whole system in their heads.

The best compliment I get on my architectures: “I could understand it without reading all the documentation.” That means the abstraction level is right—the structure itself communicates.

When Abstraction Fails

I should be honest about when this approach fails.

Performance optimization: Often requires holding detailed knowledge of implementation behavior. I struggle with this and need to work harder to rebuild understanding repeatedly.

Debugging complex interactions: When abstractions fail, you need to trace through concrete details. My ability to do this is time-limited before I lose the thread.

Detailed planning: Breaking complex work into detailed task lists requires holding the whole project in mind. I need external tools to compensate.

Remembering constraints: Historical constraints and edge cases often live only in tribal knowledge. I forget them and have to be reminded.

For each of these, my strategy is the same: externalize the memory. Document the optimization decisions. Write down the debugging trace. Create detailed task lists in external tools. Record constraints when I learn them.

I can’t expand my working memory. But I can expand my external memory infinitely.

The Architecture Test

Here’s how I test whether an architecture is good: Could I re-understand it after forgetting it?

If the answer is no—if understanding requires holding too much in working memory—the architecture probably isn’t clean enough. Not just for me, but for anyone who encounters it later.

Good architecture should be:

• Discoverable: You can find your way around without knowing everything
• Local: Understanding one part shouldn’t require understanding all parts
• Principled: Patterns repeat, so learning one area teaches you about others
• Documented: What isn’t obvious in structure is explicit in documentation

These criteria aren’t arbitrary. They’re what I need to work with my own systems. That they also make systems better for everyone is the silver lining.

The Abstraction Advantage

In system architecture, abstraction is the skill. The ability to:

• Find essential structure in complexity
• Create useful simplifications
• Design interfaces that hide irrelevant details
• Build mental models that survive without remembering everything

ADHD doesn’t automatically provide this skill. But it forces practice. Years of being unable to hold details creates strong abstraction muscles by necessity.

The architect who can’t remember details must become the architect who doesn’t need to.

---

This is part 4 of the ADHD Architect series:

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

---

I’ve already forgotten some of the specific examples I used earlier in this post. That’s fine—I know where to find them.

The system is designed for someone who forgets. By me, for me, and apparently for everyone else who appreciates clear abstractions and good documentation.

The working memory limitation that makes details hard to hold is the same limitation that makes me good at not requiring details to be held.

I can’t remember the trees. But I can see the whole forest at once. For architecture work, that’s often the better trade.