Case Studies in Writing Cards

17 minute read

The Twenty Rules and my Rules for Designing Precise Anki Cards are all very nice, but knowing all the rules doesn’t necessarily mean you can do it yourself, or even fully understand the consequences of the rules. Sometimes it’s more informative to see the rules in action. So in this post, we’ll look at three case studies of real things I added to my Anki collection recently and how I selected and wrote the cards in accordance with these principles. The first focuses on some new English words, the second on historical British currency, and the third on some confusing behavior of a piece of software.

Vocabulary

First, let’s take something comparatively simple: words. We can make words as complicated as we want, but for the purposes of building vocabulary, we’re probably after one particular thing: when we see the word in a new context, we want to know what it means. Despite the apparent simplicity of what we want to learn, there is nuance in method even here; at least in my experience, the naïve approach to learning words is considerably less effective than a more considered one.

Let’s talk about sources for a moment. Every time I encounter a new word in English, I try to mark it down. With a paper book, I put a dart next to the word; on my Kindle, I simply look up the word by long-pressing on it, which has the lovely side effect on recent Kindles of adding it to your “Vocabulary Builder,” which you can later look through to find all the words you looked up. I don’t encounter many new words in articles I read on the computer, but if I do I try to just scribble them down and add them immediately when I finish the article. If you’re actively learning a foreign language in a way that involves reading on the computer, you’ll be seeing a lot more new words, so you might need to come up with something better!

Now that we have the words, we have to create cards from them somehow. The easiest would be to type the word into a dictionary application, copy and paste the definition, and drop it onto a card. I don’t do this, though; it results in a pile of out-of-context cards. Out-of-context cards can be OK if you need volume; I learned an imported heap of several thousand cards in preparation for my SATs and got a perfect score on the vocabulary section, in significant part due to that. But now that I know the vast majority of words I come across, but those I encounter are more unusual and harder to remember, it makes more sense to make the cards better. I haven’t done a controlled experiment, but I would be surprised if this didn’t come out faster in the end: it takes a bit longer to create the cards, but you spend less time reviewing them and the knowledge is more accessible.

Here’s what I include on my cards:

  • The word itself (of course). The word is the only thing that goes on the front of the card.
  • The definition. Rather than copying and pasting a definition, I put the word into Google and read through a variety of definitions, then write my own definition, striving to emphasize the way the word was used in the context where I encountered it. Elaborative rehearsal strikes again here.
  • The sentence (or, occasionally, several sentences, if needed) in which I initially saw the word. The word itself is in bold. This way, if I’ve forgotten the card, I can see an example of how it would be used. I find having and frequently seeing the sentence actually makes the definition easier to remember, too; I often have a vague notion of the example sentence when I look at the word, which makes it easier to remember what the word means, too.
  • The source, both because it’s fun to see and in case the sentence is ever not enough context and I want to go back and look.

I use a custom note type to store and format my cards.

Here are a couple of recent examples of this approach:

  • phalanstery
    • n. A community of people living together in common; commune.
    • The Communion of Saints is not a phalanstery; nevertheless it is a unity.
    • The Intellectual Life, A.G. Sertillanges, p. 57
  • loutish
    • n. Uncouth, rude; awkward (esp. of a boy or man).
    • Other rules even forbade [Yale students] from ‘sit[ting] on the College fence on Sunday’ – an apparent red flag of loutishness.
    • https://quillette.com/2020/06/17/bad-vibrations-the-lies-universities-tell-their-students-about-sex/
  • costermonger
    • n. (chiefly British) A person who sells goods, especially produce, in the streets.
    • [Jim] had loved too well to imagine himself a glorious racehorse, and now he was condemned to toil without honour like a costermonger’s donkey.
    • Lord Jim, Joseph Conrad, p. 151

Theoretical note: Knowledge of a word comes in several stages: first, we’ll have no idea what the word means at all, except for a guess based on similar words; second, we might have a vague notion of what it means; third, we might be able to recite or explain the definition but have to think about it a little bit; fourth, we might fully understand it; then finally we might use it in our own speech or writing. The primary goal of putting vocabulary into Anki is to boost it from the first or second stage into the third. Anki can also help bring about the fourth and fifth stages by bringing the word to your attention at random times where you might be in a good position to use it, but this is a secondary benefit and not one you should count on.

History

I’ve been reading The Intellectual Life of the British Working Classes, and every couple of pages it starts discussing the costs of things – books, classes, subscriptions, or the like. Since the time period being discussed is in the 1800s to early 1900s, this is all pre-decimal British currency, in pounds, shillings, and pence, with names of coins I’ve never heard of mixed in. Essentially, the prices of things being quoted are meaningless to me. I’m only a third of the way through the book, plus I’ve had this problem before with British literature. Let’s fix this by committing the basics of the system to memory.

