Nire Bryce

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:

1. learn what a function is in your language, how it can be called upon anywhere in the code and it's position doesn't really matter. this is the first step. if you don't get how variables work you'll need that background too. there's guides everywhere. you don't need to memorize it, just be able to go back and look when you need to

2. web search for basic project structure for the language (usually "hello world" examples in the official docs have enough boilerplate. put it in a file.

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

4. web search how to do the first smaller piece you found in the first step. every time you find something you don't understand, web search how to use that thing.

5. learn how to have it emit lines of text (print, console.log in JavaScript, etc) and put "starting <thing>" at the start of each major action, and "ending <thing>" at the end. there's better methods later but this will teach you how things flow from one to the other

6. you now know how the language fits together. each concept you don't understand, web search it and take some notes. functions, variables, classes, objects, etc.

7. do it again for the next steps, repeat until project done and start another.

8. 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.

other random advice:

if you feel like you're throwing yourself at a brick wall and making no progress, that's because you're throwing yourself at a brick wall and making no progress. it's a waste of energy. Learn to identify this early. When it happens you need to take a relaxing walk or play video games or take a nap or play with your dog or whatever. the solution will come to you, or at least some synthesis, enough to get you to the next step. for more on this, read The Programmer's Brain, which is a better book than Thinking, Fast and Slow but summaries and YouTube about Thinking, Fast and Slow will give you the gist. you really need to understand this one.

when you read a book, read it through first very fast, just under a skim. Then read the book again for real, knowing how things fit together, pacing, and what parts you couldn't understand. you'll learn much faster from books this way. you don't have to take notes, but ideally do the exercises. type them out, copy and paste doesn't build the neural pathways.

know that typing things out is low-cost. most of your time coding is spent thinking, moving things around, and looking things up. naming your variable "listOfWords" instead of "L" not only helps you and others when you come back to edit it, but it helps build the neural pathways -- the operations you do on that list of words will be associated with, lists of words.

if you choose JavaScript, you can learn the basics from FreeCodeCamp, but in my opinion that's really slow compared to the above. Being able to write code without web search is a skill, but right now you want to learn the thought process and the shape of the language before trying to memorize much. whenever you feel like you don't know enough about something, read it and take notes. not detailed notes, but enough that every time you do a lookup on that thing you can add to them. Focus more on reading than writing through.

learnXinYminutes.com is also a useful resource, which gives you a very condensed, rapid fire glossary of data types and basic technique for any given language. It's not useful for learning straight up, but it's very useful as a pocket reference so to speak.

you'll learn more from reading code than reading how-tos once you understand the language basics. You don't need to memorize the more advanced functions, those will come faster through use. Contrive some problems just to use the technique on to learn it, and save those "toy programs", because one of the fastest ways to learn a new language, is to run yourself through all of those again but with the tools of the new language

understand the difference between builtins, the standard library, and imported libraries. the difference between modules, packages, libraries, and executables. interpreted vs complied. for python you'll want to learn how to use virtual environments.

ask questions to no one in particular. learn in public. join the community forum and chat and ask questions there. you learn much slower on your own

coding is a creative discipline. it's also a constantly learning discipline.

It'll always feel difficult when you're pushing yourself, sometimes it's good to go back to the basics and cement them, which is what I use FreeCodeCamp and rustlings etc to do, since it's easy to do on my ipad when I'm out and about and let's me drill stuff I'm shaky on.

repl.it is your friend for mobile editing (it's absurd no one has a good edit bar for software keyboards other than this). for desktop I would recommend new people try either intellij IDEA, or one of the specific ones from them for your language, pycharm for example. VSCode is good once you understand what your tastes are.

people will say to learn vim, and it's true, having unfree software be load bearing is an issue. but you're working on learning to code, not learning your editor. do that when you've got coding down.

read How to Think Like a Computer Programmer python edition. you can ignore the python tutorial stitched within it, and just replace the other parts with your language. you're not looking to do the exercises with this book, you're looking for mindset. know that this is the start, not the end, though the book is a bit aspirational.

most people writing blogposts are learning it as they go, not writing from a place of deep knowledge.

most advice blogposts, or blogposts about what programmers should do, are aspirational. ignore their diktat and extract the useful pieces, but don't hold yourself to their standard. you'll get there, now is not the time.

until you're very comfortable with your language, don't read any books published before 2010 unless you're learning c/c++, you need to know what's changed since then first.

don't worry about functional or object oriented programming right now, most people talking about them as distinct concepts with rigid feature sets dont really know what they're talking about. You'll want parts from both, they're stronger together, and seeing them as arbitrary borders will only hinder you. use the labels when you want to learn more, not when you're looking at the shape of the terrain.

don't learn Haskell as a first language unless you've got a university theoretical math background. Learning the names for things in that language while also learning the language will set you back. Learn it later, as a second or third. Knowing basic and advanced programming concepts elsewhere will aid learning Haskell, learning Haskell will not help you learn other languages this early (because they use very different words and concepts to teach it thanks, in part, to the artificial borders mentioned above)

if this advice seems like a brutal learning cliff, you're overthinking things. you don't need to know the deep language features until you need to actually use them, and you'll learn them from reading others' code once you're there. The important part of programming is this breaking impossible problems down into smaller and smaller pieces until you can implement each one and stitch together into a whole. That's it. Everything else flows from that. So work on that first. once you're craving to know more about the language, web search "<language> idiomatic style" to learn agreed upon best practices, and go read whatever The Book on your language is.

books: for new people, i don't recommend language specific books. I don't even really recommend programming books (the rust one is good, but written for people who are already programmers). I do recommend:

• The Structure of Scientific Revolutions - this book has some problems when looked at from the present, but there was less information then. The core ideas are still important to have in your inventory.
• The Programmer's Brain - intermediate level, will help you studies and how you think about code, learning how to rely less on "active-working-memory" in your brain by writing things down, but also how to compress concepts to better fit in working memory
• probably more but I'm out of brain for this today

@eramdam reminded me that I forgot to talk about documentation. Often the web documentation is written for developers and so full of all sorts of things you don't know how to read yet. Manual pages and built-in documentation for your language may be easier. You can get documentation in the right margin of a VSCode editor by using this addon https://marketplace.visualstudio.com/items?itemName=NonSpicyBurrito.hoverlens and many other IDEs and editors have similar, or at least documentation panes you can open, so you can see the documentation for things you select at-a-glance. The official documentation is a source of truth, whereas everyone else on the internet can be wrong.

further works:
@eramdam going into detail about some of this