Learning Concepts

Why I built it

Learning has been getting cheaper every year. Engineers now finish the core CS courses before their first year of college is over, and pick up system design, ML and AI before their second. It won’t be long before kids in school are good at this too, because the material is easy to get: visualisations, and the same idea explained a hundred different ways until you’re satisfied with the answer.

So instead of buying one more curated course or reading one more book online, I made my own. I came across an ad for fanout.sh’s system design course, liked how it was structured, and built the same kind of structure for myself. Not for a job hunt. For me to sleep well at night knowing how things work, including the things I didn’t understand, or didn’t pay much attention to, in college.

What it is

The courses I started with are the ones closest to my day-to-day work, which is mostly AWS, Python and Postgres:

• PostgreSQL, because it’s the database I use every day, and I wanted to know what actually happens under a query, an index or a vacuum instead of treating it as a black box.
• Language Runtimes & Concurrency Models, because Python’s runtime, async code and workers decide how my services behave under load.
• Landmark Cloud Systems, the designs behind services like DynamoDB, Aurora and S3, because I build on AWS and wanted to understand why those systems work the way they do.

Everything else in the library is there to support those. Operating systems, networking, computer architecture, data structures, algorithms and maths are the basics I needed to really understand the high-level details. System Design ties them together, and the ML courses are where I’m heading next.

Every course is a chain of problems in dependency order. Each topic states which problem it inherits and which one it leaves open. One rule holds the whole thing together: no concept may be used before it has been taught.

I read it on my phone wherever I am, even offline, and it brings back old topics for review so they stick.

How it changed over time

It started as sticky notes. At first, everything was a note on one topic at a time: whatever I was trying to understand that week, written up on its own page. I realised that wasn’t the best way to learn. Each note stood alone, with nothing telling me what came before it or what to read next.

Then it became courses. I reorganised the notes into courses and modules, with progress, so every topic had a place in an order and I could see how far I’d got.

Then I realised they were just books. A course is a book and a topic is a page. So I made them look and behave like that: a shelf of books, a warm, paper-like theme in the spirit of a Kindle, serif text, and one topic per page. That alone increased my focus span. I read one topic at a time instead of skimming across many.

Then it grew with Claude. Writing every course by hand would have taken years. So I asked Claude to research each course and prepare a plan, reviewed the plan, and then Claude wrote the lessons module by module, which I reviewed too.

Then I made it simpler. Lessons written that way tended to be dense. So I went back through the courses with one test: could a reader who knows nothing follow this? Jargon became plain words, and every term now gets explained where it’s first used.

Then I gave it a voice. Some ideas are easier to follow when someone walks you through them, so many lessons now have a narrated explainer that plays inside the page.

How I work with agents

Claude writes the lessons. I tried Codex and Devin for writing topics too, but they couldn’t match Claude on quality or completeness: lessons came out thinner, skipped steps, or stopped short of the whole idea. So Claude writes the topics, and Codex and Devin build smaller features alongside it.

Claude plans, I review. For each course, Claude researches the subject and prepares a plan: what problem each topic solves, and what it can assume the reader already knows. I review the plan before any lesson is written, and I review the lessons that come back. Every lesson also has to follow a shared set of rules about what it must and must not do.

A mistake seen twice becomes a rule. Not a note in a log. If I catch the same kind of mistake a second time, it becomes a rule in the rulebook or an automated check, so it can’t quietly come back. The rulebook is how I teach the agents, and it keeps growing.

What I learned

• The shape of the material changes how well you learn it. Notes, then courses, then books: the content barely changed between them, but how long I could stay focused did.
• When Claude writes the content, the rules are the real work. Every rule in the rulebook is a mistake that happened at least twice.
• Plain words are harder than jargon. The biggest rewrites weren’t about adding topics. They were about saying the same thing more simply, once, with one picture.
• Build the thing you’ll use. I read these courses myself, and that’s how most of the problems got found.