Spaced repetition for computer science (2026)

You followed the proof in lecture. You understood the solution when you read it. Two weeks later you cannot reproduce either. This is not a memory problem — it is a problem with what you practised.

Computer science has an unusually wide gap between understanding something and being able to produce it under pressure. You can follow a red-black tree rebalancing argument line by line, agree with every step, and be unable to write the rotation cases from a blank page a fortnight later. I remember sitting in my dorm at 2am before algorithms midterms, re-reading the same AVL rotations over and over, nodding along like I'd mastered them. Then the exam asked me to delete a node and rebalance — I froze, drew three wrong trees, and walked out with a solid B minus. That gap is where most study time goes to die.

The fix is not more hours. It is changing what you rehearse.

Recognition is not recall, and reading is mostly recognition

When you read a worked solution and think "yes, that's right", you are exercising recognition. It feels like learning because it feels fluent. But fluency while looking at the answer predicts almost nothing about whether you can generate the answer without it.

This is why re-reading lecture notes and re-watching a walkthrough are such poor uses of time, and why they feel so productive. The subjective sense of "I know this" is produced by familiarity with the text, not by the ability to reconstruct the idea. One of my professors used to say, "If you can't write it from memory, you don't know it — you've just seen it before." That line stuck with me more than any textbook.

The practical test is brutal and quick: close everything and write the thing from an empty file. If you cannot start, you did not know it. Most people discover this the first time in an exam or an interview, which is an expensive place to find out.

Why naive flashcards fail for CS specifically

Spaced repetition has an excellent reputation in medicine and languages, and a mediocre one among programmers. The reason is that most people write CS cards as definitions:

Front:  What is Dijkstra's algorithm?
Back:   A shortest-path algorithm using a priority queue…

That card tests whether you can recognise a name. It will not help you implement it, choose it, or notice when it is the wrong tool. You can answer that card correctly for a year and still fail to spot that your graph has negative edges. I once had a study buddy who could recite every sorting algorithm's time complexity cold — then bombed a system design question because he couldn't explain why he'd pick quicksort over mergesort for a specific workload.

CS knowledge is mostly procedural and conditional — how to do something and when it applies. Definition cards test neither.

Five card types that actually work for CS

These are the shapes worth writing. Each one forces generation rather than recognition.

1. Counterexample cards

Front:  Why does Dijkstra fail with negative edge weights?
        Give the smallest graph that breaks it.
Back:   Once a node is finalised it is never revisited. With a
        negative edge a later path can be cheaper.
        3 nodes: A->B = 2, A->C = 5, C->B = -4.
        B is finalised at 2; the true shortest is 1.

Forcing yourself to produce the minimal counterexample is what converts "I know it doesn't work" into "I know why, and I would notice."

2. Invariant cards

Front:  State the loop invariant for binary search on [lo, hi).
Back:   If the target is present, its index is in [lo, hi).
        Preserved because we discard only the half that
        cannot contain it. Terminates because hi - lo strictly
        decreases.

Nearly every off-by-one you will ever write is a violated invariant you never articulated. Writing them down once, and rehearsing them, kills an entire category of bug.

3. Complexity derivation cards

Do not memorise that mergesort is O(n log n). Memorise the derivation:

Front:  Derive the running time of mergesort from its recurrence.
Back:   T(n) = 2T(n/2) + O(n). log n levels, O(n) merging per
        level, so O(n log n). Master theorem case 2.

A remembered result is useless when the recurrence changes. A remembered method handles the variant you have not seen, which is the one you will be asked about.

4. "What breaks if" cards

Front:  What breaks if a hash table's load factor is allowed
        to approach 1?
Back:   With chaining, buckets lengthen and lookup degrades
        toward O(n). With open addressing, probe sequences
        grow sharply and clustering compounds it.

These build the conditional knowledge that decides whether you pick the right structure at all — the part interviews and real systems actually test.

5. Blank-page reconstruction cards

Front:  Implement quicksort partition (Lomuto) from scratch.
        No looking.
Back:   [your own reference implementation]

Slower than the others, so use them sparingly — perhaps five procedures you genuinely want in your hands. But this is the only card type that rehearses the exact skill an exam or interview demands: production from nothing. When I was grinding for coding interviews, these cards were the only thing that actually made me faster in a live coding session.

Interleave, or you will learn to recognise the chapter instead of the problem

Doing thirty dynamic programming problems in a row teaches you something real, but it also teaches you something false: that you already know the technique before you read the question. The chapter heading did the hardest part for you — selecting the approach.

In an exam nothing tells you it is a DP problem. Selection is the skill, and blocked practice never rehearses it.

