Finished the courses but can't write code? What the research says to do

A post on Reddit's r/learnprogramming forum makes a plain complaint. Its writer had finished three courses and still could not build anything. What made me curious was the word finished. So my question is a simple one: what do course finishers lack?

The pattern has a name. Al Sweigart of Invent with Python calls it tutorial hell, the cycle of going through tutorial after tutorial without feeling able to write a program yourself.

Why does a finished course not mean you can code?

A guide on freeCodeCamp sums up the gap in one line: "Tutorials teach you how to code, but not how to build." Following along, in that guide's account, gives a false sense of mastery.

Two plain definitions help here. Recognition is knowing something when you see it. Recall is producing it with nothing in front of you. An empty file in an editor gives you nothing to recognize.

Does practicing recall beat seeing the material again? In a 2006 experiment by Roediger and Karpicke, one group of students took repeated tests on a text while another group restudied it. A week later, the tested group recalled 61 percent. The restudy group recalled 40 percent.

The tested students had also read the text far less.

The chart at the top of this page shows that one-week result. Look at the shorter grey bar. It belongs to the group that spent more time with the text.

A classroom study also favors the active side. In 2019, Deslauriers and colleagues compared active physics classes at Harvard with a passive lecture. In each case, the students in the active classroom scored higher on the test of learning, as The Science Breaker describes the results.

How much does doing beat watching?

Saying that doing beats watching is easy. Carnegie Mellon University researchers put a number on it and called it the doer effect. Their finding, carried by EurekAlert, is that the learning tied to each activity done was six times greater than for each video watched or page read.

That multiplier comes from Carnegie Mellon's own online courses, in its Open Learning Initiative and MOOC settings, so it describes learners in those courses and does not cover every coding tutorial online. In the drawing below, compare the two bar heights: the bar for each activity done stands six times taller than the bar for each video or page.

Sweigart sets a limit on the push toward doing. He calls "work on your own projects" oversimplified advice, because beginners still need handholds and guideposts. He also writes that small projects are better for beginners than large ones.

So the shift I suggest is gradual, from watching toward writing, with the tutorial kept close as a handhold.

What does a four-week plan look like?

The plan below is my own, built on the findings above. Each week asks for more writing from memory and less following. In the drawing, watch the grey tutorial band shrink as the teal own-code band grows.

The daily habits change first. I built them on the two contrasts above: following along versus building, from freeCodeCamp, and restudy versus testing, from Roediger and Karpicke. Typing along line by line becomes pausing before the instructor types and writing the next line yourself. Rewatching a confusing part becomes closing the video and rebuilding what you just saw. Only after that attempt do you open the original and compare.

1. In week one, retype code from memory. Take a short piece of code from a course you already finished. Read it, then close it and write it again in a blank file. Compare the two, note what you missed, and try that part again.
2. In week two, rebuild a tutorial project from a blank file. Choose one you completed. Keep the tutorial closed, open it only when stuck, and close it again once you are moving. The closed tutorial stays within reach as a handhold, which Sweigart says beginners still need.
3. In week three, start a small project of your own. freeCodeCamp offers a rule of thumb for size: a project you cannot start after about two hours of brainstorming is too advanced. If an idea fails that test, pick a smaller one.
4. In week four, extend that project and publish it. Add one feature you planned yourself, then put the project online. One line from the freeCodeCamp guide fits this week: "The goal at this stage wasn't to build something impressive, it was to build consistently."

None of the studies above tested a four-week coding plan, so this order applies their findings and has not been measured itself.

What should you build first, and when should you look things up?

For first projects, a difficulty rating gives a beginner more to go on than a bare list of ideas. One list on the bkhtdev Substack rates projects on a 1 to 5 scale. A number guessing game and a to-do list each get a 2, while a weather app gets a 3. Ratings vary from source to source, so this is one writer's scale. Its order still helps: the two projects rated 2 come before the weather app.

That makes the to-do list a fair pick for week three.

For the moment you get stuck, the freeCodeCamp guide sets out an order that begins with the error in front of you:

1. Read the error message in the console.
2. Copy the message and search it online.
3. Ask someone for help.
4. If there is no error but the logic is wrong, revert to the last version that worked.

The Harvard study had one more measure: how much the students felt they had learned. The active-class students scored higher, yet their feeling of learning was substantially lower than that of peers who sat through a passive lecture, The Science Breaker reports. The group that learned more felt it had learned less.

Those were physics students, not people learning to code.

Method note: the 61 and 40 percent figures are recall one week after study, from Psychological Science 17(3), pages 249 to 255, whose design gave final tests at 5 minutes, 2 days or 1 week; the six-times figure applies to Carnegie Mellon's online courses; the project ratings come from a single list.