Forem: Andrew Chadwick

The Dyslexic Mind Loop: Why Over-Preparation is a Fast Track to Burnout

Andrew Chadwick — Mon, 20 Apr 2026 19:11:26 +0000

Picture this: You are sitting in a system architecture meeting. A senior engineer or a manager brings up a strange edge case. They look around the room, stumped, and admit, "I actually didn't know the system did that."
Without missing a beat, you chime in. You confidently explain the exact underlying logic, how the legacy C# controller interacts with a forgotten SQL constraint, and why it behaves that way. The room is impressed.

It feels like a massive win. It feels like a superpower.

But if you are a dyslexic developer, there is a dark side to this moment. That impressive display of system knowledge wasn't just casual expertise; it was the result of a grueling, exhausting psychological cycle.
Welcome to the Dyslexic Mind Loop.

The Anatomy of the Loop

The Dyslexic Mind Loop is a toxic feedback cycle fueled by a deeply ingrained sense of neuro-anxiety. It usually breaks down into four distinct phases:

1. The Insecurity Trigger

It always starts with a baseline feeling of: "I'm not naturally very good at this." Because dyslexic brains process linear information differently, reading documentation or following standard neurotypical workflows can feel like swimming against the current. To compensate, we convince ourselves that we must take extra care to survive. We believe we start at a deficit, so we have to work twice as hard just to break even.

2. The Granular Deep Dive (Over-Preparation)

Driven by that fear of falling behind, you start over-indexing on minor details. While others are reviewing the high-level happy path of a feature, you are diving into the abyss. You spend hours tracing the absolute lowest-level logic of a system, memorizing obscure configurations that seemingly have no immediate relevance to your actual ticket. It is an exhausting, brute-force method of learning.

3. The Accidental Flex (Validation)

Then, the random meeting happens. Someone asks a question about that exact obscure detail you burned the midnight oil studying. You answer it perfectly. Your boss or teammates are genuinely surprised. The dopamine hits. You proved your worth to the team.

4. The Toxic Reinforcement

Here is where the trap snaps shut. Your brain immediately registers that exhausting deep dive as a necessary survival tactic.

The internal monologue goes: "See? You were right to be anxious. You were right to spend three extra hours learning that random SQL constraint. It paid off. You have to keep doing this."

The Slow Push to Burnout

The problem with the Dyslexic Mind Loop is that it is fundamentally unsustainable.

You are weaponizing your own imposter syndrome to force yourself to learn. Because the loop occasionally rewards you with public validation, you trick yourself into believing it is a healthy working method. But you aren't just learning; you are hoarding data out of fear.

Every time the loop resets, the mental tax gets heavier. You start feeling the need to over-prepare for every meeting, every PR review, and every new feature. You slowly push yourself toward complete mental and physical burnout because your brain is convinced that relaxing your grip means you will instantly fail.

Breaking the Cycle

Breaking this loop doesn't mean lowering your standards; it means changing your reliance on raw memorization.

Recognize the Trigger: Catch yourself when you start going down a rabbit hole. Ask yourself: "Am I learning this because it is required for my task, or am I learning this because I'm afraid of looking stupid?"

Offload the Burden: You don't have to hold the entire 3D map of a system in your working memory. Leverage tools. Use a local AI agent to query system architecture. Write things down in a connected knowledge graph. Let the tools remember the obscure details so your brain doesn't have to.

Accept "I Don't Know": This is the hardest step. Practice saying, "I don't know off the top of my head, let me check the documentation or your notes." It feels terrifying at first, but you will quickly realize that neurotypical developers do this every single day without a second thought.

Your ability to see the big picture and map complex systems is a genuine asset. But you don't need to sacrifice your mental health on the altar of over preparation to prove you belong in the room.

Dyslexia + AI: The Ultimate power couple

Andrew Chadwick — Fri, 17 Apr 2026 16:04:26 +0000

Have you ever hesitated to ask a question in a PR review or a daily standup because you knew it sounded too "basic"?

For dyslexic engineers, this is a daily reality. We process information and ask questions in a very specific way that often doesn't make sense to neurotypical developers. We frequently find ourselves having to ask about low-level concepts things that are widely considered "common knowledge" or implied by the rest of the team.

To the outside world, it might look like we are struggling with the basics. But the reality is entirely different. We are building a mental 3D map of the entire system, and we cannot build it on assumptions.

The Load Bearing Pillars of the 3D Map

Dyslexic brains excel at spatial reasoning and seeing the big picture. When we look at a feature, we don't just see a linear script. We need to visualize exactly how a state change in the JavaScript frontend ripples through the C# backend controllers, and how that ultimately alters the SQL database constraints.

To construct that 3D visual map, we need to completely clarify every single foundational detail. If one detail is missing, the map collapses.

