The direct answer

Learn one concept, then write one small program that uses it — from memory, not by copying the tutorial. Mix problem types once you know the basics, explain each line out loud when you get stuck, and rebuild old programs from scratch every few weeks.

Coding has a specific trap: you can spend hours “learning to code” without writing a single line. Tutorials feel productive — you follow along, the code works, and you feel like you understand it. Then you open a blank file and cannot start. That is not a talent problem, it is a practice problem: you practised watching, and the exam asks you to write.

The system in short

  1. One concept, one small program. Never finish a lesson without writing code.
  2. Write the code from memory before you look at the solution.
  3. Mix problem types once you know the basics of each one.
  4. Explain each line out loud when you get stuck — most bugs are found in the explaining.
  5. Rebuild an old program from scratch every week, without looking at the original.
  6. Keep a one-page list of the errors you keep making, and check it before you start.

Step 1: One concept, one small program

A lesson is not finished when the video ends. It is finished when you have written a small program that uses the concept on your own — 20 to 40 lines.

The program must be yours, not the tutorial’s. Change the data, the problem, the output: if the tutorial sorted numbers, sort names; if it counted words in a sentence, count them in a paragraph from a file.

This is practice testing, applied to coding. In a 2013 review, Dunlosky and colleagues rated practice testing one of only two high-utility techniques, alongside distributed practice; watching a tutorial and re-reading your notes are the coding equivalents of re-reading — rated low.

Set a rule: 20 minutes of tutorial, then 40 minutes of writing. If the tutorial is an hour long, split it — watch one section, write the code, then watch the next.

For fitting a skill around your course, the study system for skill learning alongside a degree covers the weekly shape of that.

Step 2: Write from memory before you look at the solution

When a tutorial or exercise gives you a problem, try it before you look at the answer. Open a blank file, write what you can, and only look at the solution when you are stuck for more than 10 minutes.

This feels slow. It is slow. It is also the only way to find out what you actually know. Reading a solution feels like understanding it because it is fluent.

Rowland’s 2014 meta-analysis of 61 studies found testing beat restudying by a medium amount (g = 0.50), and 81% of the comparisons showed a benefit for testing. The advantage grows with time: on an immediate test, restudying often wins; after a delay, testing wins. Feedback mattered: with feedback the effect was larger (g = 0.73) than without it (g = 0.39).

The 10-minute rule matters: staring at a blank file for an hour is frustration, not practice. Stuck for 10 minutes, look at the solution, understand one line at a time, close it, and write it yourself.

Step 3: Mix problem types once you know the basics

Practising one kind of problem for an hour feels good — you get faster at string problems, and by the end you feel like you know strings. Then a real task mixes strings, loops, and functions together, and you have to decide which tool to use.

Mixing problem types is called interleaving. Rohrer and Taylor found in 2007 that students who practised four kinds of maths problems mixed together scored 63% on a test a week later, against 20% for students who practised them blocked by type — even though the blocked group did far better during practice, 89% against 60%. Fourth-graders showed the same pattern: 77% against 38%.

The rule for coding: learn a concept blocked first, then mix it. When a concept is brand new, practise it on its own until you can write the basic version without looking. Then mix it with the concepts you already know.

A practical mix: a 40-minute session with 4 problems — one on loops, one on functions, one on lists, one that combines all three — in a shuffled order. If you reach for the wrong tool, that is the most useful kind of mistake.

Step 4: Explain each line out loud when you get stuck

When code does not work, the usual response is to stare at it, change something at random, and run it again. That works sometimes, and it teaches nothing. The better response is to explain the code out loud.

Most bugs are found in the explaining. You say “this loop goes through every name in the list”, and halfway through the sentence you realise the loop goes through every character in the first name instead.

Self-explanation has real support. In a 1989 study, Chi and colleagues watched eight physics students think aloud while studying worked examples: the best solvers gave about 15 explanations per example; the weakest gave fewer than 3, and scored 46% correct against 82%. Small, so it shows a pattern rather than proving a rule — but a 2018 meta-analysis across 64 reports found a moderate average benefit (g = 0.55).

Do this before you ask for help or search for the answer. Five minutes of explaining out loud, then ask — the question will be better, and the answer will make more sense.

Step 5: Rebuild an old program from scratch every week

This is the spaced review for coding. Pick a program you wrote two or three weeks ago. Delete it — or move it to a folder you will not open — and write it again from a blank file.

The comparison is the review. The parts you wrote easily are learned; the parts you had to think hard about, or got wrong, are what you study next.

One rebuild a week is enough. Pick a program that took you an hour the first time; the rebuild should take 30 to 40 minutes. If it takes longer, the concept has not stuck yet, and it goes back into your practice list.

Keep a one-page list of the errors you keep making — the off-by-one loop, the missing return, the variable you forgot to initialise. Check it before you start a session.

A worked example: a Tuesday evening after classes

You have a 7pm to 10pm evening and you are learning Python, currently on functions and lists.

