How I Think About Learning
How to become expert at thing:
1 iteratively take on concrete projects and accomplish them depth wise, learning “on demand” (ie don’t learn bottom up breadth wise)
2 teach/summarize everything you learn in your own words
3 only compare yourself to younger you, never to others
That quote is from Andrej Karpathy’s tweet where he briefly describes two broad ways of learning: breadth-wise and depth-wise.
Breadth-wise learning is familiar. You move across a wide surface area: lectures, courses, reading lists … trusting that the material will become useful later. Depth-wise learning tends to work in the opposite direction. You pick something to build, start working, and only learn what you need when you hit a limitation.
In the Dwarkesh podcast, Karpathy argues strongly for the latter. He says that when he teaches, he withholds explanations until the student has felt the problem for themselves. As he put it, “It’s a dick move to present the solution before I give you a shot to try it yourself”. The idea being that once you’ve struggled, the solution has somewhere to land.
In that sense, I don’t do particularly well with breadth-wise learning on its own. If I don’t know why something matters, my attention drops off really quickly. I was reminded of this recently when I briefly considered learning more about AI. As the field kept expanding, I asked one of the ML engineers I work with for good resources. They pointed me to the a16z AI Canon as a starting point, which eventually led me to the fast.ai course taught by Jeremy Howard.
It’s a really really well-regarded course, and I can see why. But I got bored sooner than I expected. Not because the material was poor, but because I didn’t yet have a problem that required it. Without a concrete need, the concepts stayed abstract. And that clarified something else for me: I’m less interested in fundamentals in isolation, and more interested in how ideas show up inside real systems.
And so, depth-wise learning fits me better. I learn best when I’m doing … when I’ve committed to building something and the gaps reveal themselves naturally. When a system resists me, the learning becomes specific and grounded. I don’t mind throwing mud at the wall sometimes and seeing what sticks.
Another thing I’ve noticed is that I’m rarely satisfied with only the minimum needed to move forward. Once I’m working with a tool or system, I tend to explore its broader shape. For example, I often skim through documentation before deploying or configuring anything. Not to memorise it, but to understand what exists.
There’s value, for me, in knowing what I don’t know. If I don’t know something is there, I won’t know to reach for it later. Having a rough mental map, even an incomplete one, makes it easier to navigate when a real need arises.
So I find myself somewhere between the two ends of the spectrum. I don’t want exhaustive breadth without context, but I also don’t want to learn the bare minimum and stop there. I want enough depth to feel friction, and enough surrounding knowledge to feel oriented in the problem space.
Admittedly it’s slower, but over time it seems to compound. The details I pick up along the way tend to resurface later, often outside their original context, and make it easier to reason, adapt, build something new, or even just have opinions.