I'm not talking about which language to learn first or which framework to use. There's plenty of that advice already. These are the things no tutorial covers.
Ship Ugly Things
The single best accelerant to learning is finishing and shipping projects, even when they're embarrassing. The gap between "almost done" and "done" is where most learning happens.
I have a graveyard of half-built projects that each taught me 30% of what a shipped project would have.
Read Other People's Code
I learned more reading well-written open source code than from most tutorials. Pick a library you use, find the source, and spend an hour understanding how it works.
The skill of reading unfamiliar code is as important as the skill of writing it.
Understand the Problem Before the Solution
It's tempting to reach for a framework or library as soon as you understand what category of problem you have. Resist that for a minute.
Before adding a state management library: what problem am I actually solving? Can I solve it without the library? If not, why not?
Understanding why a tool exists makes you dramatically better at using it — and at knowing when not to.
The Documentation Is Usually Good Enough
When I was starting out, I'd search for tutorials before reading the docs. That's backwards. Docs are usually more accurate, more complete, and more up to date than tutorials.
The tutorial teaches you the author's mental model. The docs let you build your own.
Slow Down to Speed Up
Writing code fast is not the same as building software fast. The time spent thinking, reading, sketching, and asking questions almost always reduces the total time to a good result.
The best developers I've worked with are often the ones most willing to pause and think before typing.
Everything Is Learnable
This is the one I needed to hear most. When something feels too hard, it usually means I haven't yet found the right explanation, not that I'm not capable of understanding it.
Keep looking for a different angle. It's out there.
Comments