# Nobody learns to design a system by reading about design.

I’ve mentored junior developers for years, and the advice they’re getting right now worries me. They’re told software engineering is mostly architecture and design now, and that writing the code is the part tools handle.

I learned architecture the slow way. I shipped a query that ran once per row. I built an API I had to version because I got the first design wrong. I wrote a service that ignored timeouts until production taught me why they matter. Each mistake left behind a kind of judgment no book gives you, a feeling for what will hurt in six months.

That judgment comes from doing the tedious work by hand, again and again, until the patterns become instinct. Reviewing good code and producing it are different skills. Anyone can nod along at a clean design. It takes reps to know why it’s clean, and to notice the quiet flaw in one that only looks clean. If juniors skip those reps because everyone is pushing them away from writing code, I honestly don’t know where the instinct comes from.

It’s easy for seniors to say they’ll figure it out. I think that’s us forgetting how hard it was the first time. Nobody remembers the weeks they spent confused by something that now feels obvious.

What I’m trying for now is simple. I ask juniors to write the first version themselves, even when a tool could produce it faster, and then we review it together and talk about what they’d change. I also ask them to explain a failure they caused, in plain words, because that’s where the lesson sticks. It’s slower, and I think it’s the only way the judgment forms.

Tools will keep getting better, and I’m glad. But either they get good enough that this stops mattering, or we end up with engineers who can describe a system and can’t tell when it’s wrong.

If you lead a team, how are your juniors getting their reps in right now?