How to learn how to learn (as a dev)

One major takeaway was to "learn in public". That is, share what you learned for the sake of ensuring you actually learned it.

Learning in public seems (to me) connected to Einstein's quote: "If you can't explain it to a 6 year old, you don't understand it yourself". It also appears related to the concept of "the protégé effect".

I was about to write this blog post after I set up a fancy blog on my website: seif.rocks. But Josh warned about this mental trap that keeps one from starting.

So, I decided to write my first blog post (I think) about some of the main takeaways from Josh's article. Here we go:

"Guided" vs "Unguided" learning

Guided learning is when you read tutorials, docs or watch videos (amongst others). Unguided learning is when you code it out yourself.

In order to learn more effectively and avoid things like tutorial hell, you can mix the two methods. For example:

Try figure out the purpose each block of code (from the tutorial) and prove yourself right (or wrong) by fiddling with it.

Follow the tutorial as instructed. But then, minimize the tutorial window and try to redo it yourself. This way you can test yourself because "tests are best" after all.

Follow the tutorial as instructed (again), But then, do a different or extended version. For example, If you learned how to do an Instagram clone, do a twitter clone. Or, if you did a tutorial with plain and boring frontend, make it more production-like.

Build daily habit

Instead setting a side one day per week for learning. Make it a daily thing.

For me, I (try to) start my day with one hour of solving algo problems.

The main benefit of habits is that the more you do them the less they feel like a "chore", and consequently the less "motivation" you need to keep them going.

Read the blog post here: joshwcomeau.com/blog/how-to-learn-stuff-quickly/

Image credit belongs to woodnest