Why one app, and not twelve exercises

A folder of disconnected exercises teaches you that programming is a series of puzzles somebody else already solved. Building one real thing over a term teaches you the actual job: deciding what it should do, discovering you were wrong, and changing it.

So the "curriculum" is a to-do list web application. It starts as a variable and a print statement. By the end it has a database, accounts, tests, and real users — and at no point did the student learn something whose purpose was "you'll need this later."

The last principle is the one that matters most: they use the app as their realto-do list, and keep a list of everything that annoys them about it. That list becomes the syllabus, and now they're the one setting it.

The framework

Merrill's First Principles, in practice

My clinical practice is built on Merrill's First Principles of Instruction. Here is what each one actually looks like on a Tuesday.

  1. Task-centered

    The entire curriculum is one artifact: a real application the student builds up step by step. No concept is ever taught "for later." Each one is introduced the moment the app needs it, and the task grows in complexity.

  2. Activation

    Every lesson opens with a warm-up that reviews the previous session by doing — not by me recapping it.

  3. Demonstration

    I introduce and play with the new tool using example data, while the student watches.

  4. Application

    The student practises a similar task while I watch. They type every line — never paste — and I coach by question, not by answer.

  5. Integration

    The student uses the app as their real to-do list, and keeps a running list of its annoyances and the features they wish it had. Those lists become the next lessons, which they now drive.

Merrill, M. D. (2002). First principles of instruction. Educational Technology Research and Development, 50(3), 43–59.https://doi.org/10.1007/BF02505024
Merrill, M. D. (2013). First principles of instruction: Identifying and designing effective, efficient, and engaging instruction. Pfeiffer.

The shape of a term

Eight weeks, one thing, getting harder

Each week the app gains a capability, and the student gains the concern that comes with it. The final assessment is a product with users — not a zip file that only runs on my laptop.

  1. Week 1A small logic exerciseCommand line. Variables, input, a decision.
  2. Week 2A browser interfaceThe thing becomes visible, and other people can use it.
  3. Week 3Persistent dataIt survives a refresh. Suddenly the data model matters.
  4. Week 4Authentication and permissionsWho are you, and what are you allowed to do? Two different questions.
  5. Week 5External API integrationRate limits, webhooks, data mapping, and failure handling — the glue work.
  6. Week 6Testing and observability"The code runs" is not "the feature works" is not "the UX is right."
  7. Week 7Deployment and user feedbackReal users. Real traffic. A rollback plan.
  8. Week 8Refactoring and postmortemWhat we would do differently, written down.

Evidence of judgement

The engineering journal

Every significant AI-assisted change gets five sentences. Not to create paperwork — to create a trail showing that a person, not a model, made the call.

  1. What did I ask for?
  2. What did the AI change?
  3. What did I verify myself?
  4. What could be wrong?
  5. Why did I accept or reject the change?

Assessment

What I actually grade

Notice what isn't on this list: how much code you produced. In a world where code is cheap, grading volume grades the wrong thing.

  • The quality of their requirements
  • Their ability to explain generated code
  • Test coverage, and test quality
  • Debugging method
  • Architectural trade-offs
  • Security awareness
  • Git and checkpoint discipline
  • Quality of user feedback
  • Their final engineering postmortem

Want to see it rather than read about it?

The playground has live, working versions of the lessons — the same ones my students build.

Open the playground →