How to write cards you'll still want to see in six months

The example courses are a quick way to see how SRS Badger works. But the cards that end up being most useful are the ones you write yourself, because they're about your gaps: the thing you looked up twice this month, the bug that cost you an afternoon, the formula you can never quite remember.

Writing good cards is a small skill of its own. Here's what I'd suggest.

Write the card while it still hurts

The best time to write a card is right after something cost you time. Maybe you assumed sort() returned a new list, or you forgot which way around a LEFT JOIN goes. In that moment you know exactly what the card should ask, what the wrong answer looks like, and which test case would have caught it.

If you wait until tomorrow, it'll feel too obvious to bother writing down. That's a trap. Things only feel obvious because you just looked them up.

One thing per card

Each card should test one thing. If a card covers three ideas and you forget one of them, you have to rate the whole card as forgotten, and the scheduler can't tell which part was the problem.

For coding cards, size matters even more. You're going to see this card many times over months, so it should take a few minutes, not forty-five. A card you dread is a card you'll skip, and once you start skipping, the whole schedule falls apart. "Implement an LRU cache" is one card. "Implement an LRU cache with expiry, thread safety and metrics" is four cards, or maybe just a bad afternoon.

Pick the kind of card by how you forget it

SRS Badger has a few kinds of cards. They're good at different things.

Code cards, when the problem is "I can't write it". You write a solution and it runs against tests. Use these for things you need to be able to do: a query shape, an algorithm, an idiom you keep fumbling.

Flashcards, when the problem is "I can't remember it". What HAVING does that WHERE doesn't. Why you can't write s[0] on a Rust String. These are much quicker to review than code, so don't make something a code card if remembering the fact is the whole point.

Typed answers, when it's short and you'd fool yourself otherwise. With a normal flashcard it's easy to flip it, see the answer and think "yeah, I knew that". Making yourself type it first removes that. They work best when the answer is short and exact: a keyword, a number, a name. You can list other answers that count, like 0.75 alongside 3/4.

Multiple choice, when the wrong answers are real mistakes. It's only useful if the wrong options are things people actually believe. If the wrong answers are obviously silly, you're not testing anything.

Dynamic cards, when you need the method and not the answer. These are small programs that make a new problem every time the card comes back. They're mostly for math: if you see "expand $(x + 3)(x - 5)$" every week, you'll eventually just remember $x^2 - 2x - 15$. With a dynamic card the numbers change every time, so you have to actually do it.

Let the tests be the spec

On a code card, the tests are plain data: the arguments go in, the expected value comes out.

[
	{ "in": [[3, 1, 3, 2]], "out": [3, 1, 2] },
	{ "in": [[]], "out": [] },
	{ "in": [["b", "a", "b"]], "out": ["b", "a"] }
]

That means the prompt can stay short, because the tests say exactly what "correct" means. Put your effort into the edge cases: the empty list, the single item, the one you got wrong the first time. Those are the ones that catch you when you're working from memory.

Don't make cards for everything

Some things don't need a card at all. Anything your editor autocompletes, exact argument orders you'd look up anyway, config syntax you touch once a year. Let your tools remember those. Cards are for the things you want in your head while you're actually working.

Using AI to write cards

Every chapter has an Author with AI button. It copies a prompt you can paste into ChatGPT, Claude or similar, and you paste the result back in to get a batch of cards. It's a fast way to get started on a new topic.

I'd still read every card before keeping it. AI-written cards tend to be too big, too vague, or test something you don't care about. Delete the ones that aren't useful and edit the rest. A few good cards are worth far more than a lot of mediocre ones.

The habit

That's really the whole thing. Next time something takes you a long time to figure out, spend two more minutes turning it into a card. Then let the schedule make sure you only have to figure it out once.