We ask those granular questions because those seemingly unrelated pieces of information are the load-bearing pillars of our mental models. We aren't asking because we don't understand the code; we are asking because we need to understand how the code affects the entire ecosystem.

The Problem with "Implied Knowledge"

The biggest friction point for dyslexic developers working in teams is "implied knowledge."

Traditional documentation and neurotypical communication skip steps. A tutorial or a senior developer might assume that Step A naturally leads to Step C. But a dyslexic brain absolutely requires Step B to connect the spatial logic. If we stop the meeting to ask about Step B, we risk social friction or looking inexperienced.

Enter AI: The Judgment-Free Sounding Board

This is exactly why the combination of Dyslexia and AI is so incredibly powerful.

AI doesn't judge. It doesn't sigh when you ask it to explain a foundational concept for the third time. With tools like local LLMs, we finally have a safe space to ask those hyper-specific, low-level questions. We can drill down into the absolute basics of a framework until that missing piece clicks and the 3D mental map is complete.

Even better, AI allows us to safely question and test our hypotheses before writing a single line of code.

Because we see systems spatially, we often conceptualize unconventional solutions. Before putting a theory to the test in our IDE, we can bounce the entire architectural flow off an AI agent. We can poke holes in the logic, test the edge cases, and validate our 3D map instantly.

A Cognitive Accessibility Tool

For a lot of the industry, AI is just a fast autocomplete or a boilerplate generator.

But for dyslexic developers, it is a profound cognitive accessibility tool. It translates the rigid, linear world of documentation into the spatial, interconnected format our brains natively use. It removes the exhausting barrier of "implied knowledge" and allows us to leverage our actual superpower: seeing how the whole system connects before it is even built.

Part 2: Marketing New Apps Sucks (But Preparation Saves You)

Andrew Chadwick — Wed, 01 Apr 2026 06:11:16 +0000

While I spend most of my time deep in C#, SQL, and JavaScript building my open-source local AI tool SheepCat (🐑🐈), I recently took on a side quest. I started building an app to support a friend's fitness business.

During the build, we identified a massive gap in the market: there is a desperate need for a local-first directory for Personal Trainers (PTs) that doesn't use the predatory "Bark model." We didn't want an app that charges PTs exorbitant fees just for the privilege of being introduced to a lead.

Our solution was beautifully simple: If you are part of the directory, you get a profile page. If a client wants to message you, they message you directly. No middleman holding leads hostage.

Building it was the fun part. Then came the marketing. And let’s be honest: marketing new apps sucks.

Navigating the New SEO: Welcome to GEO

To get eyes on this, I’ve been experimenting with GEO (Generative Engine Optimization). If you haven't dived into it yet, it is essentially the new SEO. It feels exactly like doing SEO back in the old days, but instead of optimizing for Google's traditional crawler, you are optimizing to be the definitive answer an AI search tool spits out when a user asks, "Who are the best PTs in my area?"

The "Done a Million Times" Objection

Armed with a shiny new app and a GEO strategy, I started promoting the tool in various Personal Trainer community groups.

It didn't take long for the grilling to start. One user immediately dropped the classic indie-hacker gut punch:
"Don't you think directories have been done a million times before?"

It is the kind of comment that instantly makes you want to get defensive and list out every single feature you spent weeks coding. But they were right. Directories have been done a million times. Most things with a clear purpose have been tried before.

Instead of arguing, I leaned into it. I replied: "You're absolutely right, they have. But we are trying to solve a new problem. We are aiming to solve the future problems where AI is shifting the search focus, and traditional directories aren't built for that."

The Trump Card: The Foundation Member Pitch

That shifted the tone, but then came the ultimate buying objection:
"Okay, but why would we buy into something brand new that doesn't have traffic yet?"
And they were right again. Why would they?
Fortunately, this is where taking a step back from the code to think about user psychology paid off. I had anticipated this exact hesitation weeks ago.

I pitched them our Foundation Members Program:
The first 200 people to sign up get a locked-in price for life.
To sweeten the deal, we guarantee absolutely zero ads on their profile page, forever.

I wasn't just selling a directory; I was selling early-adopter real estate.
That single, pre-planned offer completely flipped the script. The user's opinion turned around on a dime, ending with: "Fair game. Send me a link."

The Takeaway for Indie Devs

Trying to promote a new app is exhausting. It is entirely different from the dopamine hit of a passing test suite. You will get grilled on your product, and people will be skeptical of your new domain name.

But with a little bit of planning, and the forethought to anticipate exactly why a user would hesitate to interact with your system, you can build a solid foundation. When the hard questions come, you won't be shaken—you'll just drop the link.

Check out our fitness project here : Worlds Highstreet

