essay · spaced repetition

Spaced Repetition for Programmers (Not Vocabulary Apps)

You finish a course, feel sharp for about a week, then open an editor three weeks later and can't write a for loop without looking it up. That's not a willpower problem. It's a review problem, and most of the fixes people reach for don't actually touch it.

You finished the course. Three weeks later you can't write a for loop.

This happens to almost everyone who learns to code outside a job that forces daily reps. You finish the bootcamp, the course, the YouTube series. You feel capable. Then life happens for two or three weeks: a different project, an interview process, a vacation. You open a blank file and the syntax that felt automatic now needs a Google search. Not because you're bad at this. Because you stopped doing reps, and code skill behaves like a physical skill. It decays without use.

The usual advice is to reread your notes or redo the tutorial. Neither works for long, and it's worth being specific about why.

Flashcards remember facts. They don't make you write code.

Spaced repetition itself is sound. Review something right before you'd forget it, and the memory holds longer each time. That part isn't in question. The question is what you're reviewing.

Classic flashcard decks test recognition: you see a question, you recall a fact, you flip the card. That works well for vocabulary, for historical dates, for "what does .reduce() do." It works less well for code, because knowing what .reduce() does and being able to write a reducer from a blank editor are different skills. A recognition card can confirm you remember the definition. It can't confirm you can produce the thing.

This is also the core of the honest objection to using flashcards for programming at all: some developers argue memorizing a language is pointless, that understanding how things work by building real programs is what counts. They're not wrong about the goal. They're describing a failure of recognition-style cards, not a failure of spaced repetition as a method. If your deck is "what is a closure" with a text answer on the back, you're going to hit that ceiling fast. You can get very good at reciting definitions and still freeze on a real problem.

Why "just reread your notes" and "just Google it again" both fail

Rereading feels productive because it's fluent. You see the code, you follow the logic, it makes sense, you move on. That fluency is the trap. Recognizing a solution when it's in front of you tells you almost nothing about whether you could produce it cold. This is the same gap between watching someone lift and lifting the bar yourself.

Googling it again works in the moment and teaches you nothing for next time. You solve the immediate problem and leave the underlying gap exactly where it was. Do this enough times with the same pattern (binary search, the classic two-pointer setup, a basic decorator) and you build a habit of outsourcing the recall instead of building it.

There's a related failure mode showing up in generic spaced-repetition tools built for code: the scheduler decides what you owe, and if you miss a few days, the backlog piles up into something that feels like debt instead of practice. That's a tooling problem more than a method problem, but it's part of why plain SRS apps feel punishing for working developers who already have unpredictable schedules.

What changes when you type the answer instead of recognizing it

The fix isn't a different flashcard app. It's a different kind of card: one where the back of the card is a blank editor and the question is "write this function." No multiple choice, no fill-in-the-blank, no peeking at the first few characters and declaring victory. You type the whole thing, from memory, and the IDE either runs it or it doesn't.

This is a small shift that changes everything about what the review actually measures. Recognition tells you that information is somewhere in your head. Production tells you that you can retrieve it, structure it, and get the syntax right under the small pressure of a blank screen, which is exactly the condition you're in during a technical interview or when you sit down to ship a feature. The Anki-skeptic argument concedes this indirectly: the value people do get from flashcards for code is reviewing specific tidbits and gotchas, not full programs. Production practice at the snippet level is the version of that concession that actually holds up. You're not trying to flashcard your way through a whole codebase. You're drilling the function-level and pattern-level reps that would otherwise rot between projects.

The gap between bootcamp graduation and your first interview

This gap is where most of the damage happens, and it's rarely talked about honestly. You spend three to six months in a bootcamp or self-taught sprint building daily reps without meaning to, just by doing assignments constantly. Then you graduate, and the daily forcing function disappears. You're job hunting, which means interview prep, networking, maybe a part-time job to cover rent, and the actual hands-on-keyboard coding time shrinks to whatever's left over.

Three months later you're in a technical interview and the fundamentals that felt automatic at graduation are rusty. Not gone. Rusty. You recognize the pattern the second you see the solution, which is cruel, because it means you knew this. You just couldn't produce it fast enough live.

This is the actual argument for keeping some kind of structured review going after you finish learning, not during it. I build FlashCode for exactly this gap: it's spaced repetition where the cards are real code snippets you type from a blank editor, not facts you recognize, organized by language and role so the reps match what you're actually interviewing for. I built it because I kept watching capable people lose fluency in the dead time between finishing a course and landing the job, for reasons that had nothing to do with how good they actually were.

Spaced repetition built for snippets, not vocabulary

If you take nothing else from this: when you evaluate any tool, including this one, ask whether the review is recognition or production. Can you flip a card and nod, or does it make you actually write the thing. The forgetting curve is real and the scheduling math behind spaced repetition is solid, but none of that matters if what you're reviewing doesn't resemble what you'll be asked to do. Code skill lives in your fingers as much as your head. Review it that way.