mint

this isn't nearly complete, but here's my pre-coffee explanation. it's long. this isn't the only way to learn, maybe it's not even the best way to learn, but it's the only way that worked for me.

tip: hit buttons on your monitor until you figure out where the sharpness setting is and make it go up 1 ticks.

its often set too low by default, you'll see a noticeable change in how easy it is to see thin things. check text on white background and text on black background for each change

don't start with reading the books unless you can't do the following:

have a project, break it into pieces. projects can be grand ideas, or "wow i wish i could perform this operation on a text file but no tools do it". it's ok if your project is unrealisticly big or ambitious, there will always be small pieces you can break off and implement. the project is for generating things to break down until they're simple pieces, then finding out how to do each piece. even experienced people often work this way. web search isn't taboo except on loudvoice bigface YouTube.

if you can't think of anything, use something like an old advent of code. advent problems are hard, but when you're learning, the goal is to give it a try, and then look up the answer thread on Reddit, or answers on YouTube. people do advent of code as a learning experience, and share that. they get harder as the number goes up, but that's true every year. if you get stuck, go do a previous year.

It's a rough start but imo this teaches things better than the tutorials. reading and watching videos help you understand what's out there, but they don't really translate to learning, writing code does. Even if you don't understand it. Once it works, once one piece of it works, figure out why it does.

also don't choose python. it's a nice language to learn, but it has so many things unique to it with regards to code layout and structure that it's actually better to learn JavaScript or something instead (to reduce complexity, ignore the ES6 syntax for now). if you can't, python is a good start. But it'll be like learning all over again when you switch languages.

I do recommend learning Python before Rust though, as it introduces you to a lot of the more advanced concepts pretty fast and easily. (iterators, for x in y, etc)

then:

To expand on a few things:

type it out, copying and pasting doesn't build the muscle memory.

100000%. Even at my stage, when I learn about a new API or whatever, I take the time to write. it. out. It's almost silly how much it helps to just "rewrite" a StackOverflow/doc answer but like, it really helps cement it in your brain.

optionally web search for at least a linter and ideally a formatter for your language that has plugins for your editor of choice. the linter will catch errors before you run the program, the formatter will show you neat tricks for making things more readable.

I'm only talking in the experience of JavaScript so take it with a grain of salt, but formatters (like Prettier) make a world of difference.
Not only do they kill any feedback that amounts to "hum actually moving this curly brace on the next line is Better" but they also remove some mental load. I've been using those for ~5-6 years and I can just type shit that I know is valid and it gets formatted automagically when I save, it's extremely good. And if it doesn't format it usually means I broke something lol

Another tool in your arsenal as a developer, IMO, is good access to docs. Of course search engines are good and in the Web world MDN is like, the #1 place for them. But having access to a quickly searchable (and offline) copy of those docs is also SUPER helpful. Tools like DevDocs (free, in browser) and Dash (macOS, paid) are worth the setup time (and the price when/if you can afford it) IMO.

One last thing that may be controversial but that I believe in: don't pay attention to things like "DRY (don't repeat yourself)" and other acronyms developers/programmers love to throw around in coding discussions. Focus on something that works and is readable/understandable.
I know it sounds obvious written like that but after a certain amount of time as a developer, you might be tempted to be like "oh i solved this problem in only X lines of code and no repetition" and you might be proud of yourself. And it might genuinely be good work!

But then 6 months pass and someone else (or yourself) will try to read what you wrote and won't be able to decipher it because your code is too clever for its own good.
To that effect:

• comment, comment. And ideally not the "// this function returns foo" type comment. If you're doing something that might sound unusual, explain why. Because your co-worker/friend/yourself that sees the code later might not know/remember the context, you'll never regret commenting.
• maybe the only "programmer acronym" I believe in is "KISS (Keep It Simple Stupid)". In most of the cases¹ there's not a huge performance gap between code that's simple if a bit "stupid" (unoptimized) and code that is very well optimized but undecipherable by anybody that's not the author. If you need to write something super optimized/complex, don't be the asshole and comment the shit out of it.

Speaking of code and optimization, as a new learner you might hear stuff like "do X instead of Y, it's more performant", sometimes without much explanation as to why. My advice is to usually not worry about it too much, and if you do measure your code's performance. Every language is different in that area but in JS-land for example, what is "performant code" changes over the years because the JS engines improve over time.
That said, a good advice for writing performant code is usually "do less work". It might sound stupid but it's a powerful advice.

1. Again, i'm talking with a JS/Web dev background, I'm sure you could debate the difference is wider in other languages/programming environments.