I've found that I just won't learn a language or framework unless I have a clearly defined goal/project in mind, so I usually start with that. Toy or otherwise

I've found that I just won't learn a language or framework unless I have a clearly defined goal/project in mind, so I usually start with that. Toy or otherwise, if I don't want to build some sort of project, for which the language or framework is a good fit, then I won't ever learn more than just dipping my toes into the language. My approach is actually fairly consistent across languages/etc., and it usually gets me up to speed/gets me to a point where I know enough to work with something, but certainly doesn't make me an expert in the language or framework. I start by doing a hello-world equivalent, usually with some sort of input and output. (E.x. "What's your name?"->"Dave"->"Hello Dave!") Then, I usually go through some sort of basic program to get an idea of how the language features work and how things are done in the language. Exactly what depends on the framework or language; but usually of comparable difficulty to a dynamically resizeable array with basic algorithms like 'sort' (merge, quick, etc.) in C. The idea is to write something you're fully capable of knocking off in less than two or three hours, and is <1000 lines of code but isn't trivial. My reasoning for this intermediate step is that a large project needs to have some sort of structure, and if I don't have at least a rudimentary understanding of how things work in the language, then I'm going to have a bad time. After I've done that, I get started on the actual program or project: I start by constructing a rough framework of how I want to structure the program and then slowly add in the parts that I want, restructuring if it's necessary. Throughout the process, I look at websites/books/documentation/code examples/etc., particularly if I don't know how to do something or think there's a better way than what occurred to me.