Depth Over Breadth
The more projects I take on, the more I’m convinced: the biggest leaps in ability come from going all-in on a problem you genuinely, desperately want to solve.
Not “this seems interesting, let me give it a shot.” More like — you’re thinking about it over dinner, in the shower, and at 2am when a new angle hits you and you get out of bed to try it.
When you care that much, you dig. You don’t just grab the first solution that works — you keep asking why it works, why the other thing didn’t, what’s actually happening underneath.
When you’re all-in, you exhaust the possibilities. Plan A fails, try B. B fails, try C. C fails, smash parts of A and B together into some weird Plan D. And none of it is wasted — each dead end pushes you somewhere you’ve never been before.
You can’t get that from skimming across projects.
Breadth tells you what exists. Depth teaches you how things actually work. And once you’ve truly understood one thing — really understood it — the way you see everything else changes. Because now you know what “actually getting it” feels like, and you can’t fool yourself anymore.
So no, doing more isn’t the answer. Doing more is a trap — you touch everything, finish nothing, and never get pushed to your limit by any single problem. It feels productive. But look back and there’s nothing there.
Do less. Go deeper. Find the problem that keeps pulling you back, and stay with it.
Growth isn’t about how many things you’ve touched. It’s about how deep you’ve gone on one.
How I deeply learned this one — the best UI design is leading users to the core product value as friction-free as possible:
