Thinking flashcards can be written just about any way is probably the most serious misconception. Flashcards need to be good in a specific way to be effective. Fortunately, there’s lots of instruction online for how to do that.

Andy Matuschak has a long guide to making good flashcards. That’s hands-down my favourite material on this, because it’s so thorough. I could not write anything better. If you have read that and hunger for more, you might be interested in Wozniak’s 20 rules of formulating knowledge. I have not read Boretti’s article on effective spaced repetition, but it looks rather good.

They are all good enough. There are two components to spaced repetition: active recall and the forgetting curve. The forgetting curve is the part the software/algorithm optimises for, and they all do it to within the inaccuracies of the available science. Individual variation (between people using spaced repetition) trumps the small variations in algorithm choice.

Use any algorithm. Use the default in your software. Or use the Leitner system if you want. Anything is a lot better than nothing at all.

Active recall means trying to figure out the answer before looking at it, and then being honest about whether or not you got the answer right before you looked at it. This is in contrast to what many people do, which is look at the answer and then they count that as remembering if they recognised it. Recognising the correct answer is not the same as remembering it.

It will be tempting to say you remember an annoying flashcard just to get it out of the queue, but when feeling that temptation, the right response is to rewrite the flashcard, or unschedule it entirely.

You must be honest with our spaced repetition software about how well you remembered the answer, or it’s not going to be able to prioritise cards properly.

Spaced repetition, used well, reinforces knowledge graphs in your brain. For it to be successful in practise, this knowledge graph needs to be shaped around and hooked into on knowledge graphs that already exist in your brain. Pre-made decks are rarely made to fit your brain. It’s much better to tailor your own deck to fit into your brain well.

See the next few questions for more details.

Nothing! It’s not time wasted, it’s time well spent. For me, I estimate nearly a third of the benefit I get from spaced repetition comes from just the act of creating cards. It’s only reasonable for this activity to make up a quarter of the time spent on spaced repetition.

Finding ways to automate card creation sounds like a quick hack to save a quarter of the time, but if it also loses a third of the benefit, then what’s the point?

Users often complain about the effort required to make flashcards, and conclude that the problem is that (quoting one user)

It feels like if I try hard to make flashcards atomic, then by the time I’ve made them I’ve already internalised the concept and will not forget it for a while. This puts me off the whole process.

That’s a feature, not a bug! This is part of how spaced repetition can support understanding, and not just memorisation.

Good sets of flashcards on something probe that thing from many angles. Make cards asking about

• Properties of the thing,
• Similarities and differences between the thing and related things,
• Examples of the thing,
• Implications of the thing,
• History of the thing,
• Why the thing is significant,
• Decompositions of the thing into constituent parts,
• The bigger phenomenon into which the thing fits,
• Variants of the thing,
• etc.

When making good flashcards, you are forced to explicitly ask these questions. The questions help immediate understanding, and the flashcards enable retention of that understanding over time.

Another way to think about it is that you are not using spaced repetition to memorise the source material verbatim. You are using it to construct knowledge graphs in you brain. Using pre-made decks of flashcards prevents you from creating this knowledge graph in a form that connects well with concepts already in your individual brain.

When learning something, more meaningful practice results in faster learning. The flashcards themselves are not meaningful practice. Time spent with spaced repetition is time not spent with meaningful practice.

But think about what happens during meaningful practice: if we don’t do spaced repetition, we would have to look up the basics, and that takes time away from the meaningful practice! Thus, memorising the basics is a technique to make the meaningful practice more effective.

That said, it is a complicated tradeoff: how much time should we spend memorising fundamentals compared to practicing? I don’t have the answer, but

• I have rarely regretted spending a little more time learning the fundamentals.
• Coworkers more often remark on how quickly learn things when I spend more time on the fundamentals.
• When I’m too stressed to learn the fundamentals, I often end up getting stuck and having to backtrack and learn the fundamentals anyway.

My experience points toward memorising the fundamentals being undervalued in our (software) product development culture.

Both! I used to think it was only for long-term stuff, but when I’ve had to temporarily go into projects based on technologies I’ve never used (e.g. PowerShell) I have had good success in quickly reading a book on the fundamentals and making flashcards from it. It sounds like a slow way to go about things compared to just diving in, but to my surprise it has actually been a very fast way to get to an apprentice level in a new technology.

Once the project is over I unschedule those flashcards and let myself forget again.