Wikipedia should do fabulously as a source for something like this: well-established facts, little to dispute, and all we need is an overview. Let’s pull up £sd and get reading. (That link is a snapshot of the current revision at the time I wrote this blog post, in case the structure of the article changes enough to make the post hard to understand.)

Before creating any cards, it’s usually a good idea to read the whole article, or at least a section at a time. If you don’t, you may shortly discover some things you added are irrelevant or even wrong, and you might miss out on opportunities for integration cards (more on that in a minute). If it’s a long article, you might want to scribble down notes on items you know you want to create cards for as you go, but this one is short enough that shouldn’t be a problem.

After reading the article, I conclude there are three main things from it that I want to retain:

  1. What is the relationship between pounds, shillings, and pence?
  2. How much of these were the common coins worth?
  3. When was this system supplanted?

One other thing that’s not in the article: I’d like to know roughly the exchange rate with a currency I’m familiar with today, so I have at least a general sense of scale. We’ll come back to this later.

For question (1), the most obvious way would be simply to ask, “What is the relationship between pounds, shillings, and pence?” But if you’ve read either the 20 Rules or my Creating Precise Cards, or one of many other resources on creating spaced-repetition flashcards, you know that we’ll do better splitting this up into several atomic units. Rather than asking for the relationship between pounds, shillings, and pence, we’ll start with two questions:

Q: £sd: How many pence are in a shilling?
A: 12

Q: £sd: How many shillings are in a pound?
A: 20

Notice the prefix £sd on the questions. The context of these questions may seem clear enough without it, but being extra-clear on the context of a question will never hurt, and something that looks clear while you’re adding cards may look vague during review. Who knows, maybe twenty years from now some new country will start using unrelated units called “shillings” and “pounds”!

I’m going to add one more card on this topic, an integration card. By “integration,” I mean that it doesn’t add any facts that we couldn’t in principle work out from the other cards we’ve already added; instead, it merely connects or integrates those other cards. Integration cards help keep the knowledge fresh and relevant in your mind by forcing you to use it and think about the relationships between the cards. A collection with no integration cards has a tendency to turn into a disconnected collection of facts, which makes review more boring and your memory worse.

Q: £sd: How many pence are in a pound?
A: 240

(Look, it hasn’t even been a full minute, and we’ve already proved the need for the £sd qualifier: there are 100 pence in a modern pound!)

Now for question (2). The table in the Decimalizations section of the article provides a handy list of the most common pre-decimal coins and their values. We don’t need to add cards for all of them; for instance, it is patently obvious that a sixpence coin is worth six pence. I’ll add cards for the florin, crown, half-crown, sovereign, and guinea, all following the same pattern:

Q: £sd: How much is a guinea worth?
A: 21 shillings

The half-crown card deserves some notice, too, as it’s actually an integration card. I could have safely assumed I would remember that a half-crown is worth half of a crown, but I added it anyway because this is an opportunity to also touch the knowledge that half a shilling is sixpence, since five doesn’t divide evenly by two:

Q: £sd: How much is a half-crown worth?
A: 2/6 (2 shillings, 6 pence)

I managed to sneak in the written notation for shillings and pence from the Writing conventions and pronunciations section here, too, though since it is in the answer and not the question, I am not necessarily expecting to remember it. If I thought that was a crucial point, I’d want to add several cards about that.

Note: If you’re really attentive and you’ve read the post on creating precise cards, you might notice that the last two questions could be made more precise: I could conceivably give other correct answers. For instance, a half-crown could also be one-eighth of a pound, and a guinea could be 252 pence. But in this case, I think understanding what units should be used is actually part of understanding the £sd system; if your first thought of how to express the value of a guinea is in pence, you are missing the point of the system! We could conceivably split each question into two questions, e.g., “How much is a guinea worth in shillings?” and “In what units should you express the worth of a guinea?”, but even to me that seems like it’s going further than necessary. If I notice I’m failing the card over and over for this reason, I’ll tackle simplifying it then.

For question (3), we really only need one question to accomplish my goal:

Q: £sd: In what year was British currency decimalized?
A: 1971

One more step: understanding how this relates to today’s currency. This was remarkably difficult to figure out, but I think I got it right! First I went to Wikipedia’s table of historical exchange rates to the US dollar, which has figures running back to 1850. Then we need to convert these figures into 2020 US dollars to get the understanding of scale I’m looking for, which we can do with Wolfram|Alpha. For instance, typing in $1 in 1850 in USD yields the information that $1 in 1850 dollars is worth $34.71 in 2020 dollars. The exchange rate between pounds and dollars in 1850 was 0.2017, according to Wikipedia; we have to invert that to go from dollars to pounds, yielding approximately 4.957. Then:

(Why not just ask Wolfram|Alpha for an 1850 pound in 2020 dollars? It doesn’t seem to have exchange data for the pound going back that far.)