Fixing the Messy Reality of Dev Time Tracking (SheepCat v1.4 Release)

Andrew Chadwick — Mon, 30 Mar 2026 05:56:57 +0000

If there is one thing that universally ruins a developer's flow state, it’s trying to accurately log time.

When you spend your day jumping frantically between a C# backend, complex SQL migrations, and a JavaScript frontend, your "schedule" is rarely linear. You get interrupted, you context-switch, and by 5:00 PM, trying to piece together exactly how long a specific task took is a guessing game.

I originally built SheepCat as a local-first, zero-cloud AI scratchpad to handle this context-switching for me. You drop messy notes in, and the local AI formats them. But as the community started using it, two massive workflow bottlenecks became obvious: timing accuracy and historical summaries.
Today, with the release of SheepCat v01.04.00, we are fixing both.

⏱️ The Timing Fix: Chain-Based & Fixed Durations

Previously, tracking the exact duration of an interrupted task was clunky. If you went down a rabbit hole debugging an auth loop, the timing could easily get skewed.

In v1.4, we’ve introduced chain-based task timing and special tasks with fixed durations.
What does this mean for your workflow? It means SheepCat now understands the fluid nature of dev work. Instead of rigid start/stop timers that you inevitably forget to click, the system better handles chained events and allows you to set fixed durations for specific, repetitive tasks (like that 15 minute daily standup). It reduces the cognitive load of micro managing the clock, keeping the focus entirely on the code.

⏪ The Time Machine: Rerunning Historical Summaries

Because SheepCat uses your local LLM (via Ollama) to generate your end-of-day project updates, we ran into a practical reality of working with AI: sometimes, you just want a do-over.

Maybe you dropped a crucial ticket number into yesterday's log after the daily summary ran. Or maybe you tweaked your local Ollama model prompt and want to see how it formats last week's messy notes.

In this release, we added the Summary History page.
You can now navigate back to any day in your history and trigger a completely fresh rerun of your full-day summary. No data is locked in. If you missed a task yesterday, just add it today, go to the history page, and let the local AI regenerate a perfectly clean update for your PMs.
Protecting the Flow State
The entire philosophy behind SheepCat is cognitive ergonomics. Your tracking tools should never be a source of stress. They should sit quietly in the background, keeping your proprietary code completely offline, and doing the administrative heavy lifting for you.

If you are tired of cloud-based tracking tools breaking your focus (or leaking your data), you can check out the new v1.4 release on GitHub here:
👉 SheepCat-TrackingMyWork Release v01.04.00
Would love to hear how the local AI summaries are working for your stacks!

It’s Better to Be Lucky Than Right: Why Your Code Needs the "Seemingly Pointless" Catch-Alls

Andrew Chadwick — Fri, 27 Mar 2026 09:43:16 +0000

In all my time as a software engineer jumping between C# backends, SQL databases, and JavaScript frontends I’ve learned one undeniable truth: no matter how many edge cases you plan for, a user will inevitably do something that absolutely blows your mind.

You can design the most airtight architecture, and yet, sometimes the only thing that saves your system is a well-placed catch-all or an extra null check.

You know the one. It's the exact check that a coworker flags in the PR review, asking: "What's the point of this? The data should never be null here. I'll still approve the PR, but this really isn't needed."

And then, a week later, it ends up being the single line of code that stops a massive crash because a user somehow managed to completely bypass Step 3 of a form, and half the expected model data was missing.

The Edna Mode Principle

As Edna Mode rightly says: "Luck favors the prepared, darling."

You should always try to consider all the absurd angles from which someone might break your application. Users are incredibly creative at doing exactly what you didn't anticipate. They will:
Poke directly at your API endpoints instead of using the UI you spent weeks building.

Paste an entire 50-character address into a PlaceName field, causing the database to silently truncate it and lose the actual location info.

Find a way to submit a payload that defies the laws of your frontend validation.

AI Assumes the "Happy Path"
This preparation is especially critical right now with how heavily we are integrating AI into our workflows.

Whether you are using Copilot, a local Ollama model, or another assistant, AI is fantastic at giving you exactly what you asked for. It will write the "happy path" beautifully. However, it very rarely considers the chaotic, human edge cases.

AI assumes the user will follow the rules. As engineers, we know they never do. If you are relying on AI to write your data handling or API logic, you have to be the one preparing for the unpredictable scenarios the model overlooked.

Trust Your Intuition

There are a million ways a system can break. As much as we all want to be perfectly "right" in our code and logic, you simply can't be right 100% of the time.

Sometimes, your engineering intuition just has to kick in. When you feel the urge to drop in that extra validation step, that redundant fallback, or that seemingly pointless catch-all just do it.

