You should be learning a bit more with each loop though.
Even banging your head on the wall against something eventually gets you somewhere.
Honestly I just open up a new project and start fucking around until I figure out syntax, language features, and how files relate to each other
Either I come up with a new project or I rewrite an old project in the new language.
I used to do those old school language tutorials where we start with how to write a variable, then how to write a function, etc. but I think that's better for complete beginners just starting out.
I've done project rewrites. This minimizes the problem solving to mostly just syntax, sometimes a new paradigm if the framework is different enough. But in my experience a rewrites goes so much faster than I expect it, since theres a very clear goal to achieve while rewriting. If someone has an existing project to rewrite, I recommend it. If not, you could implement some project in a framework your comfortable with, and then do a rewrite in the new thing.
Rewrite one of my old C projects in it and compare the difficulty, ease of understanding the code, any issues/boons in documenting it, etc.
Is it possible to build XML parser in it?
If answer is yes then i will build XML parser in it.
Solving a problem you know how to solve and solved more than once is a my goto approach in learning languge or frameworks. Translation of already solved problem to the new operational model or semantic exposes a lot internal stuff and marketing double talk.
This is a lot of work and time so can not recommend it for all cases and situations.
This is what I do, too. Good for programming languages. Not always applicable for frameworks.
Start a project with a good template and learn by tinkering. Some languages/frameworks have some canonical starter templates (.NET, Phoenix/Elixir) and most others you can find by googling "x boilerplate."
These days I use ChatGPT 4, with a long running conversation where I explain what I'm trying to do, what tools I'm using, paste in sections of code that I don't understand, asking how to change the behaviour of that code, give it error messages I'm seeing, etc.
It feels really close to pair programming with someone sitting next to me who knows the language/framework. The code it writes is often wrong but it's close enough that I can work reasonably efficiently.
A couple favourite from earlier todays
Both pieces of advice were spot on and saved me hours of googling.
rebuild stuff
I've remade a temperature converter cli 3 times in rust. Just to understand enums, structs and the borrow checker. Then I made an http server, that acted as a library's book borrowing system.
I've started using LLMs for this. You can get up and running incredibly fast this way.
I use enterprise bing at work so it sources each sentence so I can go directly to the docs if I need to.
I've found it really superior to reading docs as it's interactive. Being able to ask follow up questions is very powerful.
I've noticed the new batch of juniors at work are able to get productive very fast by using them.