This post is originally written by JACK KINSELLA.
You can visit his website and read the whole post there too. I am copying certain parts of the post that I like and I need.
1. Screenshot Cards > Plain Text Cards
2. Focus On Available Functionality Over Detailed Info
3. Scrapbook Cards
To transform a photo of a code example into an Anki friendly question/answer pair I create a card with a question before the screenshot, something along the lines of: “What’s great about this code?". Within the answer I identify in bullet-points the strengths of the technique, forcing myself to identify and verbalize my learning, rather than leaving it as vague wordless appreciation.
Sometimes I invert this process and analyse awful code, making “What’s wrong with this?” cards, again constructing rules or prescriptions against what is bad. The eventual goal of both these processes is rapid perception of quality in my own programming.
4. Ordered Info Doesn’t Ankify Well
Simply means the ordered information in the form of separate cards won’t be shown to you at the same time. I’d rather keep and resort to an updated checklist or diagram of the ordered process.
5. Suspend Technology On Hold. Drill When Needed.
Means technologies that are seldom used at your work space and not much of use for you either. Just suspend them from popping up and review only when you think you need them technologies for your next project.
6. Lower The Intensity
When you accumulate billions of cards, your daily revision process could take a bit more time. To combat this I limited the maximum number of reviews in my programming deck to 40 cards per day and modified the deck settings within Anki to increase the easy bonus (extra time between cards you mark as easy) and the interval modifier (time between reviews of any card).
7. Numbered Reading
Whenever I read a printed programming textbook I place a number (1,2,3…) in the margin beside any point I wish to later commit to Anki, alongside a short reminder, e.g. “file system efficiency”. Once I finish the book I scan through it again, adding a card to Anki for each numbered point I continue to perceive as worth remembering.
8. Emphasize Language Invariant Memes
9. Execute Code For Yourself After Repeat Failures
When I become aware that I have failed a card a number of times I test that code in a console or do its equivalent (e.g. for Vim commands I tap the keyboard shortcut into Vim). I do this at least twice in a row. This helps my fingers learn the command, proves to me that the code works, and gives me contextual understanding, the effect of all these being that I am more likely to remember it next time.
10. Brainstorm “Uses For The Card”. Or Delete It.
11. Bold The Key Point
12. Best Practice Cards
Whenever I learned about a best practice‚ be that through pairing with a better programmer, watching a Play-by-Play screen cast, or reading a GitHub comment, I transformed the idea into a card.
13. Puzzle and Explanation Cards
Sometimes you do not wish to learn just facts and you need to learn a technique, methodology or mental algorithm instead. For these purposes (e.g. learning binary mathematics multiplication) I created cards with a puzzle in the question and its solution in the answer.
LastMod 2020-04-13 (643786e)