- Start with an ambitious project
- Get stuck
- Curse everything about said language or framework, "why did they do it like this"
- Read the docs and find out why they did it like this
- Feel stupid
- Finish the project (or at least the part you actually cared about) with your new knowledge
- Feel smart
- Repeat until you know said language or framework
Easy to get caught in a perpetual loop with steps 4 and 5
You should be learning a bit more with each loop though.
Even banging your head on the wall against something eventually gets you somewhere.
I get stuck at step 2
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
- Read the documentation
- Try some simple examples from the docs
- Build a simple project
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.
Read. Build. Repeat.
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.
Read official docs, then rewrite some small own project in it.
Solve advent of code in it
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."
- Watch a project tutorial video
- Code along with the video and taking notes
- Create my own project with the notes i took and documentation
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
- I asked "where can I find the code that does X" and it told me to search the project for "Y" to find it.
- I asked it how to use a code generation shell script bundled with the framework to do a common task, and when I explained that the answer didn't seem to line up it said "in that case you can't use the script. You'll need to write the code manually, here's how to do that"
Both pieces of advice were spot on and saved me hours of googling.
Build something that already exists. My go-to is usually dir.exe.
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.
