There’s a genre of content online that frames learning as an optimization problem. Learn React in 30 days. Master system design in a weekend. The implicit premise is that faster is always better.
I’ve been thinking about whether this is true.
Speed is sometimes the wrong variable#
When I’ve tried to learn something fast — really compress it into a short window — I tend to end up with a shallow model that breaks under pressure. I can answer the interview question but I can’t debug the production incident.
Slow learning looks different. You’re not going from zero to competent in a weekend, you’re accumulating understanding over weeks or months. The understanding compounds differently. It feels like things start clicking into place rather than being memorized.
The walk analogy#
When you walk somewhere you notice things you don’t notice when you drive. The texture of the neighborhood. The small details. The way things connect.
I think learning has a similar quality. When you let understanding develop slowly — reading, building, getting confused, sleeping on it, returning — you’re doing something more like walking. You’re building a map from lived experience rather than trying to memorize a grid.
What this means practically#
I’ve stopped optimizing for how fast I can get to “competent.” I try to stay curious longer. I take more detours. I let myself be confused for longer before reaching for the solution.
The result is that things I’ve learned this way tend to stay learned. I can still explain systems I worked on years ago, not because I have a good memory, but because I understood them at depth.
I’m not saying don’t be efficient. I’m saying efficiency in learning might mean something different than it means elsewhere.