Include your Sources, Have a Single Answer, and Break-Down Your Cards
Here’s a flashcard related to Oracle SQL that was giving me trouble (lapsed 8 times and was automatically marked as a leech):
- Side 1: Collection (Oracle SQL)
- Side 2: Data types in Oracle SQL that lets you internalize parent-child relationships between tables in the parent table.
This was a double-sided card, so both Side 1 and 2 serve as the question. Let’s see if we can improve this one.
First things first: do I need this card at all? Yes: SQL is highly relevant to my career in Data Science, and the organization I work for relies heavily on Oracle database. It’s important knowledge for me that I didn’t want to remove.
Next, figure out the issue with the card. Looking at the card statistics, it turns out I was always getting Side 2 wrong. After some consideration, I realized that this is actually a poor definition of a “Collection”. In fact, it’s not really the “definition” of a Collection, but a characteristic of a Collection. In other words, the flashcard doesn’t have a unique answer: it’s true that a Collection internalizes parent-child relationships, but it does a lot of other things too.
I consulted the original source of the material and there isn’t a clear definition of a Collection there. I did some Googling for other sources and apparently there isn’t really a great definition of an Oracle Collection. It turns out that Collection refers to a generic programming idea not specific to Oracle.
So, rather than trying to define Collection, I’ve opted to break the existing card down into multiple cards, following Rule Number 4 of Knowledge Construction: stick to the minimum information principle, which means if you can break a card into multiple simpler, easier-to-answer cards, do it.
Card 1 (one-sided):
- Side 1: What Oracle SQL data type lets you internalize parent-child relationships in the parent table?
- Side 2: Collection
Card 2 (one-sided):
- Side 1: What kind of relationship does an Oracle SQL Collection help you represent?
- Side 2: Parent-child (aka “one to many”)
Card 3 (one-sided):
- Side 1: Does the Oracle SQL Collection data type internalize parent-child relationships in the parent table or child table?
- Side 2: Parent table
I also tracked down a good definition of the generic “Collection” concept in Computer Science, and added it:
Card 4-5 (double-sided):
- Side 1: Collection (Computer Science)
- Side 2: Object that groups multiple items together as a single unit (Computer Science)
I feel confident these cards will be easier to remember, cost less time and frustration, and help me remember the concept much better.
Lessons learned:
- Flashcards should have a single answer. Multiple correct answers for a card is a recipe for confusion and frustration. Interestingly, this isn’t included in Poitr Wozniak’s Twenty Rules for Formulating Knowledge, although you could interpret this as a form of interference (Rule #11)
- Keep track of your source material when making cards. It makes it easy to look up more details when needed.
- Browse related sources through Google search if you’re unsure about what to do to an item. This will give you more context around the card to see whether the knowledge is even required at all. You may also come across a clarification or better formulation. In the example above, I discovered the generic concept of “Collection” in programming and realized that it was futile to try to include a definition specific to Oracle SQL.
- Break cards down into a larger number of simpler cards. This is classic knowledge construction advice that is often not heeded, because it feels like more cards means more work. Counterintuitively, it is really a free lunch: you remember the concept better, you spend less time reviewing than you would have with the single complicated card, and reviews become much more enjoyable.
“Flashcards should have a single answer” this is the classic interference problem which may not have been directly referenced to in the seminal piece you talk about, but has been alluded to implicitly in the article.
Thanks for pointing that out…I still think of it as distinct from interference, but I added a note. Thanks for reading!