The order I learned in
The path I took, and how I knew when to move on to the next step.
The rule I came away with
Learn just enough to build one thing that runs, then go back and dig deeper.
I tried it the other way round: finish the theory first, build later. I quit in month four, with nothing to show for it.
The order I suggest
| Stage | What to learn | When you can move on |
|---|---|---|
| 1 | The syntax of one language + a few basic algorithms | You can write a ~100-line program on your own |
| 2 | Git, the command line, how to read documentation | A strange error stops making you panic |
| 3 | One real project, start to finish | You have something that runs for other people |
| 4 | Tests, design, optimisation | Someone else can change your code |
The column that matters is the right-hand one. Don't change stage on a schedule — change on a signal.
The tutorial trap
Watching a tutorial and typing along feels almost exactly like understanding. That feeling disappears the moment you sit in front of an empty file.
How I got out of it: after each tutorial, rebuild a different variant of it without looking back. Change the requirements a little. The part where you get stuck and have to work it out yourself is the part where the learning happens.
Progress is kept in your browser and sent nowhere.
Read next
Programming
Introduction
Why I opened this section, and what will go into it.
⏱ About 2 min read
Programming
How to think about programming
What decided how far I got — and it was not the language I picked.
⏱ About 2 min read
English
Introduction
Who I am, what my learning path looked like, and why this blog exists.
⏱ About 5 min read
English
How I taught myself English
The whole route I took, start to finish.
⏱ About 4 min read