Mix problem types within a session. It will feel worse and score lower in the moment; that is the expected pattern. The literature on interleaving is consistent that blocked practice produces better practice performance and worse retention, which is exactly the trap — the method that feels most effective is the one that works least.

Space it, but not evenly

Review just as recall starts to get difficult. Roughly: one day, three days, a week, two weeks, a month. The precise numbers matter far less than the principle — an easy review is a wasted review, because retrieval strength grows with the effort of retrieval.

Two habits worth having:

• Write cards the same day you meet the material. A week later you no longer remember which parts confused you, and confusion is the best signal for what to make a card about. I learned this the hard way — cramming a full week of OS lecture notes into cards on Sunday night gave me a deck full of useless trivia and zero insight into what I actually struggled with.
• Delete aggressively. A deck you dread is a deck you abandon. Fifty cards you actually review beat four hundred you do not.

Plenty of CS material should never become a card:

• Language syntax. You will absorb it by writing code, and the editor helps.
• Library APIs. Documentation exists and changes faster than your deck.
• Specific constants — default load factors, buffer sizes. Know that they exist and are tunable; look them up.
• Whole proofs verbatim. Card the key step or the insight, not forty lines of algebra.

The test for whether something deserves a card: would being unable to recall it in a conversation, exam or design discussion actually cost you? If not, leave it in the documentation.

A workable weekly loop

1. After each lecture or chapter, write 3–8 cards — counterexamples, invariants, derivations. Twenty minutes.
2. Review due cards daily. Fifteen minutes, and it stays fifteen if you delete ruthlessly.
3. Once a week, pick two or three algorithms and implement them from an empty file. This is the honesty check, and it is the step people skip.
4. Practise mixed problem sets, never grouped by technique.

None of this is fast. It is simply the difference between studying for four hours and remembering nothing, and studying for one hour and being able to produce the thing when it counts.

The single highest-use change, if you take only one: after reading any worked solution, close it and write it out from scratch. The gap between how easy that feels and how hard it turns out to be is the entire problem, measured.

Integrating Spaced Repetition into Your Coding Workflow

Spaced repetition isn't just for theoretical concepts; it's a powerful tool to solidify your practical coding knowledge. Think beyond definitions and apply SR to the intricacies of writing, debugging, and optimizing code. When you encounter a particularly stubborn bug, a tricky language feature, or a complex API call, that's your cue to create a new flashcard.

For instance, after successfully debugging an issue, create a card asking, "What was the root cause of the 'NullPointerException' in Module X, and what specific change fixed it?" Or, if you've mastered a complex syntax like C++ smart pointers or Python decorators, design a card that requires you to write a minimalist example from scratch, explaining each component. This approach helps you internalize common error patterns and efficient solutions, transforming frustrating moments into lasting learning opportunities.

By actively reviewing these practical scenarios, you'll build a robust mental catalog of solutions, reduce your

Creating Production-Focused Spaced Repetition Cards

While definition cards may not be the most effective way to practice computer science concepts, you can create production-focused cards to practice problem-solving skills. For example, you can create cards with incomplete code snippets that require you to complete the implementation.

An alternative approach is to create cards with a problem statement or a specific coding challenge. This type of card encourages you to think critically and apply your knowledge to solve a real-world problem.

Consider using a tool like ScholarNet AI to help you generate these types of cards. This AI-powered platform can assist you in creating customized practice cards based on your study plan and learning objectives.

Using Storytelling Techniques with Spaced Repetition

One effective way to retain computer science concepts is by creating stories that illustrate key concepts. For example, you can create a story about a character who is designing a complex algorithm to optimize a web application's performance.

When you create these stories, try to incorporate multiple concepts into a single narrative. This approach can help you build connections between different ideas and retain them more effectively.

• Create a character with a specific goal or problem to solve.
• Use key concepts as plot twists or turning points in the story.
• Make use of sensory details to bring the story to life.

Integrating Spaced Repetition with Active Learning Strategies

Spaced repetition is most effective when combined with other active learning strategies. For example, you can try summarizing key concepts in your own words or creating concept maps to visualize relationships between ideas.

Another approach is to teach someone else the concept you're trying to learn. This approach can help you identify knowledge gaps and retain information more effectively.

• Summarize key concepts in your own words.
• Create concept maps or diagrams to visualize relationships.
• Teach someone else the concept you're trying to learn.

🎓 Turn any topic — or your own notes — into AI flashcards in seconds. Free, no signup.

No account needed to try. Sign up free anytime to save your decks and unlock the AI tutor, quizzes, and more.

Get the full ScholarNet toolkit — free

Save your work, run Brain Battles against other schools, track your GPA, and unlock the AI tutor. One email, no password.