It might seem entirely unnecessary right now, but it could be the exact thing that saves your system on a Friday afternoon.

Is It Still Engineering If AI Writes the Code?

Andrew Chadwick — Tue, 24 Mar 2026 08:43:20 +0000

It seems like everyone is using AI to generate code these days. Which begs the question: if an LLM is typing out the syntax, are we actually engineering anymore?

Like any tool in this era or any era before it the answer depends entirely on how you use it. I’ve written before about AI being like a sword; in the hands of a skilled master, it’s an incredibly powerful weapon. But a sword doesn't win a battle on its own. Today, I want to talk about the skill of the engineer wielding it.

The "Screenshot to App" Trap

We have all seen the viral demos. Someone shows an AI an image of a UI, writes a basic prompt, and the AI spits out a functioning workflow. It looks like magic.
But look under the hood of those generated apps. You almost always get a massive, single-file monolith with zero security, tightly coupled logic, and a fundamentally fragile flow.

What happens when you want to extend that app? You ask the AI to move a feature or reuse a component. To accommodate, the AI writes more code on top of the pile, inevitably breaking a dependency you established 15 prompts ago. Suddenly, the app is a spaghetti mess, and the AI gets stuck in an endless apology loop "You are correct, here is the updated code" progressively breaking three other things to fix one.

It is not really the AI’s fault. It is just providing the most probabilistic solution to a surface-level prompt.

The Engineer’s Mindset: Systems over Syntax

An engineer approaches the exact same tool completely differently. We don't just ask for "an app." We define the problem, break down the required steps, and figure out how different technologies need to gel together to make the system resilient.

When an engineer uses AI, the prompt isn't a wish list; it is an architectural blueprint. It looks more like this:
Structural Boundaries: "I want this app to consist of a main body, but split the three core workflows into discrete, decoupled services."
Enforced Standards: "Every method call requires unit testing. Please add this rule to your project memory/instructions file so you don't forget it on the next prompt."
Data Architecture: "Store the data using this specific repository pattern, and separate the data layer into its own isolated project."

The Power of Pushback

The real engineering happens when the AI gets it wrong.
Because an engineer understands the underlying mechanics whether they are structuring a complex backend or designing a relational database they know when to challenge the output. If the AI returns a probabilistic guess that violates the core project philosophy or introduces a massive bottleneck, the engineer catches it, rejects it, and forces a course correction.

The Verdict

Typing syntax was never the hardest part of our jobs. Problem-solving is.

AI does not replace engineering; it simply shifts the focus from writing boilerplate to pure system design and architecture. As long as the core fundamentals of building scalable, maintainable software are not forgotten, AI is just the newest tool in the engineer's belt to build better systems faster.

I Got Tired of Jira Breaking My Flow State, So I Built a Local App to Bypass It (SheepCat v1.3)

Andrew Chadwick — Mon, 23 Mar 2026 16:09:04 +0000

We have all been there. You are deep in the zone, holding a complex mental model of a C# backend or untangling a massive SQL query. Then, the inevitable message drops: "Hey, can we get a quick status update on ticket LM-62401?"

To answer, you have to switch to your browser, wait for the heavy Jira or Azure DevOps UI to load, navigate the endless boards, find the ticket, and type out what you did. By the time you get back to your IDE, your working memory has completely crashed. The context is gone.

That cognitive tax the constant friction of administrative context-switching is brutal.
So, I decided to engineer a workaround.

## Enter SheepCat 🐑🐈‍⬛

SheepCat is an open-source, locally run desktop app I built to track my daily work without leaving my flow state. The premise is simple: log what you do, as you do it, in a lightweight, frictionless local interface.

But with the release of v01.03.00, it just got a massive upgrade that completely eliminates the "PM Interruption."
The New Release: Direct API Pushes to Jira & Azure DevOps
Up until now, SheepCat was great for keeping a local ledger of my day. But I still had to manually copy-paste that data into the corporate trackers eventually.

With v1.3, I’ve implemented an External API Service Factory. Now, SheepCat talks directly to your project management tools.

## Here is how the new workflow looks:

Stay Local: Log your micro-updates, debugging steps, and code changes directly into SheepCat throughout the day.

Batch Select: At the end of the day (or when you are at a natural stopping point), open the new scrollable "Send Updates" dialog.

Push to Production: Multi-select the entries you want to share, and SheepCat fires them directly to Jira or Azure DevOps via API.

No opening browsers. No hunting for tickets in heavy UIs. You just push the update from your desktop and get right back to the code.

## The Philosophy: Systemic Adaptation

I originally started building tools like SheepCat because, as a neurodivergent developer, the standard corporate workflow (high context-switching, rigid administrative tracking) drains my mental battery incredibly fast.

