There is a gap between “I understand loops” and “I can use loops without looking anything up”. Practice is what closes it, and not all practice closes it equally fast.
The tutorial trap#
Following a tutorial is pleasant. You always know the next step, nothing breaks for long, and at the end there is a working program.
The problem is that the hard part — deciding what to do next — was done for you. That decision is the skill. Watching someone else make it builds recognition, not ability, which is why people can follow a five-hour course and still stare at an empty file afterwards.
Tutorials are useful for seeing how something is done. They are not practice.
Five ways to practise, worst to best#
5. Watching and typing along#
Low value on its own. Worth it once for a brand-new concept, to see the shape of it.
4. Coding puzzles#
Better — you have to think. But puzzle problems are self-contained and pre-specified, which is not what real programming feels like. Useful for interview practice and for drilling a specific weakness.
3. Rebuilding from memory#
Follow a tutorial, close it, wait a day, then build the same thing from scratch. You will get stuck in exactly the places you did not really understand — which is the point. Cheap and surprisingly effective.
2. Modifying something that works#
Take a working project and change the requirements. Turn the quiz app into a flashcard app. Make the to-do list a habit tracker with streaks.
You get a working base to learn from and real decisions to make.
1. Building your own thing#
The most valuable and the most uncomfortable. Nobody tells you what to do next, so you have to plan, get stuck, search, and decide. That discomfort is precisely the skill developing.
Keep it small — see beginner programming projects.
A week that works around a job#
Five hours a week, roughly:
- Monday (1h) — learn one new concept. Read, try the examples.
- Tuesday (1h) — use that concept in something tiny of your own.
- Wednesday (1h) — work on your current project.
- Thursday (1h) — keep going, or debug what broke.
- Friday (1h) — tidy up, commit, write down what you learned.
Roughly one part learning to three parts building. If you are learning more than you are building, adjust.
Deliberate practice on your weak spots#
Keep a note of every time you look something up. After two weeks, patterns appear — maybe it is always list slicing, or always this, or always async. Those are your weak spots, and thirty focused minutes on one is worth more than three hours of general practice.
Signs it is working#
- You guess the cause of an error before reading past the first line
- You look things up less for basics and more for specifics
- You can read code you wrote last month and follow it
- You start noticing what is bad about your own code
- Getting stuck feels routine rather than alarming
Signs it is not#
- You have finished several courses and cannot start a blank file
- You copy solutions without understanding them
- You have started six projects and finished none
- You spend more time choosing tools than using them
None of these mean you cannot do it. They mean the balance is off — usually too much input, not enough output.
Questions people ask#
How many hours a day should I practise?
An hour most days beats seven hours on a Sunday. Consistency wins because programming builds on itself and long gaps mean re-learning.
Should I take notes?
Write down what you got stuck on, not what you learned. The stuck list is a precise map of what to practise next.
Is it normal to forget syntax constantly?
Completely. Professionals look things up daily. What you should remember is the shape of the solution — the exact method name is what documentation is for.
Should I learn in public?
It helps some people a lot: explaining forces clarity, and a public record is motivating. Others find it a distraction. Try it for a fortnight and see.
Where to go next#
- Beginner programming projects
- How to build a portfolio
- Programming books — which kinds are worth your time
- How long does it take to learn programming?