Learn by Doing: Why Practice Beats Passive Study

Following a worked example and producing a solution are different tasks. Practical learning gives you a place to try the decision, inspect the result and explain what changed. This guide covers research on active learning and retrieval, its limits and a study routine you can use. It explains the teaching choices behind Code Nexus and our AI engineering guides.

The feeling of understanding is not the same as learning

When you reread a chapter or watch a clear explanation, the material becomes familiar. Familiarity feels like knowledge. But recognising an idea when you see it is a different skill from producing it when you need it, and engineering work is almost always about producing.

This is one of the most consistent findings in the science of learning: what feels easy in the moment is often not what builds lasting skill, and what feels harder, such as struggling to recall something or getting a task wrong first, tends to build more.

What the research shows

Two bodies of evidence are worth knowing. We describe what each did and did not test, because it is easy to overstate research in either direction.

Active learning in the classroom

In 2014, Scott Freeman and colleagues published a meta-analysis in the Proceedings of the National Academy of Sciences. They pooled results from 225 studies that compared undergraduate science, technology, engineering and mathematics (STEM) courses taught by traditional lecturing with courses that used active learning, where students work on problems, discuss and apply ideas during class.

The findings:

• On average, exam and concept-inventory performance was 0.47 standard deviations higher under active learning.
• Students in traditional lecture courses were more likely to fail: the odds ratio for failing was 1.95, and failure rates under lecturing were 55% higher than under active learning.
• The authors noted that the size of the exam gain would raise average grades by about half a letter.

What this does not show. These were university STEM classes, not adult learners working on their own, and "active learning" covered many different methods. It does not prove that any particular practical technique beats every other. What it does show, across a large number of studies, is that getting students to do something with the material improves results compared with having them listen.

Retrieval practice

In 2006, Henry Roediger and Jeffrey Karpicke published a study in Psychological Science on what is now called the testing effect. Students studied prose passages and then either restudied them or took recall tests without feedback. When they were tested five minutes later, the students who had restudied did better. But on tests given after a delay, prior testing produced substantially greater retention than restudying, even though restudying made students feel more confident about what they would remember.

What this does not show. The materials were text passages, not programming tasks, and the participants were students in a lab. It supports the idea that pulling information out of memory strengthens it, and it warns that your own sense of how well you have learned can be misleading. It does not measure how a coding skill develops.

Putting the two together

Neither study is about learning to code. But together they point the same way: active use beats passive exposure, and effortful recall beats rereading. For technical skills, where the goal is performance, that is a strong reason to design learning around doing.

Theory and practice are partners

"Learn by doing" is sometimes heard as "skip the theory." That is a mistake, and the research does not say it. What it says is about the order and balance.

• Theory first, then practice leaves people holding ideas they have never used. They remember little, because nothing hooked the idea to a problem.
• Practice with no theory produces people who can follow a recipe and cannot debug it. When the recipe breaks, they have no model of why.
• Practice with just-in-time theory works best. You meet a problem, feel why you need an idea, learn it in a few minutes, and use it straight away. Then you step back and explain why it worked.

In short, theory gives you the map and practice gives you the ability to walk it.

How to study practically

Here is a routine that applies the research. It works for Python, Linux, cloud services and AI alike.

1. Start with a task, not a topic. "Filter this list of comments" teaches more than "chapter 4: loops".
2. Predict before you run. Write down what you think will happen. Your prediction is a small retrieval attempt, and the gap between it and the result is the lesson.
3. Change one thing at a time. When something breaks, you will know why.
4. Get feedback fast. The sooner you learn whether you were right, the less time you spend practising a mistake.
5. Return to old material on a schedule. A quick attempt to recall something a few days later does more than an hour of rereading it.
6. Explain it in your own words. If you cannot explain why it worked, you have found the next thing to study.
7. Finish something. Small completed projects teach the parts tutorials skip: setup, errors, and tidying up.

The trap: tutorials that feel like practice

Following a tutorial step by step can feel like doing. But if you copy every line and never decide anything, you have practised typing, not problem solving. This is often called tutorial hell: hours of progress that vanish the moment you face a blank file.

A quick test: close the tutorial and rebuild it from memory. Where you get stuck is exactly where you were only following along. That is the useful place to spend your time.

Why we also use stories

At Code Nexus, tasks come wrapped in a story: you are a new engineer at a fictional company, and each episode brings a problem someone on the team needs solved. That is a design choice, and we want to be clear that the research above is about active learning and retrieval, not about narrative. Our reasons for using stories are practical. A realistic situation gives a task a reason to exist, it shows you the messy context real work comes in, and it makes it easier to remember why you did something, not only what you typed.

How Code Nexus builds practice into every episode

• Every episode is a task you complete. You write code in the browser, run commands in a simulated terminal where the task needs one, or make an engineering decision and justify it.
• Your work is checked as you go. You get feedback on whether you got it right, so mistakes do not go unnoticed.
• Short checks bring ideas back. Recall questions revisit earlier material so you retrieve it instead of rereading it.
• Checkpoints line up with real certifications. Season checkpoints follow the syllabus of exams like PCEP, PCAP and Linux Essentials, so you can measure progress against an independent standard.

The full route, and where each certification fits, is in the certification roadmap.

A note on limits

Practical learning is not magic. It takes longer per session than watching and feels harder, and it only works when the tasks are the right size: hard enough to make you think, and not so hard that you give up. Good design chooses the next task carefully. If you are learning alone, err on the side of smaller steps and finish each one.

Go deeper

• Theory vs practical learning: what three well-known studies say about balance and guidance.
• Story-driven learning: what the research on narrative and memory does and does not show.
• Tutorial hell: why following along feels like progress, and a way out.
• Learn Python by building: a ladder of projects from first script to classes.
• Codecademy alternative: moving beyond browser syntax drills into workplace engineering.
• Udemy alternative: why active practice beats passive video courses for technical skill.

Start with one task

You do not need a plan to begin. Pick one small problem and solve it with your hands. If you would like the problems chosen and checked for you, create a free account and open Episode 1.