But what I've found is that reducing cognitive load benefits everyone. Whether you have ADHD, dyslexia, or you are a neurotypical senior dev who just wants to stay focused on the architecture, engineering your environment to remove friction is a superpower.

(If you are interested in this kind of workflow hacking, we recently started a community to share these exact types of "janky" survival tools over at r/LobACob!)

Give it a Try (and Break My Code)
SheepCat is fully open-source. If you are tired of the Jira UI tax, grab the latest v01.03.00 release and try the direct integration.
Get the v1.3 Release on GitHub
If you end up using it, drop a star on the repo! And if you want to add integrations for other tools (Linear, Trello, Asana), PRs are incredibly welcome.

The Self-Taught Engineer vs. The CS Graduate: Why Teams Need Both

Andrew Chadwick — Mon, 23 Mar 2026 07:07:30 +0000

The debate between taking the traditional Computer Science university route versus the self-taught path is as old as the tech industry itself. Having spent years in the trenches building C# backends, writing complex SQL queries, and untangling JavaScript I've worked alongside brilliant engineers from both backgrounds.

What I’ve noticed is that while both routes produce incredible talent, the journey shapes how these engineers tackle problems, especially early in their careers. Here is a look at how the self-taught engineer and the university graduate compare, from day one to the senior level.

The Starting Line: Vocabulary vs. Hands-On Practice

In the beginning, the playing field isn't exactly level.
University graduates usually enter the market with a higher starting salary. Why? Because the university system does a great job of teaching the "correct" terminology and prepping students for the job hunt (alongside the theory). They know the exact architectural terms for the HR screen and have had professors pointing them toward the most proven ways to land a role.
Self-taught engineers, on the other hand, often start at a lower pay grade. They might have built multiple full-stack applications from scratch, but they might initially stumble in an interview when asked to define polymorphism or diagram memory allocation. They have the raw building skills, but they often lack the formal vocabulary to sell themselves effectively right out of the gate.

The Real World: When Production Breaks

The differences become glaringly obvious the first time a system breaks in a weird, undocumented way.

When things go wrong, the educated engineer often falls into one of two camps. The first type freezes up: "Well, that's not how it is in the textbook." The second type has a lightbulb moment: "Oh, I see. The real tech world is messy, and we must adapt." Universities teach the ideal state of software, but production environments are rarely ideal.
This is where the self-taught engineer usually shines. To gain practice, a self-taught developer has likely broken their own environments a hundred times. They’ve spent nights piecing together a solution, deploying it, breaking it, and fixing it again. When a production bug pops up, they’ve probably seen the issue three times already and have a gut feeling about exactly where to look.

Reaching Senior Level: The Convergence

Once both engineers hit the senior level, the early gaps close, but their unique strengths remain highly visible.

The CS Graduate brings an invaluable depth of foundational knowledge. They are the ones who intuitively understand the how and the why beneath the framework. When the team needs to optimize a heavily trafficked service to run in O(1) time complexity, or design a system architecture using the most robust design patterns, their academic background pays massive dividends.

The Self-Taught Engineer, however, brings an insatiable, enduring drive. Because their entire career was built on self-directed learning, they rarely lose that builder's mindset. They are usually the ones eagerly picking up new technologies, prototyping the latest frameworks, and pushing the team to modernize, because continuous, unprompted learning is quite literally how they survived and thrived.

The Verdict

Neither of these routes is bad. At the end of the day, success in software engineering comes down to determination and the drive to keep learning. The CS graduate brings the structure, the deep theory, and the optimization skills. The self-taught engineer brings the adaptability, the hands-on troubleshooting, and an unmatched drive to explore new tech.

If you want a truly resilient engineering team, you don't choose between the two. You hire both but understanding the journey will give your team the edge.

Surviving a Neurotypical Industry: What "Janky" Workarounds Get You Through the Day?

Andrew Chadwick — Fri, 20 Mar 2026 18:32:16 +0000

There is a running expectation in software engineering that everyone processes work exactly the same way. You are expected to read walls of linear documentation, jump seamlessly through rapid context-switching, and track everything chronologically in Jira.

But if you have a neurodivergent brain, that standard corporate workflow often feels like it was actively designed to work against you. We spend an astronomical "cognitive tax" every day just trying to operate in a business world set up for a completely different neurotype.

Whether you are untangling a massive C# architecture, writing complex SQL joins, or wrestling with JavaScript dependencies, the friction is real. For a long time, many of us focused on trying to "fix" our brains—trying to focus harder, read faster, or cope better.

But we are engineers. When a system is broken, we fix it or build better systems.

The Graveyard of Polished Products

To survive, we don't wait for permission. We build scripts to manage executive dysfunction. We create recursive, nested, color-coded Excel sheets to handle linear text. We hack together local AI prompts to translate dense documentation into plain English that our brains can actually parse.

