Spaced Repetition for Programming

You already write or study code, and pieces of it still disappear: a flag from last quarter, a distinction you understood on Friday, the fix that made sense only while the file was open. Spaced repetition for programming is the decision about which of those pieces gets a scheduled review, and what you do on the day it returns.

Give each piece one of three jobs.

Look up rare exact syntax. Practice writing, debugging, and problem-solving in the editor. Schedule a retrieval only for a stable idea you keep losing and expect to need again.

That scheduled set is wider than a glossary and narrower than a review date on every note you keep. It holds distinctions, conventions, pattern logic, gotchas, and a prompt to re-explain or re-apply a concept a real project already made important. The semicolon on every line stays unscheduled. So does a function you will call once.

A standard description of learning to program mixes notation, patterns, and the work of planning and debugging. You meet them together. When a scheduled item comes due, produce it before you reopen the source: re-explain the distinction, or apply the rule to a case you have not stored as a script. Then check. The lookup and the editor work stay on their own jobs.

Three jobs, not one memory problem

The lookup row is exact syntax you can read while the script is open. The practice row is a defect: naming it does not make the test pass. The schedule row is a stable idea you already understand, keep losing, and expect to meet again.

What belongs on a schedule

Schedule a stable idea you have already lost and expect to meet again.

Distinctions. Debounce and throttle. Or git reset --soft, which moves HEAD and leaves the index and working tree, against git reset --hard, which moves HEAD and resets both the index and the working tree to that commit. If you wanted --soft and run --hard, uncommitted changes in tracked files are discarded.

Conventions. A rule the codebase already repeats. This service returns errors as values at the boundary, and thrown exceptions stay inside the module. A new file is where that rule disappears. A preference you used in one script can stay in that script.

Pattern logic. An optimistic lock writes the row only when the version you read is still the version stored. Re-explain that sentence. Write the statement for one table when the task is open.

Gotchas. Array.prototype.sort sorts in place, and with no compare function it compares elements as strings. You can know that and still ship [10, 2, 1].sort() on a list of numbers. Review the gotcha. Cover the call site with a test.

A prompt to re-explain or re-apply. "When is this isolation level enough, and when does the update need a row lock?" The prompt is what comes due. You produce the explanation on the page, then check it. You are reviewing a decision you expect to make again.

Leave out the semicolon you type on every line. Leave out a function you will use once.

A card, a page, and a problem are different units

Which object you schedule is the same format choice as notes versus flashcards. A connected explanation can stay a page. An independently testable item can be a card. For code, you schedule at that grain.

Keep debounce versus throttle on one page when the point is the condition that picks each. Split a token onto a card when you truly want it exact and it stands alone: git push --force-with-lease, if a plain --force is the mistake you keep approaching. A live problem stays practice in the editor. A scheduler can decide when that problem returns. The solving still happens in the editor.

Anki can hide a token in a snippet, or ask you to type an answer. Both still need a single checkable target. A cloze that hides --force-with-lease checks that flag. Writing the release script is a different target. Anki does not run your program.

People who use Anki for code usually card one fact, distinction, or gotcha they already understand. A prompt to reproduce a whole feature is a practice task, and it is a bad flashcard. "Implement debounce" fails as a card for that reason. The implementation is the editor job.

Interview practice can use the same split. One working approach is to let Anki decide when a problem returns, then solve it again in the editor so you practice the pattern rather than recite one stored solution. The card holds a cue and a date.

Implementing the pattern, or explaining it from a cue and then checking your source, is a card-free review.

Only schedule what you already needed

A common working habit is to remember what you use often, look up the rest, and keep a note or a card only for the things you keep losing. One form of that habit is to save the item the second time you look it up. The first lookup is ordinary work. The second means you needed it again and it did not stay put. That is a practitioner habit, not a finding from a study.

A careful Anki user's own rule was: learn the API by using it, then keep cards only for pieces you will need again. Nielsen records that rule in his own account. That is one person's rule. Use the API on a task you actually have. Drop the cards you will not meet again. Leave an API you might want someday off the schedule until a project has already made a piece of it important.

Recalling a cue is not using it

In that same account, a card can bring a command or an idea back. Using it at the keyboard, and combining it with other ideas, is a further step.

You can produce git rebase -i when a card asks for the command. Choosing it, editing the todo list, and resolving the conflict the rebase stops on is the further step. The card has done its job when the command comes back. The editor is where you find out whether you can apply it with the rest of the history.

Where a different tool is the better fit

If the collection is hundreds of flags, signatures, or command forms, Anki is the stronger fit. Each item is one fact, with its own cue and its own return date.

Some tools schedule short syntax drills and check the code you type. That job is exact production of a small pattern, which is different from keeping an explanation you can reuse.

Writing code is required either way. Yuhimo is not that deck, and it is not a drill that checks the code you type.

How Yuhimo fits

Yuhimo is the fit when you want the explanation to stay a page and only some pages to be scheduled. Every page starts as a note. Turn learning on for the concept you want back: the debounce page, the boundary convention, the isolation prompt. Leave the signatures you look up unscheduled. That selection is what a learning page is.

Add a question when a cue makes the recall specific enough to miss. "Which git reset moves HEAD and also resets the working tree?" can be missed. A heading that only says "Git reset" usually cannot, because it does not ask for one mode. The craft of that cue is the same as any other recall question.

When the page is due, re-explain or re-apply before you open it. Then compare your attempt with the page. The prompt is "How well did you remember this?" You rate your own recall:

• Forgot — Couldn't recall
• Barely — Recalled with difficulty
• Remembered — Recalled correctly
• Easily — Recalled without effort

Yuhimo does not decide whether the answer is correct, and it does not run code. If you could restate debounce and still could not write it, rate the recall you actually had, and do the writing in the editor.

The general method for scheduling notes is spaced repetition for notes. Use that when the question is how a page becomes a review. Use this page when the question is which programming ideas deserve that treatment.

Common mistakes

A whole function on one card. The card has no single checkable target. Practice that feature in the editor.

Every API you might want someday. Until a project has made a piece of it important, lookup is enough. After you have used it, keep only the pieces you will need again.

A syntax drill in place of building. The drill checks a small pattern. Choosing that pattern under the constraints of a real change, and writing the program, still sit in the editor.

A card that only asks you to recognize the command. Recalling git rebase -i when asked means the cue worked. Choosing it, typing it, and combining it is the further step.

An interview queue stuffed into a notes app. A notes page is a poor unit for a list of problems you meant to re-solve. Let a card scheduler decide when a problem returns, and solve it in the editor so you practice the pattern.