68 karma · joined August 22, 2013
I recently also started to review flashcards by printing the cards due today and writing down the answer opposed to reviewing them on a screen, and I have noticed a much higher retention as I am not distracted by the mere presence of the device.
1. A dictionary
2. A flash card creation functionality
Like the author said, understanding the card you're writing in your deck is fundamental. In my case, I would add, this is even true of when you add language cards. For example, I once added the word `thwart`. This card doesn't "cleanly" translate to my native tongue, and I was failing it at all times, I was confusing it with other words such as stifle, stymie etc because have a close meaning but not quite the one in thwart. Only after I grasped the exact definition and usage of it I started to not block on it anymore. I now attempt to be better at it by trying to also recall or make up the antonym of a certain word.
Also I started to create decks for:
1. Emacs commands, including custom shortcut which I use daily, or trying to drill new commands or features that I leant.
2. passages from books I read, mostly for those I use cloze deletions.
3. simple arithmetic, in order to be quicker at doing those without having to use a calculator at all times with me
4. shell commands, for example less frequently used git commands, grep or rg options.
A final note on using LLMs for flashcard creation. Sometimes the LLM can come up with some useful examples, or memory hooks, which help in retaining the information. Yes, I agree here with the author: out of 10 cards created with the LLM you're probably going to retain just one, and even that one will need rewriting.
All it fully tax deductible, amazing quality and even more flexibility when I have a meeting, for example ability to show my desk.
git config --global help.autocorrect 1
It will run the correct misspelled command after 100ms. For example git stauts will be corrected automatically to git status http://schacon.github.io/git/git-config.html
1. Change of behaviour between versions, (e.g. the way a frameworks integrate with a page)
2. Reliance on functionality being supported into the future
3. Customer expectations
4. Browser support
That said, it is true that a frameworks gives you the ability to put together an app in a few weeks. However, when you know that what deal with with something that needs to be maintained for years than knowing what does each piece of your code is far more important.