Opinionated, yes. Arbitrary, no.

Software education has a strange habit: it ignores the science of learning while teaching the science of computing. Course design here started from the opposite direction. We read the memory and expertise literature first, then built the curriculum to match it. Four findings shaped almost everything.

1 · Testing yourself beats re-reading — so the exercises come first

In a widely cited 2006 experiment, Roediger and Karpicke had students either repeatedly study a text or repeatedly recall it from memory. A week later, the group that practiced recalling remembered substantially more than the group that re-read — even though re-reading felt more productive at the time. Psychologists call this the testing effect, and it has been replicated across ages, subjects, and decades. Dunlosky and colleagues’ 2013 review of ten study techniques rated practice testing among the most effective known, and re-reading among the least.

This is why DevModules is 243 exercises with short lessons attached, rather than long lessons with a quiz at the end. Watching someone code produces the comfortable illusion of learning; retrieving the syntax yourself, with the video closed, produces the real thing. Our lessons are deliberately shorter than the exercises they unlock.

2 · Spacing beats cramming — so the curriculum keeps circling back

Cepeda and colleagues’ 2006 meta-analysis of 254 studies found that spreading practice over time reliably beats massing it into one block, across essentially every kind of material tested. The forgetting-then-relearning cycle is not a bug in your memory; it is how durable memory gets built.

You’ll feel this in the curriculum’s structure. Closures appear in Part 1, return with async code in Part 3, and return again in the dedicated workshop. Part 5 makes you retrofit tests onto your Part 2 capstone — a spaced, effortful revisit disguised as a project. When an exercise feels like “didn’t we do this weeks ago?”, that timing is intentional.

3 · One-on-one feedback is the strongest lever we know — so humans review your code

In 1984, Benjamin Bloom published what he called the 2 Sigma Problem: students tutored one-to-one under mastery conditions performed about two standard deviations better than students in conventional classrooms — roughly, the average tutored student outperformed 98% of the comparison class. Bloom framed it as a challenge: find methods that get group instruction close to what tutoring achieves.

We can’t give every learner a full-time tutor, but we can put the tutoring where it compounds most: at the capstones. Every part ends with a working engineer reading your actual code and telling you, specifically, what a professional would change. Mastery matters here too — capstones pass when they’d survive a real team’s review, not when the calendar says the module is over.

4 · Expertise comes from deliberate practice — so the projects are designed to hurt a little

Ericsson, Krampe, and Tesch-Römer’s 1993 studies of expert performers found that what separates the best is not raw hours but deliberate practice: effortful work at the edge of your current ability, with immediate feedback, on tasks designed to fix specific weaknesses. Robert Bjork’s related work on “desirable difficulties” shows that conditions which make practice feel harder — spacing, variation, generation — often produce better long-term learning than conditions that feel smooth.

So our projects are specified like real tickets, edge cases included, pitched slightly beyond what the week’s lesson handed you. The productive struggle is the point. A curriculum that never lets you be confused is a curriculum that never lets you learn to debug — and debugging without fear is the actual job.

Where the opinions come in

The research explains our methods. Three choices are ours to defend:

• One language, all the way down. Cognitive load theory (Sweller, 1988) argues that working memory is the bottleneck in learning complex skills. Every additional language multiplies syntax, tooling, and mental models competing for that scarce capacity. JavaScript runs the browser, the server, and the tooling — one language is enough to reach production, so one language is what we teach.
• Fundamentals before frameworks. Frameworks are excellent compression of fundamentals you already have, and miserable substitutes for fundamentals you don’t. We teach the platform first so that frameworks become choices, not dependencies.
• Free to learn, paid to be mentored. The material costs nothing because gates in front of knowledge offend us. The humans cost money because their time is real. We think that’s the honest way to fund a school, and it’s written plainly in our Terms.

A curriculum is a bet about how people learn. We’d rather place ours on published evidence than on what makes the smoothest marketing video.

References

1. Roediger, H. L., & Karpicke, J. D. (2006). Test-enhanced learning: Taking memory tests improves long-term retention. Psychological Science, 17(3), 249–255.
2. Dunlosky, J., Rawson, K. A., Marsh, E. J., Nathan, M. J., & Willingham, D. T. (2013). Improving students’ learning with effective learning techniques. Psychological Science in the Public Interest, 14(1), 4–58.
3. Cepeda, N. J., Pashler, H., Vul, E., Wixted, J. T., & Rohrer, D. (2006). Distributed practice in verbal recall tasks: A review and quantitative synthesis. Psychological Bulletin, 132(3), 354–380.
4. Bloom, B. S. (1984). The 2 Sigma Problem: The search for methods of group instruction as effective as one-to-one tutoring. Educational Researcher, 13(6), 4–16.
5. Ericsson, K. A., Krampe, R. T., & Tesch-Römer, C. (1993). The role of deliberate practice in the acquisition of expert performance. Psychological Review, 100(3), 363–406.
6. Bjork, R. A. (1994). Memory and metamemory considerations in the training of human beings. In J. Metcalfe & A. Shimamura (Eds.), Metacognition: Knowing about knowing (pp. 185–205). MIT Press.
7. Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257–285.