Using this process:

  • 1850: £1 is worth $172.06
  • 1900: £1 is worth $160.76
  • 1950: £1 is worth $31.12

Since my goal was just a general idea of scale, I’ll round off roughly and split it into just two data points, losing some detail but making it a great deal easier to remember:

Q: £sd: About how much was an 1850 or 1900 pound worth in 2020 dollars?
A: $150

Q: £sd: About how much was a 1950 pound worth in 2020 dollars?
A: $30

And why not an integration card or two, for some additional practice and because these are nice reference points as well:

Q: £sd: About how much was an 1850 or 1900 shilling worth in 2020 dollars?
A: $7.50

Q: £sd: About how much was an 1850 or 1900 penny worth in 2020 dollars?
A: $0.60

There. That’s 13 cards, total lifetime cost of maybe 40 minutes, and I’ll have a continuing basis for comparison with one of the most influential (and confusing) currency systems in modern history.

Now, I might want to make some changes later on. For instance, perhaps the groat comes up in something I’m reading and I want to make a note of how much that’s worth. The great thing is that now that I won’t forget the basics, these kinds of additions will be easy: I have a way of judging if new information is interesting or important, and instead of having to read an article and create a whole structure of knowledge in my head, I can likely run a 30-second Google search and, should I decide it’s worthwhile, drop one card into my collection. Similarly, maybe 30 years from now I want to rerun the conversion math with the current value of the US dollar (notice that I wrote “2020 dollars”, not just “dollars” – spaced-repetition flashcards need to be written to age well!).

Programming

Today at work I was trying to debug a problem with an automated build in Azure DevOps, and I created another bug while debugging that prevented me from attacking the original bug (if you’re a programmer, you will recognize this phenomenon!). About half an hour later, I figured out the new bug: I named my test Git branch users/soren, whereas the previous branch had been named develop, and it turns out that the code checking the branch name used the variable $(Build.SourceBranchName), rather than $(Build.SourceBranch), which means it discarded everything up through the last slash, yielding just soren instead of users/soren. If you’re not a Git expert, this feature is useful because the branch develop actually has a longer name, refs/heads/develop, and oftentimes you only care about the last part. But in my case, I certainly didn’t expect users/soren to turn into soren! I didn’t even know there was a difference between SourceBranchName and SourceBranch, because Azure DevOps often has multiple names for the same thing.

Let’s create some Anki cards so I don’t get confused by this again.

First, let’s tackle remembering that these two variables are different things. How to ask this question may not be immediately obvious, however! Our first thought might be to ask something like, “Are $(Build.SourceBranch) and $(Build.SourceBranchName) different things?”, but I don’t generally like asking yes/no questions, as I find they aren’t particularly memorable. We could ask what each of them does, but I know that the two names are similar enough that if all we do is that, it’s likely I’ll mix them up repeatedly during reviews, so that’s not a good idea. Here’s what I like to do with confusingly similar items: create a card that starts by asserting that they’re different, then asks what the difference is.

Q: ADO: What is the difference between $(Build.SourceBranch) and $(Build.SourceBranchName) when using Git?
A: $(Build.SourceBranchName) contains only the portion of the ref name after the final slash.

(I’ve added a couple of qualifiers: ADO makes the card context-free by indicating that it’s a question about Azure DevOps, and using Git is important because the answer is different if we have ADO configured to use a different source-control program.)

This card isn’t going to be enough by itself, though; while it’s an important piece of the puzzle, I haven’t directly tested myself on what I want to know: I want to be able to recognize, when I encounter one of these two variables, that the form $(Build.SourceBranchName) omits part of the branch name, while $(Build.SourceBranch) doesn’t. Rather than directly asking this question, though, let’s go for a pair of application questions that puts the knowledge in the context I’ll be needing it:

Q: ADO: If you have a Git branch master, what does the variable $(Build.SourceBranch) contain?
A: refs/heads/master

Q: ADO: If you have a Git branch master, what does the variable $(Build.SourceBranchName) contain?
A: master

These questions test the same knowledge. They’re also more fun and we’re probably more likely to think about them when the information would be useful in real life, since they focus on a real situation.

One more item worth adding on this topic: if I’m looking at incorrect code like the code I was staring at today without recognizing the problem, ideally I would notice something’s off and what the problem is. To reinforce this, I ask what I call “what’s wrong with this picture?” questions:

Q: What is wrong with this Azure DevOps template snippet?

${{ if eq(variables['Build.SourceBranchName'], 'releases/initech') }}:
    SOURCE_FOLDER: Release

A: $(Build.SourceBranchName) only contains the portion of the ref name after the last slash, so this will never evaluate true.

And there we have it! I’m sure there will be something else in the way next time, but if I keep adding enough of these questions over time, pretty soon I’ll be able to solve a lot more problems right away.