Whatever suits you. I have configured mine to be 15 flashcards or 5 minutes, whichever comes first. This usually takes 2–3 minutes and I normally do a couple of sessions in a row. Critically, I only commit to 15 flashcards or five minutes at a time, which is manageable regardless of the size of the backlog.

Keep doing what you would do if there was no giant backlog. The most important thing in spaced repetition is writing good flashcards, and the second most important thing is active recall. None of those are affected by the length of the backlog. Sure, with a backlog you will not be reviewing on the optimal schedule, but that’s not such a big deal. The software will still present you with the highest-priority flashcards first, and that’s good enough.

It can be discouraging to see that there is a 1700-something flashcard backlog, but as with any desirable habit, the important thing is not sticking diligently to it every day, but sticking diligently to resuming it when we’ve fallen off the wagon.

Make better flashcards.

Okay, that might not be your problem. But in almost all cases it is, so there’s a good chance you’re missing something about how to write good flashcards.

With good flashcards covering topics important to you, the process should feel smooth and rewarding and you should notice practical benefits in your life after a few months at most.2² How long it takes you to feel benefits depends on what sort of subjects you cover with your flashcards. If you use them mainly for things you need rarely but which are important when you need them, it can take longer to recognise that it has worked.

Gwern approached this from an economical viewpoint, and estimated his way to 5 minutes. If you suspect you will lose more than five minutes over your lifetime having to look something up or not know it when you need to, it is worth memorising it.

I’ve also read arguments that it’s not just about saving time, but also rescheduling the time cost:

Ask yourself if the cost of having to look it up at a potentially inconvenient time (e.g. in the middle of a busy work day) is greater than the cost of memorizing it during scheduled less busy times (e.g. doing flashcards while eating dinner or during a bus commute).

This perspective indicates it might be work flashcarding things even if you’ll spend less than five minutes looking it up, as long as you typically have to look it up at inconvenient times.

I have some flashcards where this easily happens. For example, to ensure I remember how to compute the natural log from the base 10 log, I have a flashcard asking for the value of the natural log of 23. After a few repetitions, I associate the number 23 with the answer 3.1, without going through the process of figuring it out. When I notice that happening, I change the numbers. Other cards can also be reworded as needed to prevent pattern recognition from taking hold.

Some people seem to think that once flashcards are written, they are set in stone. Not so – feel free to make your decks a living collection of your knowledge graph. Update them as you go and feel like it. Break them apart, join them up, delete them, reword them. Whatever makes them better for you.

So many things! Here are some examples from my decks, but it goes way beyond these.

• Software development
  • Typical posix shell scripting mistakes
  • Domain-driven design concepts and ideas
  • Common Haskell libraries and their most important constituents3³ This used to say .net libraries but I’ve since switched jobs to a Haskell shop so I have unscheduled many of the .net library cards. I’ll put them back into the rotation if I happen to find my way to a .net place again.
  • Details around tcp networking
  • Results from the scientific study of software development
• Hardware and software
  • Powerful functionality in your development environment you use rarely but love to know about when you need it
  • Netcat invocations that are very useful for troubleshooting but again rarely needed
  • Cash flow conventions for the hp-12c financial calculator
  • The meaning of various lamps, warnings, and symbols in cars you drive
• Maths
  • How to do things with the standard libraries that you typically rely on third-party libraries to do
  • How to generate random numbers from a few common distributions
  • Identities in linear algebra
  • Limit laws in probability
  • Base 10 logarithms
• Human interaction
  • Phonetic alphabets used by the nato and local variants
  • Negotiation techniques
  • Things to observe to extract details from an environment or interaction
  • Instructive details from biographies
  • Terminology from the philosophy of science
• Organisations
  • Ideas from queueing theory, and where they apply
  • Histories of various innovative products
  • Techniques from lean production to deal with variation in flow
  • Decision-making protocols, like formal consensus and Robert’s Rules
  • Advice for freelance consulting
• Fermi nutrients, i.e. order-of-magnitude reference points that can be combined to improve the accuracy of other estimations.

Some of this might not make sense at first, like why should we care about the histories of innovative products? But one of the things I love about working with experienced people is how often they can go, “Yeah, this is like that one time where X” and retell a story from their past. I want to be like that, except I’m way too young to retell stories from my past. But I can maybe learn to retell stories from other people’s lives, and get better at my craft for it.