About 18 months into my first dev role, I noticed something uncomfortable. I could ship features. I could debug pretty well. I’d gotten reasonable at code review. But when senior engineers had architecture discussions, I was nodding along without really following. They’d talk about whether to put a queue between two services, whether to denormalise a particular table, whether the new feature needed eventual consistency or strong, and I had no framework to engage.

That was the systems design gap. Most self-taught devs hit it eventually, and I want to walk through how I started closing it without going back to school.

Why this gap exists

Self-taught devs typically start with a specific application in mind. A web app, a mobile app, a script that does something useful. The path to learning is project-driven and the projects mostly fit on one machine or in one cloud service.

Systems design starts when problems get bigger than that. Multiple services. Distributed state. Scale. Failure modes you have to actually think about. The concepts here weren’t covered in any tutorial I followed in my first year.

CS grads don’t necessarily have these covered either, to be fair. But they often have adjacent concepts (operating systems, networks, databases) that give them a head start when they encounter systems design at work.

The three things that helped me most

A bunch of stuff helped, but three things moved the needle disproportionately.

1. The “Designing Data-Intensive Applications” book

I know this book gets recommended constantly. There’s a reason. Martin Kleppmann’s book is the single best resource I’ve found for the conceptual foundation. It’s dense - took me about four months to work through - but every chapter unlocked something.

The key insight for me was that almost every interesting systems design decision is a tradeoff between consistency, availability, latency and complexity. Once I had that framing, the architecture conversations at work started making sense. I could finally tell why senior engineers were arguing for one approach over another.

I’d recommend reading it slowly and actually doing the exercises. Skimming this book defeats the point.

2. Reading post-mortems religiously

The other thing that accelerated me was reading public post-mortems from companies like Cloudflare, GitHub, Stripe, and AWS. The Cloudflare blog in particular publishes incredibly detailed incident write-ups that walk through the actual systems involved.

Reading these taught me how systems fail in practice, which is the negative-space lesson behind systems design. You learn what could go wrong by reading about what did go wrong elsewhere. Over time you build pattern recognition for failure modes - cache stampedes, retry storms, thundering herds, gradual cascading failures - that lets you anticipate problems in your own systems.

I now spend maybe 30 minutes a week on this. It’s the highest-value learning activity I do.

3. Asking to be in design review meetings

This was scary. The first few meetings I was in, I felt like I shouldn’t have been there. I didn’t say much. I took notes and tried to follow along.

But persistence paid off. By the third or fourth meeting I started catching things. By the eighth I was asking questions that occasionally turned out to be useful. By month four I was contributing meaningfully.

The tactical advice: ask your manager if you can be a silent observer in architecture meetings. Most managers will say yes if you frame it as wanting to learn. Don’t try to contribute too early. Just listen and note what you don’t understand, then look it up later.

What I’d skip

A few things I tried that didn’t help much:

System design interview prep videos. These are useful if you’re actively interviewing. They’re not great for general learning. The format optimises for impressing an interviewer in 45 minutes, which doesn’t match how real architecture discussions work.

Building toy distributed systems. I tried to build a “mini Kafka” as a learning project. Got 30% through and bailed. The exercise wasn’t bad, but I was reinventing things without understanding why. Reading mature systems’ source code and writing about it taught me more.

Trying to learn everything before applying it. I held back from contributing to architecture discussions for too long because I felt I needed to know more first. Wrong call. You learn faster by being slightly out of your depth and getting corrected than by reading more in private.

The AI angle

GenAI changed how I learn systems design. Two specific patterns:

Using Claude as a sparring partner for design discussions. I’ll explain a system I’m thinking about and ask it to poke holes. The output isn’t always brilliant but the prompts force me to articulate my thinking, and the responses often surface considerations I hadn’t thought of.

Using AI to read source code faster. When I’m trying to understand how a real system works, I can paste in source code and ask for explanations of specific patterns. This used to take me hours of bouncing between docs and code. Now it takes minutes.

That said, I’m wary of just asking AI for systems design answers without doing the underlying learning. The AI will give you something that sounds reasonable. Whether it’s actually right depends on whether you can evaluate it. And evaluating systems design requires the underlying knowledge that AI can’t shortcut.

Where I am now

Three years in, I can hold my own in most architecture discussions. I’m not yet at the level where I’d lead the design of a new platform, but I can contribute meaningfully, push back on bad patterns, and ask the questions that surface real problems.

My current learning project is going deeper on database internals. I’ve been working through the PostgreSQL source code in spare hours, trying to understand the query planner. This is far slower than the earlier learning was - the gains are smaller and more specialised - but it feels like the right next direction.

For other self-taught devs

If you’re hitting the same wall I hit, three pieces of advice.

First, accept that systems design is its own skill that requires deliberate study. You won’t pick it up by accident from your day job, even at a good company. You have to invest in it.

Second, balance reading with exposure. The book learning is necessary but not sufficient. You need to be in real architecture discussions where the tradeoffs are live and the consequences are real.

Third, don’t be embarrassed about the gap. Most senior engineers I know have at least one area where they feel like they’re playing catch-up. The discipline of identifying gaps and closing them is more valuable than knowing everything from day one.

The gap is closeable. You just have to actually close it.