Why I Created a Specific Curriculum

About twelve years ago, I was driving 45 minutes each way from work, listening to a podcast called Coding Blocks. They would take a single programming concept and thoroughly explain it.

That was the last time learning felt like something I could absorb while living my life instead of pausing it.

Eventually, that content became harder to find. Most programming education shifted toward tutorials, frameworks, and rapid builds. Useful, but fragmented. I found myself trying to bend other people’s projects to fit what I actually wanted to build.

That friction never went away.

From Consuming Projects to Designing My Own

The shift happened when I realized I didn’t need to consume someone else’s curriculum. I could create it myself and tighten it through iteration.

Instead of watching videos and adapting them to my current project, I could describe what I wanted to understand, dump all the constraints and half-formed ideas out of my head, and use a large language model (ChatGPT) to help me structure my thoughts and provide valuable feedback. That’s the difference between letting a tool generate content and using it to refine my own ideas.

That feedback loop changed everything.

The Brain Dump → Clarifying Questions Loop

My process usually starts messy. I describe the goal. I include context. I ramble. I contradict myself. I mix philosophy with implementation.

Then the model pushes back with clarifying questions.

That back-and-forth does something subtle but powerful. It forces assumptions into the open. It surfaces decisions I didn’t realize I hadn’t made. It extracts structure from nonlinear thought.

The outcome improves when the model challenges my assumptions instead of just expanding them.

I avoid using the term “AI.” That term implies agency and authority. What I’m working with is a probabilistic language model. It predicts text based on patterns. It isn’t an authority. It doesn’t know truth. It’s a tool for shaping language and ideas. Language matters because it shapes how much trust we assign to tools.

Writing as Iteration, Not Output

Once the structure appears, we tighten. We rewrite. We compress. We expand. We reorganize. The first draft is rarely the final draft.

This is where learning deepens. The refinement stage forces clarity. If something can’t survive rewriting, it probably wasn’t understood yet.

This post exists because of that process.

Designing a Learning System That Survives Reality

The other half is the learning project itself.

I didn’t want a course. I wanted a system that could survive distraction, repetition, and time gaps. Something I could listen to while driving. Something that could sit in my head while I’m on a tractor. Something that doesn’t collapse if I miss a week.

So I designed the lessons to be audio-first. Clear sentences. Repetition on purpose. One core mental model per chapter. Code is separated from narration, so listening never turns into noise.

The idea is simple: understand the behavior first. Touch the keyboard later.

Repetition with Increasing Specificity

The real breakthrough wasn’t structure. It was layering.

The same core ideas repeat across the entire learning path:

  • State
  • Inputs and outputs
  • Conditions
  • Loops
  • Failure
  • Boundaries

As specificity increases, the concepts stay the same.

First they show up in abstract examples. Then in Python. Then in HTTP. Then in databases. Then in embedded systems. Then in real homestead automation.

Each time, the idea gains resolution. Complexity grows, but the mental model remains stable.

That repetition is not accidental. It’s reinforcement under increasing load.

Listening Isn’t Lesser Learning

There’s an assumption that passive listening is inferior. That if you’re not at a desk taking notes, you’re not serious.

That is not how it works for me.

Listening is not lesser when it’s intentional. It’s pre-loading the model in your head. It’s building intuition before implementation.

When I sit down to write code after listening to a concept multiple times, it doesn’t feel foreign. It feels familiar. The terrain is already mapped.

Owning the Learning Stack

On the homestead, I care about owning my power stack. My water stack. My infrastructure.

Why wouldn’t I care about owning my learning stack?

Instead of renting someone else’s roadmap, I built one that fits my constraints, my goals, and my timeline. It’s modular. It evolves. It tolerates gaps.

Most learning systems are fragile. They require momentum and motivation. Mine is designed to survive interruption.

Design Your Own

You don’t need my curriculum. You don’t need my structure.

But you might need your own.

Start with a brain dump. Be explicit about your constraints. Let someone—or something—push back with clarifying questions. Refine the structure. Design for repetition. Separate narration from execution.

Own your stack.

Learning isn’t something you download. It’s something you architect.

Explore the Project

If you’re curious how this learning system is structured, you can explore the full repository here:

Learn-to-Code-Slowly on GitHub