These tools are usually chaotic. They are the definition of "janky" code. They have zero UI, they would fail a code review, and the world never sees them.

But they are the exact reason we can function and thrive in our roles.

Enter r/LobACob: A Workshop for Systemic Adaptation

It is time to stop hiding the messy hacks. We just launched r/LobACob a brand-new professional community for neurodivergent technical minds (developers, engineers, architects, PMs, and managers) and our neurotypical allies.
"Lob a Cob" is our metaphor for cognitive engineering. It’s about taking the chaotic, unstructured information thrown at us every day the "cobs"(or a roll if your from London) and building it into a functional, personalized system.

We are not here to cope. We are here to re-engineer our environments.

Who Should Join?

The ND Professional: This is your safe workshop. We want to see your real, raw survival tools. Code quality does not matter here; functional wins do. Share your messy scripts, your architectural mental models, and your strategies for stopping the "PM Interruption" from clearing your mental RAM.

The Neurotypical Ally & Manager: You are incredibly welcome here! Neurodivergent folks are forced to be masters of aggressive efficiency to reduce cognitive load. Hang around, and you will absolutely find systemic productivity hacks and workflow workarounds worth stealing for yourself. Good systems benefit everyone.

What is Your Workaround?

Tech’s standard operating system isn't working for everyone, but we know how to push fixes.
Over at r/LobACob, we have stickied a thread dedicated to these janky survival tools. Come introduce yourself and answer the question: What is the weirdest, messiest, most chaotic workaround you use just to get through your workday?
Let’s share the solutions that actually work.

Join the discussion at r/LobACob here!

The "Cold Boot" Update: How Dyslexic Developers Process the PM Interruption

Andrew Chadwick — Thu, 19 Mar 2026 12:59:02 +0000

We have all been there. You are deep in the flow state, mentally untangling a complex C# architecture or a massive SQL join, and suddenly, a wild Project Manager appears.

"Hey, do you have two minutes for a quick status update on the current sprint?"

For a neurotypical developer, this might be a mild annoyance. They pause, read the data from their short-term working memory, give a percentage, and go back to coding.

For a dyslexic developer, this interruption triggers a complete system crash. My brain doesn't just pause; it drops the entire architectural mental model I was holding. And when I try to answer the PM's question, I experience what I call the "Cold Boot."

If you are a neurodivergent dev (or a PM trying to understand one), here is what is actually happening in those first fuzzy minutes of a status update.

Phase 1: The Fuzzy Re-Render (Loading the Mental Model)

When the PM first asks me what is in flight, my initial answer is usually vague. “Uh, yeah, it’s going okay. I’m working on the backend ticket.”

I am not being evasive, and I haven't forgotten what I'm doing. The problem is that dyslexic brains often struggle with short-term working memory. We don't store project statuses as bulleted lists. We store them as complex, interconnected, holistic systems.

When I get interrupted, that system drops out of my RAM. The first 60 seconds of the conversation is just my brain frantically trying to re-render that massive 3D mental model from scratch. The details are fuzzy because the high-resolution textures haven't loaded yet.

Phase 2: The Associative Flood

But then, as the PM keeps talking and prompting me, something magical happens. They mention a specific API endpoint or a frontend bug, and a single node in my mental web lights up.
Dyslexic brains are elite at associative thinking. We might have a weak working memory, but our associative memory is a superpower.

As soon as that first detail clicks into place, the floodgates open. The fuzzy picture suddenly snaps into hyper-focus. I don't just remember the status of the ticket; I remember the entire ecosystem surrounding it.

Phase 3: The Chain Reaction

This is where the conversation takes a wild turn. Because my brain connects concepts holistically rather than linearly, remembering the current task instantly triggers a chain reaction of dependencies.

I will suddenly stop the PM and say, "Wait, the reason I am on this C# task right now is because I realized yesterday that if we don't refactor this specific service first, the JavaScript update on Thursday is going to break. Which means I actually need to ping DevOps about..."

I didn't plan to give a massive architectural update. But my brain doesn't isolate tasks. It sees the entire domino effect. Once the mental model is fully booted up, I can see exactly how the current ticket impacts a seemingly unrelated task three weeks down the roadmap.

Is this just a "Dyslexic Thing"?

While everyone hates context-switching, this specific "Fuzzy to Flood" pipeline is deeply tied to neurodivergence.

Standard Agile workflows expect linear updates: I did X yesterday, I am doing Y today, Z is my blocker. But highly systemic, dyslexic thinkers don't operate linearly. We operate structurally. We need a minute to rebuild the structure in our heads, but once we do, we can give you a level of interconnected insight that a linear thinker might completely miss.

