Chapters

• How my brain works
• The concrete difficulties
• What I tested and what worked
• AI as support, not as crutch
• What is still hard

An honest warning before starting: I am not a neurodivergence specialist, I am a case. I come from Marketing and Design, learned code out of curiosity — a few CRUDs in PHP and Ruby — and I deeply recognize myself in ADHD-style functioning: fierce hyperfocus on one side, short working memory on the other. This text is my testimony, not a manual. What worked for me may not work for you, but it might save you a few years of trial and error.

How my brain works

On one side, hyperfocus. When something grabs me — a new language, an architecture problem, an experimental tool — I enter a tunnel where hours pass unnoticed. That is how I learned things completely outside my field, and how my most ambitious projects were born, including a programming language. Hyperfocus is a superpower with high interest rates: it delivers a lot, but charges in sleep, skipped meals, and everything else in life left on hold.

On the other side, working memory. I lose the thread in the middle of long tasks. I forget why I opened that tab. I start five things and finish one — if I finish it. Seven-step instructions become three in my head, and never the same three. That is not lack of interest or intelligence; it is as if my internal whiteboard were too small and someone erased one corner at every distraction.

Understanding these two sides changed everything. Instead of fighting the brain I have, I started designing my life — and my software — around it.

The concrete difficulties

In programming, difficulties show up in very specific places:

Starting boring tasks. Environment setup, build bureaucracy, tedious migration. My brain sniffs low stimulation and simply does not start. I procrastinate not from laziness, but because ignition never happens.

Finishing the last 10%. The beginning is novelty and dopamine; the end is detail and review. Almost every project of mine has died at 90%. I learned to treat “finishing” as a separate phase with its own tactics — not as a natural continuation of the work.

Long documentation without structure. Walls of text knock me down. If a document has no clear headings, no summary on top, no concrete examples, my reading turns into anxious skimming. Ironic for someone who advocates readability — but that exact pain taught me to write and design differently.

Context switching. Each interruption costs me far more than the interrupted minutes: it costs the entire mental state, which I cannot save anywhere. Returning to a task is almost restarting it.

Decisions with too many options. Research is my strength and my trap. I compare five libraries, read the experimental ones, open twelve tabs — and stall in analysis. Curiosity becomes paralysis when there is no deadline or cutoff criterion.

What I tested and what worked

None of this is theory; it is what survived use:

Breaking everything into small modules. Large projects only move for me in slices that fit one hyperfocus session. Each module with clear responsibility, each task with visible beginning, middle and end. Not coincidentally, modularity became my architectural obsession — I design software the way my brain needs to consume information.

Externalizing memory. If it lives only in my head, it is already lost. Checklists, written context, decisions recorded with their reason — not the bare decision, the why. Prumo was born from that need: a protocol so projects carry their own context, readable by humans and agents. I built the tool I needed to keep building.

Starting with the interesting part, tying the boring part to it. I do not beat resistance to tedious tasks by force; I couple them to something stimulating. Configuring builds with music on, documenting while the code is still warm in my head, turning review into an almost playful checklist. It sounds like a silly trick, and it is — but a trick that works becomes method.

A cutoff criterion for research. Today I give myself an explicit limit: compare at most three options with criteria written before starting. Past that, I pick the best so far and leave the boundary open to revisit. A provisional, reversible decision beats a perfect, never-made one.

Low-noise environments. Clean interface, few tabs, notifications off. Every extra visual element is a candidate to hijack my attention. My projects inherited this: surface simplicity is not aesthetics, it is accessibility.

AI as support, not as crutch

AI became my central partner — but it is worth explaining exactly what it helps me with, because it is not “it codes and I sign.”

It holds context my working memory drops: summarizes where I stopped, lists what is missing, recovers the thread after an interruption. It gets boring beginnings moving: drafts the setup, structures the empty document, breaks blank-page inertia. And it investigates with me: compares alternatives, points out holes, suggests references I would never know.

What it does not do is decide for me. Trade-offs, product vision, the “no” to good ideas outside scope — that stays my job, and must stay. AI as executive-function support, not autopilot. That distinction matters, because outsourcing judgment would trade one difficulty for a dependency.

What is still hard

It would be dishonest to end this as an overcoming story. I still miss silly deadlines. I still have projects stalled at 90%. I still open twelve tabs. The difference is that today I have a system — flawed, but mine — instead of just guilt.

If you recognize yourself in this, the most useful advice I have is: stop trying to fix the brain and start designing around it. Tools, routines, software architecture, ways of documenting — everything can be designed for your real cognition, not an idealized one. That is how a Marketing person ended up creating a programming language, a 3D editor and a protocol for agents. Not despite the brain I have, but largely because of it — and the adaptations it forced me to invent.