This post mainly targets software developers; however, the practices presented are already being applied with success by medical students, and people learning new languages as well.
The problem:
When I first started learning software development fundamentals a few years ago, I used to learn so much by simply reading or watching anything related to software development, and what made me learn even more is the fact that I’m a person who likes digging holes, if an article mentions a concept that I don’t know, I would go and find another article that explains that concept, but that blog post introduces yet another concept and I have to find out about that, and so on and so forth until I have 17 tabs open and I don’t remember where I came from anymore; during that period, I was focusing on broadening my knowledge; I felt bad because I knew I won’t be able to retain all this as I wasn’t necessary going to regularly use all of it anytime soon.
The solution:
I started using Anki; it's basically a flashcards program, you simply create cards, and the program will handle the rest, it knows when you should review each card to successfully retain the information on that specific card, it's based on active recalling, and spaced repetition; 2 years ago I wasn't sure about this whole Anki thing, but I decided to give it a shot anyway, today I can say with confidence that it does work, but don't just take my word for it, I highly recommend that you read Anki's own introduction, and Gwern Branwen's excellent article about spaced repetition these two are more important than this post, read them if you have the time.
I won't be exploring the program itself, it's relatively straight forward, and there are many great articles and videos out there that explain how to use it.
When I'm reading a book, I highlight the parts that I think are important, and after I'm done reading, I start creating Anki cards for the highlighted parts, I try my best to write "good" cards for each highlighted part, this is the trickiest and the most important part, things that I avoid are:
- Questions related to language syntax.
- Questions that only require remembering what a specific method does.
- Questions like this one: “Lessons learned from chapter 2”.
- Creating cards with long answers; it's better to break them down to multiple smaller cards.
- Writing sketchy answers: only writing the keywords in the answer, or using sentences like "refer to page x" or "read article y"; this is bad because you not only want to answer the questions, but you also want to answer them the same way every time, and having to go through an article every time isn't exactly going to help you do that; it's also bad because you're assuming that you'll have access to the book or the article that you're referring to when doing your cards, which isn't always true, in my case for example, I tend to do my cards using my phone when commuting to work.
What I do is that I write questions that help me develop my mental model for the topic I'm reading about, these are usually "why?" questions, I found this type of questions to be by far, the most effective; I also found that if there's an important part, and that part that has a diagram for it, then I can simply take a screenshot and use that diagram as the answer.
Sometimes I find that there's an important part that I just can't convert to a flashcard format, in that case, I use “cloze cards”, they're simply fill-in-the-blank questions; I use this type sparingly as I always try to create regular cards instead.
When you first start using Anki, you'll notice that you're spending relatively long periods of time to create new cards, this is perfectly normal, it actually indicates that you're putting effort into writing useful cards, don't worry thought, it gets easier by time.
Everything I mentioned earlier applies to video content as well, the only difference is that instead of highlighting important parts, I type them, and sometimes I mark the important timestamps and go back to them after I'm done; I tend to use screenshots more often when creating cards for this type of content.
There is one last type of cards that I use, I call them "implementation cards", I don't have many of them, and they're all combined in the same deck; I use them for questions that require actual code as an answer, for example I have a card for implementing quick sort, and one that requires me to convert a JavaScript async function to use promises and a generator function instead; again, I use this type sparingly, because answering this type is time consuming.
There are many discussions regarding the "perfect" Anki deck configuration, for me, I use the default configuration with two minor changes, I increased the maximum number of new cards to 50 per day, and reduced the maximum review interval to 365 days.
FAQ:
“But why memorize all of this? Just learn what you need as you go”
I learn a lot by simply googling problems that I face when doing my daily tasks, however, in my opinion, there are a few problems with this approach:
When learning something on the job, you’re usually trying to get something done, you don’t have the time to gain deep understanding of the problem or the solution; you probably won’t be able to see the bigger picture, or notice how the problem you're facing could be an indicator of a more critical problem; there is a good chance that you’re learning a single solution for a single problem, which isn’t necessarily bad, but you can certainly do better.
Leaning only what you need means that if you don’t face a certain problem, then there’s a good chance that you will learn little to nothing about it; if you’re a front-end developer, you're not going to face back-end related problems, does that mean that you should ignore everything back-end related? If you’re working with relational databases, does that mean that you shouldn’t read about noSQL databases? If you’re a fullstack JavaScript developer, does that mean that you shouldn’t explore other languages? Many people might argue that you shouldn’t, but I think you should.
Learning just enough is a passive way to level up, you should consider leveling up deliberately.
Also, if you have cards that cover fundamental concepts in your decks, then you should find technical interviews easier to do; you’re regularly reviewing your cards, so you won’t have to think about the phrasing of your answer during an interview; this also applies to implementation cards, they make preparing for white board interviews easier.
“Why not invest more time in learning by doing instead of doing all of this Anki stuff?”
learning by doing is great, however, there are a few things that you need to keep in mind:
- when learning by doing, you might find that you're re-discovering patterns,what I mean by that is you might find yourself trying to describe a problem or a solution that already has a name, knowing the term that describes a specific problem or a solution makes communicating it more efficient; for example, in React, I didn’t know that passing the same prop multiple levels down is called “props drilling”; try googling your own description for props drilling, then google “props drilling”, notice how the results are better in the latter search.
- always try to find similarities between technologies, even if they were completely different; for example, each operation in MongoDB's oplog is idempotent. That is, oplog operations produce the same results whenever applied to the target dataset, this is somewhat similar to how Redux works, if you call the same series of actions, you'll get the same resulting state, both of these behaviors are somewhat similar to the event sourcing pattern, they're not textbook implementations of it, but if you already understand one of them, you can use the same mental model to understand the other, and then you start to refine that mental model to accurately represent the new concept you're learning; what you're doing is that, instead of reasoning about a new concept as if it's completely new, you start to think of it as something close to a concept that you already understand well; it's important to note that you're not necessarily looking for "real" patterns, you're just looking for similarities that could help your understanding.
“What if I'm too busy to do my cards?”
consistency Is key here; even if you can’t do all the cards, then at least do some of them, the good thing is that even if you fail to answer some cards, you will simply see them more often, and you'll eventually have the answer memorized again.
Don’t feel bad if you have many late cards, the last thing you want is yet another thing that makes you feel bad about yourself; the fact that you’re reading this blog post is a proof that you’re genuinely trying to learn something, so don’t be too hard on yourself.
Top comments (3)
Hi Ahmed,
Excellent content and I was actually looking for something that anki does.
Can you share which templates in anki has been effective for you as a tech professional
Hi there!
this is my entire Anki collection, I hope you find it useful, it includes cards related to CS concepts, DOM API, JS, algorithms implementations, and other stuff as well:
google drive
and I apologize for the the late answer
Great article Ahmed!
I have a question in regard to your Anki rules for adding cards: Why don't you add syntax related cards?
For me it sounds like an impossible thing.