A Quick Tip for PMs and Devs

For the PMs: If you ask a dyslexic dev for an impromptu update and they look at you blankly or give a fuzzy answer, don't assume they are lost or behind. You just caught them and their RAM has cleared. Give them 60 seconds to talk it out. Let the associative memory boot up. The insights you get will be worth the wait.

For the Devs: Stop feeling guilty for not having an immediate, bulleted list ready to go at all times. Your brain is rendering a 3D map while everyone else is reading a sticky note. It takes a little longer to load, but it's a far more powerful engine.

The Dyslexic Developer and the 5 Stages of Learning New Tech

Andrew Chadwick — Wed, 18 Mar 2026 06:15:18 +0000

There is a running joke in the industry that senior developers just read the documentation faster than everyone else.

If you are a neurotypical developer, learning a new tool usually looks like this: read the docs, copy the boilerplate, tweak a few variables, and push it to production.

But if you are a dyslexic developer, that linear path simply does not exist for us. We cannot just memorize syntax from 100 page doc. To learn a new piece of tech, our brains have to construct a complete, holistic mental model from the ground up. The start of the process is incredibly slow and agonizing, but the finish line is where we become almost superhuman.

If you’ve ever felt like your learning process is completely broken, you aren't alone. Here are the 5 actual stages of learning new tech with a dyslexic brain.

Stage 1: The "Vibe Check" (The High-Level Skim)

We start by opening the official documentation and reading exactly two pages: the "Features" list and the very top of the "Getting Started" guide.

We aren't actually reading the code here. Dyslexia means that staring at a wall of unfamiliar syntax right away is a guaranteed way to trigger brain fog.

Instead, we are just trying to get the high-level overview. What problem does this solve? Where does it fit in the stack? We are just laying the concrete foundation for the mental model we are about to build.

Stage 2: The "Step 6" Black Hole

This is where the pain begins. We decide to follow the "Getting Started" guide to the letter.
Because we process information differently, we end up re-reading the same setup page 15 times.

Everything is going fine until we hit Step6. On step 6 is where the documentation author casually skipped over a "basic" concept—maybe they assumed you already had a specific npm package installed globally, or assumed you knew exactly how this library interacted with a SQL database.

A neurotypical dev might have already seen in the 100 page documentation a single line that says you must add X in so Y can happen and then it will work. We get completely stuck. We spend the next 3 hours pacing back and forth, diving down an absolute rabbit hole just to pin down that one missing piece of context. It feels like wasted time, but this 3-hour detour is actually our brain frantically wiring the core structural understanding of how the tool actually operates under the hood.

Stage 3: Background Compilation

Frustrated and mentally drained, we abandon the tutorial and go back to our regular day job.
We pick up a standard C# or JavaScript ticket, but our subconscious is absolutely humming. While we are writing familiar code, our brain is quietly taking that hard-earned knowledge from Stage 2 and testing it against real-world scenarios. We start half-sketching architectures on sticky notes. “Wait, if I used that new tech here, it would totally eliminate that weird race condition…”

Stage 4: The Reality-Check PoC

In our spare time, the mental model is finally solid enough to test. We build a quick Proof of Concept (PoC) that is close to the idea we sketched out.

And immediately, we hit a brick wall. We find out the tech doesn't quite work the way our initial understanding thought it did. We hit blockers, edge cases, and weird configuration bugs. But because we already spent 3 hours suffering during Stage 2, we actually know how to read the error logs this time. We reframe our mental model, adjust the architecture, and force the PoC to work.

Stage 5: The Superhuman Delivery

Finally, a ticket comes across our desk at work specifically requesting this new technology.

Other developers might be nervously reading the docs, trying to figure out where to start. Not us. We implement the entire feature end-to-end at lightning speed. We completely avoid 90% of the common pitfalls because we already stepped on every single landmine during Stages 2 and 4.

We end up delivering the update at an incredible pace, armed with a niche, deep-level understanding of the tool's quirks that the other devs didn't even know existed.

The Takeaway

The dyslexic learning curve looks chaotic from the outside. It looks like getting stuck on easy things and taking too long to start. But what we are actually doing is front-loading the friction. We take the hit early, so when it comes time to execute, our code is closer to bulletproof.

How I’m keeping my open-source local AI app alive (and hardcoding my supporters into the UI)

Andrew Chadwick — Mon, 16 Mar 2026 17:46:42 +0000

Let’s be honest about side projects: they usually end up in a GitHub graveyard.

A few months ago, I was completely burning out. Between my dyslexia and the intense cognitive load of writing C# and untangling SQL all day, my working memory by 5:00 PM was entirely shot. Trying to remember what I actually did just to write my daily stand-up updates felt like an impossible wall of executive dysfunction.

