Building is the fastest way to learn anything

Every serious engineer I know learned the same way, whether or not they can articulate it: they built something slightly beyond their ability, got humiliated by it, and shipped it anyway.

The internet is full of curated learning paths — courses, roadmaps, reading lists. They are not wrong. But they mistake the map for the territory. You do not learn distributed systems by reading about distributed systems. You learn them by writing a queue, watching it lose a message, and understanding, in your body, why the paper you read last month said what it said.

Building forces you to make decisions that reading lets you defer. What is the schema? What is the error type? What happens when the network blinks? The moment you have to answer those questions with code, you discover the shape of your ignorance with a precision that no textbook will ever give you.

There is a deeper thing here, too. Building teaches taste. You start to notice which decisions age well and which ones you regret in three weeks. You develop a sense for the kind of code, the kind of system, the kind of product that you want to be responsible for. That sense is the actual asset. Everything else is scaffolding.

The tactical version of this advice is boring and correct: pick a real problem, cap it at two weeks, ship something a real person can use, then write down what surprised you. Do that four times a year for a decade and you will be unrecognisable.

The strategic version is more important: your career is a compounding function of the things you have shipped, not the things you have consumed. Optimise accordingly.