Spaced Repetition for Programming: What to Put on Your Cards

"Why memorize anything? You can just look it up." It's the standard objection to flashcards for programming, and it's half right. Nobody needs to memorize an entire standard library, and looking things up is a normal part of the job.

But looking something up has a cost. Every search breaks your train of thought, and you can only search for things you know exist. Developers who know the basics by heart write code faster, read other people's code more easily, and spot problems sooner. Spaced repetition is a cheap way to get there: a few minutes a day, spent on the things you'd otherwise look up again and again.

Why Programmers Use Spaced Repetition

In 2013, Derek Sivers wrote about memorizing a programming language with spaced repetition, and described it as one of the most useful learning methods he'd found. His core advice: "Flash cards are for remembering what you've learned", so learn first, then make cards. Physicist and programmer Michael Nielsen describes a similar practice in Augmenting Long-term Memory, using spaced repetition to absorb technical material, and recommends keeping each card "as atomic as possible".

The research behind it is general but solid. In a review of study techniques, Dunlosky and colleagues (2013) rated practice testing and distributed practice as the two techniques with the highest utility. Flashcards with spaced repetition are both at once.

What to Put on Your Cards

Syntax and methods you keep looking up. If you've searched for the same thing twice, it deserves a card.

Complexities. The time and space cost of common operations and algorithms, which is a staple of courses and interviews alike.

Data structure behavior. What a stack, queue, heap or hash table guarantees, and what it costs.

Code-reading cards. A short snippet on the front, what it prints or returns on the back. These train careful reading, which is exactly what exams and code reviews test.

Commands. Git, the shell, SQL: things you use often enough to want them at your fingertips, but not quite often enough to remember.

Concepts. Short definitions of ideas like a race condition, idempotency or a closure, in your own words.

Example Cards

x = [1, 2, 3]
y = x
y.append(4)
print(x)

git reset --soft HEAD~1

What Not to Put on Cards

Whole algorithms, line by line. Memorizing an implementation word for word is slow and brittle. Put the idea on a card ("quicksort: pick a pivot, partition around it, recurse on each side") and practice implementing it in code.

Things you don't understand yet. A card for a concept you can't explain just teaches you to repeat words. Learn it, try it, then make the card.

Things you'll never use. Obscure flags and rarely used APIs make reviews longer without making you better. Card what you actually use, or are about to.

Make Cards From Your Own Mistakes

Some of the best programming cards come from bugs. When something breaks because of a detail you didn't know (a mutable default argument in Python, integer division, an off-by-one in a loop), write a card about it right after you fix it. You've just found a gap in your knowledge, and the card closes it for good.

A Simple Routine

While you code, keep a short list of things you looked up or got wrong.

At the end of the day, turn the best three to five into cards.

Every day, review your due cards, usually ten minutes or less.

Keep writing code. Cards make the details stick; projects and exercises are where they turn into skill.

Writing Code on Cards in Space Repeat

Code is hard to read as plain text, so Space Repeat formats it. Wrap a snippet in three backticks with the language name and it's shown with syntax highlighting for Python, JavaScript, TypeScript, Java, C, C++, SQL, Bash or HTML. Single backticks mark inline code, and Big-O notation can go between dollar signs, like $O(n \log n)$. The Math & code toolbar under each card field inserts a code block for you and shows a preview.

New accounts can also start from ready-made decks for Python basics, data structures and Big-O, algorithms, SQL, and Git and the command line. See Computer science flashcards and Coding flashcards for more examples.

The Bottom Line

You don't need to memorize everything, but knowing the basics by heart makes you faster and more confident. Put the things you keep looking up on cards, add code-reading cards and cards from your own bugs, keep every card small, and review a little each day. Then go and write code: that's where it all comes together. For keeping the daily load sustainable, see How Many Flashcards Should You Study Each Day.