The order I learned in
The path I took, and how I knew when to move on to the next step.
⏱ About 2 min read
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.