Working memory is small, and it does not expand. That is the founding observation of cognitive load theory, and everything on this page follows from it. When a project asks you to hold creative judgement, software navigation, technical settings, file management and a deadline in your head at once, the first thing to fail is not your talent — it's your margin.
Professionals are not people who push harder against the ceiling. They are people who engineer their signal chain so they rarely hit it. That's a learnable skill, my courses deliberately train it, and it will matter to your career at least as much as anything you build in them.
Three kinds of load
Cognitive load theory splits mental effort into three kinds. Learning to tell them apart in the middle of a work session is the whole trick.
| Load | What it is | Your move |
|---|---|---|
| Intrinsic the task itself | The necessary complexity of the work — editing a scene while holding continuity, pacing and intent; a shoulder that has to deform believably. It can't be removed, only shrunk by prior knowledge. | Practice until parts of it are automatic. Whatever becomes automatic stops costing working memory. |
| Extraneous the friction | Effort the work never asked for — hunting for the brief, decoding a vague spec, un-versioned files, redoing a lost export, guessing what the rubric wants. Teaches nothing, clips you anyway. | Kill it with systems: naming conventions, one folder template, one home per project. |
| Germane the learning | The productive effort that builds durable skill — comparing two versions, explaining why the cut works, applying the principle to the next piece. | Protect it. This is the load worth paying for, and it's exactly what friction crowds out first. |
The goal is never an easy course. The goal is to spend your ceiling on the work that compounds.
My courses are built around your headroom
Several things about my courses that can read as ritual are load engineering, and you'll get more out of them knowing why they're there.
- The early weeks are hands-only because chunking is real. A skill you've practised until it's automatic stops occupying working memory — which is what frees you, later, to think about the work instead of the tool. The unaided practical exam isn't a hazing ritual; it's a headroom reading. It measures what you can do without looking anything up.
- The recurring structures are friction removal. The same session rhythm every week, one submission convention, version control from Week 1, the same crit format: you learn each format once, and from then on your attention goes to the work. That's extraneous load being deleted on your behalf.
- Demos are segmented and models are narrated — short named steps, worked examples with the decisions explained — because research is unambiguous that learners absorb more, with less effort, when complexity arrives in pieces they can process.
- The process log is external memory. Paper is cheap; working memory isn't. A decision written down is a decision you can stop carrying. Once the agents arrive, the same habit becomes your AI development log — and it's graded because it's the skill.
The AI part: load doesn't drop — it converts
It is tempting to expect AI tools to lower the effort. They won't. They convert it. Working by hand, the cost of your work is generation — slow, but you understand every asset because you made it. Working with agents, the cost moves to verification and orchestration: reviewing work you didn't do, holding your intent steady across ten fast iterations, deciding what to keep. Generation is bounded by your hands. Supervision is bounded by your judgement — and an agent can outrun it.
That's why my courses call the agent a fast but overconfident assistant. Every output you accept without verifying is borrowed load — it comes back with interest at crit, in the exam room, or in the build that won't package the night before the showcase.
I build production software with these exact agents, daily. The honest lesson from that work: once generation is nearly free, review throughput becomes the constraint. A person who can generate ten times more but verify none of it has gained nothing but risk.
And the career part, plainly: everyone you'll compete with will have the same agents you do. The day everyone can generate, production stops being the scarce skill. What stays scarce is a head that stays clear while directing ten times the output — scoping, verifying, explaining. In a tighter market that difference is the hire. Your AI development log isn't paperwork; it's the portfolio artifact that proves you can supervise the machine accountably.
Four courses, one ceiling
You're carrying each of your courses alongside three others, plus a life. The ceiling doesn't care that the loads come from different syllabi — it's one working memory. Six moves that protect it:
- Batch, don't shred
Context-switching is the most expensive thing you do all week. One deep block per course beats four shredded evenings, because every switch pays a re-loading tax and leaves half-finished thoughts resident in memory.
- Write it down
A capture list is external memory: ideas, due dates, “fix this later.” If it's written, it can stop occupying you. The open loop you're trying to remember is the one eating your margin during the work.
- Close loops
End every session with one line of state: “next — reweight the shoulder.” Future-you boots in seconds instead of twenty minutes. Same rule as the agent log: write the state down before you move on.
- One home per course
Every course gets one predictable place for briefs, files and deadlines. Five minutes spent hunting is pure extraneous load; spend the five minutes once, on the folder template.
- Scope is load management
In my courses, ambition is graded alongside finish for a reason. Cutting scope early isn't defeat — it's the production judgement studios actually pay for, and it's how a final ships polished instead of ambitious and broken.
- Audit weekly
Ten minutes, all four courses plus life, everything on one page. Tag each item: generate, verify, or coordinate. You cannot route a load you've never seen written down — and most people have never once seen theirs.
- Does it read without me explaining it?
- Can I explain every part of it at crit?
- Is it in the required format, named the required way?
- Did I write down the one thing I learned?
If all four are yes, submit and close the loop.
Where this comes from
Cognitive load theory begins with John Sweller's work in the 1980s and is one of the most replicated bodies of research in instructional design. If you want the sources behind this page:
- Sweller — Cognitive load theory, educational research, and instructional design (Instructional Science)
- van Gog et al. — advances on worked examples, animations, and load measurement (Educational Psychology Review)
- NSW CESE — Cognitive load theory: research that teachers really need to understand (the best short practical guide)
- Spanjers et al. — segmentation of worked examples (why the demos come in named pieces)
- Every Learner Everywhere — cognitive load and equity in higher ed
The application to media production, four-course semesters and AI supervision is mine. Argue with me about it at crit.