Why timetables fail and systems don't
A timetable is a prediction. It says: at 3pm on Thursday, past-you predicts that present-you will study organic chemistry for two hours. Any deviation — a cancelled bus, a bad night, a friend's crisis — invalidates the prediction, and once two blocks are missed the whole grid feels false and gets abandoned. This is why revision timetables mostly end up as beautiful documents nobody follows past week three.
A system makes no predictions. It says: whatever happens, material lands here, gets processed on Sunday, and the queue tells me what to review today. Missing a day means the queue is longer tomorrow — a consequence, not a collapse. Systems degrade; timetables shatter.
The four parts
| Part | Job | What it fails to be |
|---|---|---|
| Capture | One place everything lands: lecture notes, slides, recordings, photos of the board. | Not a filing system. Speed matters, organisation doesn't yet. |
| Process | A fixed slot where raw capture becomes questions and summaries. | Not "whenever I get round to it". This is the slot that dies first. |
| Review | A queue that decides today's work so you don't have to. | Not re-reading. A review is a retrieval attempt or it isn't one. |
| Repair | One weekly hour to catch up, triage and reset. | Not extra studying. Its entire purpose is absorbing failure. |
Capture: one inbox, no decisions
The commonest system failure is a beautiful folder structure that requires a decision at the moment of capture. In a lecture you have no attention to spare for deciding which folder a photo belongs in, so the photo stays in your camera roll and is lost.
- One destination. Slides, notes, recordings, photos of the whiteboard — all to the same place, named by date and module and nothing else.
- Capture must take under ten seconds or it won't happen during a lecture.
- Nothing gets read at capture time. Reading is processing and belongs in the processing slot.
- Photos count. A picture of a handwritten page is capture; it becomes usable later. Waiting until you have time to type it up means it never enters the system.
Process: the slot everything depends on
Processing is where raw material becomes studiable: a summary in your own words, and a set of questions you can be tested on later. It is the highest-value hour in the week and the first one people drop, because nothing breaks immediately when you skip it. Three skipped processing sessions is what a "bad week" actually consists of.
- 1
Fix the slot to an event, not a time
"After my last Wednesday lecture" survives a changed timetable; "Wednesday 4pm" doesn't. Anchoring a habit to an existing event rather than a clock is the single most reliable finding in habit formation.
- 2
Work from the capture inbox, oldest first
No choosing. The order is fixed, which removes the negotiation that kills sessions before they start.
- 3
For each item: one summary paragraph, in your own words
Closed source. If you can't write it without looking, that's the flag — you didn't understand the lecture, and you've now found out in week 3 rather than in the exam.
- 4
Then five to fifteen questions
Questions, not notes. A question is reusable forever; a note gets re-read once. This is the step that feeds the review queue.
- 5
Timebox it and accept a backlog
Ninety minutes, hard stop. If three lectures don't fit, two get done and one waits for the repair hour. A system that demands completeness gets abandoned the first week it isn't achievable.
Review: let the queue decide
The daily decision "what should I study today?" is expensive, and it is made at the worst possible moment — when you sit down, low on energy, facing everything at once. A review queue removes it. You open it, it tells you what is due, you do that, it empties, you stop.
This is the practical argument for spaced repetition that has nothing to do with the forgetting curve: it is the only common study tool that answers "what now?" without you thinking. The retention benefit is real and it is arguably the second reason to use one.
Repair: the hour that makes it survivable
Every system accumulates damage — a missed processing slot, a growing queue, a module you've quietly stopped touching. Without a scheduled repair, damage accumulates until the system feels irredeemable and gets abandoned wholesale, usually around week 8.
- Clear the capture inbox, even if that means summarising two lectures in ten minutes badly. Badly beats not at all.
- Look at the review queue's size. If it's growing week on week, you are making too many cards. Delete some — this is normal maintenance, not failure.
- Pick one module you're behind on and do one hour. One. Trying to fix everything is why people fix nothing.
- Write next week's three priorities on one line each, and nothing more elaborate than that.
What to do when you've already collapsed
If you're reading this in week 9 with nothing processed since week 4, do not build the system backwards. Start it from today, forwards, and treat the backlog as a separate triage problem — rank the missed material by exam likelihood and do the top three items in your repair hours over the coming weeks. Catching up when you're behind covers the triage; the important thing is that the forward-running system starts immediately rather than after the backlog is cleared, because that day never arrives.