So, I built SheepCat a 100% offline, local-first work tracker that uses Ollama to gently turn my messy, typo-filled brain dumps into clean corporate updates without leaking my company's proprietary code to the cloud.

I built it just to survive my own brain. But when I open-sourced it, the response from the community was incredible. Seeing other devs use it to reclaim their flow state and beat "time blindness" has been the highlight of my year.

The Reality of Open Source Maintenance

Keeping a desktop app alive, fixing bugs, and refactoring the architecture takes a lot of late nights. Up until now, SheepCat has been entirely fueled by my own stubbornness and a dangerous amount of coffee.

To help keep the project actively maintained, 100% free, and completely open-source, I’ve decided to officially launch Memberships on Buy Me a Coffee.
But I didn't just want to ask for donations. I wanted to build the rewards directly into the software.

The Developer-Focused Tiers
If you’ve ever wanted your name shipped to the local machine of every single user, this is your chance. Here is how the tiers break down:

☕ Tier 1: Keep the Lights On
Steer the Roadmap: Get exclusive access to backer polls. When we hit an architectural crossroads or need to prioritize a new feature, you get the deciding vote.
The README Roll: Your name and link proudly listed on the main GitHub repository.

💻 Tier 2: Baked Into the Code
The Hall of Fame: I am literally hardcoding your name and your handle (GitHub, Bluesky, etc.) into the codebase. You will be permanently immortalized on SheepCat’s new "About" UI screen.
Priority Triage: If you open a GitHub issue or feature request, let me know you are a Tier 2 backer, and your ticket jumps straight to the top of my local sprint board.

Building tools for our own brains
If SheepCat has helped you manage your cognitive load, or if you just want to support indie, local-first software, I would be incredibly grateful to have you on board.

You can check out the new memberships (or just drop a one-time coffee) right here @ buy me a coffee

Thank you to everyone who has downloaded the app, submitted PRs, or just dropped a kind word. Building for this community is an absolute privilege. 🐑🐈

Forem: Andrew Chadwick

The Dyslexic Mind Loop: Why Over-Preparation is a Fast Track to Burnout

​The Anatomy of the Loop

1. The Insecurity Trigger

2. The Granular Deep Dive (Over-Preparation)

3. The Accidental Flex (Validation)

4. The Toxic Reinforcement

The Slow Push to Burnout

Breaking the Cycle

Dyslexia + AI: The Ultimate power couple

The Load Bearing Pillars of the 3D Map

The Problem with "Implied Knowledge"

Enter AI: The Judgment-Free Sounding Board

A Cognitive Accessibility Tool

Part 2: Marketing New Apps Sucks (But Preparation Saves You)

Navigating the New SEO: Welcome to GEO

The "Done a Million Times" Objection

The Trump Card: The Foundation Member Pitch

The Takeaway for Indie Devs

Fixing the Messy Reality of Dev Time Tracking (SheepCat v1.4 Release)

⏱️ The Timing Fix: Chain-Based & Fixed Durations

⏪ The Time Machine: Rerunning Historical Summaries

It’s Better to Be Lucky Than Right: Why Your Code Needs the "Seemingly Pointless" Catch-Alls

The Edna Mode Principle

Trust Your Intuition

Is It Still Engineering If AI Writes the Code?

The "Screenshot to App" Trap

The Engineer’s Mindset: Systems over Syntax

The Power of Pushback

The Verdict

I Got Tired of Jira Breaking My Flow State, So I Built a Local App to Bypass It (SheepCat v1.3)

The Self-Taught Engineer vs. The CS Graduate: Why Teams Need Both

The Starting Line: Vocabulary vs. Hands-On Practice

The Real World: When Production Breaks

Reaching Senior Level: The Convergence

The Verdict

Surviving a Neurotypical Industry: What "Janky" Workarounds Get You Through the Day?

The Graveyard of Polished Products

Who Should Join?

What is Your Workaround?

The "Cold Boot" Update: How Dyslexic Developers Process the PM Interruption

Phase 1: The Fuzzy Re-Render (Loading the Mental Model)

Phase 2: The Associative Flood

Phase 3: The Chain Reaction

Is this just a "Dyslexic Thing"?

A Quick Tip for PMs and Devs

The Dyslexic Developer and the 5 Stages of Learning New Tech

Stage 1: The "Vibe Check" (The High-Level Skim)

Stage 2: The "Step 6" Black Hole

Stage 3: Background Compilation

Stage 4: The Reality-Check PoC

Stage 5: The Superhuman Delivery

The Takeaway

How I’m keeping my open-source local AI app alive (and hardcoding my supporters into the UI)

The Reality of Open Source Maintenance

The Anatomy of the Loop