Anki 程式設計師記憶卡指南：哪些內容值得製卡？

The first Anki deck I made for programming had 312 cards. I deleted it six weeks later.

Most of the cards looked like this: "What does Array.prototype.reduce do?" on the front, a paragraph copied from MDN on the back. Every morning I'd get 40 of them, recognize the answer, tap "Good", and learn nothing. Reviews felt productive and weren't.

I came back to spaced repetition about a year later, after reading two essays that changed how I thought about it. This post is what I'd tell a developer who wants to try flashcards for code and doesn't want to waste six weeks the way I did.

Why bother with flashcards at all

The honest case for it is small. You don't need flashcards to write code, because you can look things up. What flashcards save you is the lookup tax: the 20 seconds of breaking focus to search for the tar flags or the Postgres syntax for an upsert, ten times a day.

Derek Sivers wrote about this back in 2012 in a post called "Memorizing a programming language using spaced repetition software." His point was that having the basics in your head frees up attention for the actual problem. Michael Nielsen made a similar argument in his 2018 essay "Augmenting Long-term Memory," where he describes using Anki to read research papers and learn new fields. Both are worth reading before you make a single card.

What belongs on a card

After a lot of trial and error, these are the kinds of cards that survived in my deck.

Small, exact facts you keep looking up. git log --oneline --graph. The difference between useEffect and useLayoutEffect. Which HTTP status code means "unprocessable entity" (422). If you've searched for it three times, it earns a card.

Gotchas that bit you. "In JavaScript, [10, 9, 1].sort() returns [1, 10, 9]. Why?" The back says it compares as strings by default and you need a compare function. I remember these well because each one came with a bad afternoon attached.

Concepts as questions, phrased so you have to produce something. Not "What is a closure?" but "Write a function that returns a counter, using a closure." You answer in your head or on paper, then check.

What doesn't

Whole paragraphs of documentation. If the back of the card takes more than about ten seconds to read, it's a reading assignment, and you'll start skimming it.

API surfaces you rarely touch. I had cards for obscure Intl options I've used once in my life. They cost review time every week and paid back nothing.

Anything you can't explain yet. Making a card for something you don't understand just schedules your confusion. Learn it first, then card the parts worth keeping.

One idea per card

This is the rule that made the biggest difference. Nielsen calls it making cards "atomic." If a card has two facts on it, you'll remember one, get it half right, and mark it correct anyway.

So a card like "What are the four types of SQL joins and how do they differ?" turns into four or five cards. "What rows does a LEFT JOIN keep that an INNER JOIN drops?" is one of them. It feels like more work. It's much less work at review time, because each card takes three seconds.

Write cards in your own words, with context

A card I wrote myself last spring:

Front: Docker: container exits immediately after `docker run`. First thing to check?
Back: The main process finished. A container lives as long as PID 1.
      (Hit this running a script image with no long-running command.)

The bracketed line on the back is the part I'd have skipped a year ago. It ties the fact to something that happened, and that's what makes it stick. Copy-pasted cards have no hook.

Keep the daily review short

Anki's defaults will happily give you 200 reviews a day if you add cards fast enough. Don't. I cap new cards at about five a day and treat the deck like brushing teeth: ten minutes with coffee, done.

If reviews pile up, that's a signal you added cards you didn't need. Suspend or delete them without guilt. A deck you open every day beats a perfect deck you avoid.

If you're curious how the scheduling works under the hood, I wrote a walkthrough on implementing the SM-2 algorithm in JavaScript. It's the algorithm Anki's older scheduler was based on, and it's short enough to read in one sitting.

The part flashcards don't cover

Here's where my own system still had a gap. Most of what I learn as a developer doesn't come from docs. It comes from conference talks on YouTube, podcast episodes during a commute, a long blog post someone shared in Slack. Turning those into good cards by hand takes real effort, so I mostly didn't, and I forgot them.

That gap is why I built Recl. You save a video, reel, podcast or article, it writes a summary, files it under a topic, and then brings the key points back to you with spaced repetition over the following days and weeks. It handles the "I watched a great talk and can't remember a thing from it" problem, while my Anki deck handles syntax and gotchas.

I use both. They don't overlap much.

If you want to start today

Install Anki, make one deck called "code," and add three cards about things you looked up this week. Make each one a question you have to answer, keep it to one idea, and add a line about where you ran into it.

Then do your reviews tomorrow. And the day after. The habit matters more than the deck, and you'll know within a couple of weeks whether it's paying off, because you'll notice you stopped opening the same docs page.

I'm Spartan Rich, and I build Recl, an AI learning app that saves your videos, reels, podcasts and articles, summarizes them, and uses spaced repetition so you remember what you learned.