Building high quality anki flash cards is sometimes difficult and time consuming. When I first started when flash cards, I always asked myself when and why I should make a card. Sometimes it was a spur of the moment decision. Some cards didn’t last very long, or I had to mark them down because they were poorly worded. Other times those cards didn’t follow supermemos 20 rules, which I consider to be a standard goldline practice for making any flash cards for long term memory retention, regardless of subject. Sometimes I make a card which I found interesting but really had no application to any goal I am striving to achieve.
In this guideline below, I’ve taken a number of best practices from the medschool industry and applied it to programming.
1. Don’t make the cards right away, validate it
The first step in making good quality cards is to simply make them all at one time, once a week. You might be asking yourself why not make a card daily – of things you learn, etc. The reason for this is sometimes its difficult to validate how useful a card will be until you’ve been given a nights rest and think about it objectively the next day, or right before the start of the next workweek. The other reason for not making cards daily is it is extremely time consuming. Sometimes, I find myself having no time to even review my cards, let alone have time to write new ones.
With this being said, this is how I generally add new cards. In my previous post, Making an Annual Work Summary with Dynalist, I use dynalist to do weekly sprint logs. Basically, I look and see everything I’ve written down of importance that week – from coursenotes I’ve added, from project notes of things I’ve learned, to results that I’ve made toward my goals. Not all my notes will reside in dynalist, but so long as I keep a daily journal of everything I do, I can accurately remember everything I did that week.
Adding onto this idea of letting cards sit through a nights worth of sleep. Its also important to follow SuperMemos 1st rule “Do not learn if you don’t understand”. This is perhaps the most important rule towards making cards, and this is why its important to delay cards. So you can validate it in the mean time by writing code, through an exam test, through personal projects, etc. This also doubles up as a way so when you create a card, it also becomes extremely easy to review – since its been fleshed out over several days. This means you don’t have to worry about managing poorly written cards as often
2. Use your favorite notetaking application everyday to capture potential Anki Cards
Adding onto topic 1, while its important to give some time to think about what information should be made into cards, its also important to CAPTURE EVERYTHING you think might be relevant to that card. I personally use Dynalist.io as my notetaking application, but really, anything works – whether its a microsoft word doc, google docs, paper+pen, etc.
I’ve bolded information and tid bits of pieces of information that I thought would be relevant. These are words like “Code Generation, Parsing, Lexing, etc”, and they are bolded. This is the most important point here! You need to format your notes, such that when you start making cards for that one day in the week you’ve decided (usually Sunday or Monday), you’ll need to look at which information will become cards.
Its also important that you understand and break down information as well. Dynalist makes this pretty easy, by using bulletpoint indentations. This way, I can see that for instance, “Tokenizing/Lexing” is a subset of information related to compiler theory. When I start writing my actual cards, I actually need to sometimes cross-reference a 2nd or 3rd opinion to ensure that the information on the card is correct. You can see this here, when I cross-reference this information to posts on stackoverflow and freecodecamp, this helps ensure that I have high quality cards that have source information backing it. I’ve highlighted which URLs I’m referring to.
3. Decking And Plugin Strategy
I’ve discussed in my previous post on Anki best practices and formatting what I consider to be my favorite plugins for anki, practices, etc. The one I use the most currently is frozen fields by glutanimate. This lets me create cards quickly especially if the first question among my cards is more or less the same.
Before I dive into my workflow, I want to explain what my deck looks like. I only have one master deck (which has no cards in it), with 2 subdecks. That’s it. The first subdeck called “0-CS” are cards to which I personally validated following this one-week procedure – of lessons learned, and of important things I’ve taken from books, etc. The 2nd deck “1-Deduction” is mostly things where I am not sure of will work long term. These could be cards that are “fringe-tech”, essentially cards that have an expiration date as technology changes over time. These cards in the 2nd deck could also include things that aren’t entirely validated- I could be using it for say rote-memorizing a ton of API calls. Basically, the first sub-deck “0-CS” is highly validated and controlled, “1-Deduction” is sometimes full of fastly made spam cards.
4. Formatting Cards Quick
Now today is Monday. Or maybe its Sunday. I usually pick the end of the workweek or start of a new one to reflect on everything I’ve learned the previous week. I prefer doing this in the morning as well, since I tend to reflect on everything I’ve learned first, then I can focus on other work/personal related things after. You’ll want to make as many cards as possible now.
Whenever I write my cards, I have my notes open. I will look through the last 7 days of notes I’ve edited in dynalist. I search the last 7 days. These notes are rather lengthy (~10 pages) so I can’t necessarily show all of it here. But one of the notes includes things related to the stuff I wrote about compiler theory (the images I referenced above). Its also important to add look through any notes you’ve added elsewhere too – maybe through your emails, through reddit, through stackoverflow questions you’ve asked, things you wrote on paper and pen – now is the time to bring all this information out. ’
When I write my cards, I generally use a “Category Front Tag” which is formatted like
Category - Question. I’ve put two cards side by side to show how this looks like, and highlighted this
Category - Question format on the front of the card. Frozen fields makes doing this so much quicker – because once you write one card, you just delete the question and write a new one.
Because I use explicit “Category” like this, and I’ve taken these notes from my dynalist.io notes, I actually do not need to write a citation from where these notes came from (e.g. writing a source to a stackoverflow post on the back of the card, etc). This in turn saves time since I only make cards with just the bare minimal amount of information needed – saving lots of time. I also do not use “tags” at all that are built in with dynalist – it doesn’t add any value to me when I’ve phrased my “Category” phrase correctly.
5. Scalability and Maintenance
I made sure my decking, wording, and workflow strategy takes up as little time as possible and doesn’t cause problems down the road. I’ve also added another section called “Code” on my card (see previous image), which doesn’t actually show up anywhere. I only put this here since I added all my code snippets via screenshotted images, but I do need a rich text search reference if I need to look for that card in anki later. That’s what that field is for. Its also my only card type I use.
At the end of the day, I can easily search through in alphabetical order which cards I’ve added. For instance, all the things about compiler theory on my notes from YDKJS book appear right here. Later on I can just review the cards in my ankidroid app on my phone.