Programming

• 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

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

1. Read the documentation
2. Try some simple examples from the docs
3. 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.

Read. Build. Repeat.

Get theory from somewhere on the Internet (videos, tutorials etc.), then do exercises on platforms like Exercism. Once you feel like you are getting good at it, start replacing the time for exercises on time with real projects

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.

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.

i like to douse myself in mud, then slowly creep up on it from behind, taking extra care not to break any twigs or ruffle any leaves, then I grab it and hold on for the ride of my life

Read official docs, then rewrite some small own project in it.

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

1. I asked "where can I find the code that does X" and it told me to search the project for "Y" to find it.
2. 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.

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

Solve advent of code in it

Build something that already exists. My go-to is usually dir.exe.

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.

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.