I attack it by four different angles who will hopefully converge

• Find outWHY the technology is interesting in the first place. I choose to ignore things likeblockchain that have an unconvincing WHY?.
• Find a good way toget started, by asking people if there is a tutorial they can recommend
• Make a list of theconcepts I'm unfamiliar with that are related to that technology. I keep it very high level, the equivalent of reading only the introduction in a Wikipedia article. Here is an example I made for data science -->checkvist.com/p/hZRCg7XybRU2jMne6b...
• Imagine a concretesimple but meaningful project that I could build with said technology. This will force me to learn things on demand when I need them versus trying to learn everything at once but not knowing to do anything in practice. This is the part I usually struggle with :)

First off, loving this topic!

I think like you I'm a hands-on learner, but on the contrary, I really prefer to get guidance and have someone show me how to do something if possible.

I'd prefer to have the person with me in person showing me how it's done, but if it's over video call that's okay too. I suppose I can also generally learn from someone typing instructions and guidance to me over Slack, but if it's a multi-step kinda process and/or something more visual, I really prefer to work through it with them.

I think this is my preference because a) I like the opportunity to ask questions on the fly and b) I have a pretty good memory for experiences. On the latter, I notice that if I'm on call with someone and we chit-chat a bit about something, then they help to teach me whatever the thing is I'm learning, I'll kinda group the two things together in my mind and it helps me to recall it.

Go for written tutorials rather than video tutorials.
That way we get to learn a lot more by exploring related things. But in case of videos, we just follow what is being done there and we only get a high level understanding.
A well written step by step guide/ tutorial is better than video tutorials.
Also, we get a clear understanding when doing hands on with written tutorials.

Depends on what I am learning

• Programming language? -> Youtube crashcourse. Then:
  • if there is one: Official book, e.g. The Rust Book
  • else, inofficial tutorial, e.g. Javascript for Cats
  • then, keep reading dev.to, hackernews, etc.
• Product? -> Try it, fiddle, fail, read the docs.
• Tool? -> Depends on the tool. Examples:
  • For Unity -> took a course.
  • For VSCode -> read the docs
  • For Postman -> nothing, UI was trivial enough

If there is a course or tutorial with title "Learning {tech} in 6 hours", it's totally normal if you're not finishing it in 6 hours.

Just spend the first hour or the first section, not more than 1 hour. Then spend about a day or even a week to build something with everything you know from the first hour of tutorial if possible. This can be a small project that you can save in cloud drive, github gist, note, etc.

Continue the next hour of tutorial with the same step. The bigger the project you build, to may need to store it into git repository.

I tend to be a "sandbox learner" :-) and I use simple quick-start examples illustrating the concepts, and, later on, minimal projects with increasing complexity. This can be based on video courses, books, articles. Usually I focus on leading examples and I learn self-paced, "without supervision" :-), this suits me best. This way I learned in the past 4 years the technologies such as Git, Bitbucket, Docker, Ubuntu, GCP/GKE ...

I learn best by just jumping in and writing full programs in the new language. Mostly, writing cli tools first and then moving on to graphical items as I learn the new language. I rely on the online docs to teach me everything I need to know about a new language. Sometimes I buy a book.

I do learn while doing. I do absorb 20-30% from a course or any source and then go for implementation. And then I go for 50% and I do until 80-90%.

Then I do work on Good Projects and I do share all my learnings onlovepreet.hashnode.dev/

1. Hear about the new tech
2. Decide if I find it interesting
3. Put on backlog

... long time ...
Technology became obsolete, return to 1. 😁

But usually most dev tech has some kind of examples on their website that I look at. From that I can usually gauge whether I can implement it in a project or not and if it's better than the current tech that I'm using or not. When it's better I either try to implement it into an existing hobby project or start a new one. Along the way i use google/stack overflow to solve any issues i run into. If i can't find solutions immediately, it goes on the backlog as "non mature tech".

learning by doing takes longer than just going through a book or course, but the material sticks longer and better that way. a lesson you learned by overcoming a problem is always more treasured than something you merely read.

i also take the effort to type out samples, rather than just pasting them. transcribing makes you focus on the content and structure, not just the results.