7:00–7:20 — Tutorial: One 20-minute lesson on list comprehensions. 7:20–8:00 — Write: Three small programs using list comprehensions, from a blank file: square a list of numbers, filter names longer than 5 letters, build a list of even numbers from 1 to 50. 8:10–8:50 — Mixed problems: Four problems, shuffled: one on loops, one on functions, one on lists, one that combines all three. Forty minutes, no peeking until stuck for 10 minutes. 8:50–9:10 — Debug by explaining: One program from the mixed set has a bug. Explain it out loud, line by line, until you find it. 9:10–9:40 — Rebuild: Last week’s program — the word counter — from a blank file, without looking at the original. Compare the two versions. 9:40–10:00 — Error list: Check your error list. Add today’s new error, cross off the one you have not made in a week.

Three hours, one new concept learned by writing, four mixed problems, one bug found by explaining, one old program rebuilt, and an error list that says what to watch for tomorrow.

Time Block What you do
7:00–7:20 Tutorial One 20-minute lesson, once
7:20–8:00 Write Three small programs, blank file
8:10–8:50 Mixed problems Four problems, shuffled types
8:50–9:10 Debug Explain out loud, line by line
9:10–9:40 Rebuild Last week’s program from scratch
9:40–10:00 Error list Add today’s error, cross off fixed ones

Diagram: The coding study system in five steps

When it goes wrong

You have watched 10 hours of tutorials and written nothing. Watching is not learning to code. Stop the tutorial and write one small program from a blank file.

You copy the tutorial code and it works, but you cannot write it alone. You practised typing, not coding. Close the tutorial and write the same program with different data.

You practise one problem type for an hour and feel confident, then a mixed task falls apart. That is the interleaving gap. Blocked practice feels good because you never have to choose which tool to use. Mix the problem types once you know the basics.

You change three things at once when your code breaks, and now you do not know which change fixed it. Change one thing at a time. Explain the code out loud first, find the one line that is wrong, fix it, and run it again.

Diagram: Watching tutorials vs writing code

Weekly review checklist

Copy this list and use it each week:

  1. Did I write code from a blank file every day, not just watch tutorials?
  2. Did I try each problem before looking at the solution, then write it again?
  3. Did I mix problem types in at least two sessions?
  4. Did I explain my code out loud when I got stuck, before asking for help?
  5. Did I rebuild one old program from scratch, without looking?
  6. Is my error list one page, and did I check it before starting?
  7. What one change will I make next week: less watching, more mixing, or more rebuilds?

Downloadable infographic spec: one vertical image, title “The coding study system”, with the five steps — one concept one program, write from memory first, mix problem types, explain each line out loud, rebuild an old program weekly — and the session rule — 20 minutes tutorial, 40 minutes writing — in Thynq cream, Cloud Purple, Dark Purple and pink, with the cloud mascot.

What this system is not

It is not a promise of a job or a grade, and not a claim that this is the only way to learn to code. It is a practical system built on the two techniques researchers rated highest — testing yourself and spacing study out — plus mixing and self-explanation, applied to writing code from a blank file.

Sources

  • Dunlosky, J., et al. (2013). Improving students’ learning with effective learning techniques. Psychological Science in the Public Interest, 14(1), 4-58. Only practice testing and distributed practice rated high utility; rereading rated low.
  • Rowland, C. A. (2014). The effect of testing versus restudy on retention. Psychological Bulletin, 140(6), 1432-1463. Testing beat restudy (g = 0.50) in 81% of comparisons; feedback raised the effect (g = 0.73 with, 0.39 without); the advantage grows with the delay.
  • Rohrer, D. & Taylor, K. (2007). The shuffling of mathematics problems improves learning. Instructional Science, 35(6), 481-498. Interleaved 63% a week later vs blocked 20%, though blocked did better during practice (89% vs 60%).
  • Taylor, K. & Rohrer, D. (2010). The effects of interleaved practice. Applied Cognitive Psychology, 24, 837-848. Fourth-graders 77% interleaved vs 38% blocked a day later.
  • Chi, M. T. H., et al. (1989). Self-explanations. Cognitive Science, 13(2), 145-182. Best solvers gave 15.3 explanations per example against 2.8 for the weakest, in a small study of 8 students.
  • Bisra, K., et al. (2018). Inducing self-explanation: a meta-analysis. Educational Psychology Review, 30(3), 703-725. Moderate average benefit (g = 0.55) across 64 reports.
  • Rubinstein, J. S., Meyer, D. E. & Evans, J. E. (2001). Executive control of cognitive processes in task switching. Journal of Experimental Psychology: Human Perception and Performance, 27(4), 763-797. Mean switch costs 614 to 1,096 milliseconds per switch, growing with complexity.

For the full system behind this one, start with how to build a study system that fits your life, and if you are fitting coding around a degree, the study system for skill learning alongside a degree covers the weekly shape of that. If you are starting from zero, how to learn to code online covers choosing a first course.

Questions

How much should I watch tutorials vs write code?

Watch for 20 minutes, then write code for 40. A tutorial you watch without writing is a lecture you will forget. The code you write from memory is the part that stays.

What do I do when my code does not work?

Read the error message first, then explain the code out loud line by line. Most bugs are found in the explaining, not in the staring. Change one thing at a time.

How do I stop forgetting what I learned last month?

Rebuild it from memory. Take a program you wrote last month, delete it, and write it again without looking. Then check it against the original. That is a spaced review for code.

Should I learn one language deeply or several at once?

One language deeply first. Mixing languages before you know one properly means you never learn the ideas underneath. Once you can build in one language, the second one is mostly new words for old ideas.