Quite a few times, I got asked, "What should I memorize when learning Python?". I always answered: "Nothing! You will naturally memorize things that matter and others don't". Obviously, it is contextual - a backend developer will memorize different things than a machine learning researcher.
When we use anything, spaced repetitions come naturally (so it is also why our brain is tuned to them!). Artificial spaced repetitions are often helpful when we learn in an artificial environment - a new human language when there is little opportunity to practice it, things for an exam, etc.
With programming languages, as long as you have a computer, there is no reason to learn it without actually using it.
My answer would be to memorize useful facts that can't be derived from other knowledge. But put the most effort in building up fundamentals that can synthsize most usages.
Arbitrary things like obscure names, weird parameter orderings, mutated inputs, etc are all the sorts of gotchas that can be learned up-front if you care to know them before being bitten.
An example for Python is the del statement `del d[key]` which I find arbitrary and non-intuitive.
Actually when learning any language I usually learn the collections usages early--these would be good to memorize rather than repeatedly looking up and learning case-by-case as a time saving (non flow state breaking) measure.
For Swift it was all the weird call forms with keyword/symbols that move around rather than being additional parts of a complete form.
Learning parameter ordering is precisely a thing that I advice against memorizing. Just use IDE.
Other things - well, there is Google, there is StackOverflow, and now - also ChatGPT with GPT-4.
Sure, it might not be enough for learning (at least, not for everyone), but well enough to avoid needless memorization. Memorization always comes at some opportunity cost of using time (and, well, brain capacity) for something more fruitful, e.g., learning good programming patterns, wise abstractions, etc.
The 'parameter ordering' bit was specifically from using PHP for a stint. The standard library goes out of its way to make parameter ordering non-standard and inconsistent. Having to look it up constantly was such a flow-kill. My text editor back then wasn't so smart.
I'm fluent in Python, but had spent most of my time in 2.x. When I had to finally switch to 3.x, I went through all the 3.x release notes for new capabilities. One thing stood out: scandir was the preferred method compared to os.walk.
There's no way I'll remember that and I'd be too lazy to Google it. So it went into SRS.
Ditto for concurrent.futures (broke my habit of using multiprocessing directly).
The other use case for SRS and programming languages: There are always languages I use only occasionally (e.g. Emacs Lisp) So I'll never develop muscle memory. Using SRS significantly boosted my Elisp capabilities.
I don't code in JS, but I decided to take a course on it and put a lot of the stuff in SRS. I've almost never used JS since, but a coworker is using it in a project we're both working on. I was looking at his code, and pointed out to him various alternatives that he wasn't aware of (e.g. newer features since the time he learned it). Definitely would not have been able to do it without SRS. I can mostly read/understand his code. Again, almost entirely due to SRS.
> There are always languages I use only occasionally (e.g. Emacs Lisp) So I'll never develop muscle memory.
This is a fantastic use case that I hadn’t thought of.
One big problem with DSLs is that unless you use them on a near daily basis, you’ll keep forgetting how to use them. They really need to be worth the memorization cost that they introduce to a system. But SRSs can help.
I mostly agree, except if you only learn this way, you’ll end up missing a lot of non-obvious features of the language. E.g. writing your own function to do something you could do in a single standard library call, if only you knew it existed.
I programmed a spaced repetition system that integrates the doing, so that my cards aren't just memorization and theory. Each flashcard is a kata I have to program, and the program checks if my output is correct.
Perhaps, as long as you have a computer with access to chat AI, there is no reason to memorize the whole language.
Without chat AI, or an expert Q&A forum, it is difficult to search for the best solution for a complex problem articulated in its entirety.
What will end up happening is that you will convert your Y problem into multiple smaller X problems and search for how to solve those. You will design the solution to the problem in the abstract language of your mind using these smaller steps, and then map those steps to the programming language. You can much more easily look up smaller steps such as "find the index of a character in a string".
By the time you get to these small steps, you're imagining a detailed solution, whereas the language could offer something more direct.
One tell tale sign of this is code that contains functions which have exact equivalents in the standard library.
When you ask the programmer why they didn't use the library functions or built in syntax they will often say, oh I looked for something like that, but didn't find it; it was faster to just write the code than to look for it.
> With programming languages, as long as you have a computer, there is no reason to learn it without actually using it.
Spaced repetition isn't about learning, it's about remembering. From the article:
> Flash cards are for remembering what you’ve learned.
Flash cards are great for something that you don't use often but still want to remember. I use it a lot for CLI options (docker, ripgrep, etc), parts of the standard library that are useful once in a while but not always, algorithms, editor shortcuts. It also means that when you switch environments you can still remember everything.
When this comes up, I often see the criticism that it's better to learn by doing, because you retain what's necessary and forget the rest. On the contrary, that's exactly the problem this solves.
There are lots of things that you don't use day to day that it may be useful to have in memory when the need arises. That could be libraries, syntax, concepts, patterns, etc.
An example for me is CSS flexbox. I work with CSS just enough that when I need it, I don't want to sift through blog posts and MDN documentation to get what I need; I just want to know it. Chances are you can think of similar situations in your own work or personal life.
I think good quick reference guides are a better answer to that. Learning by doing is spaced repetition, with the added benefit of automatic tuning (you don't waste time learning stuff you never use).
In other words, you could equally say "I work with CSS just enough that I don't want to spend ages learning it via SRS; I just want to look it up when I need it".
The key is making looking things up as painless as possible.
Problem is, there are things you don't know you need until you know about them.
You can always code around not knowing your entire programming language or libraries.
Spaced repetition is obviously a tool for someone who wants to know all the nooks and crannies, in order to become a walking reference.
It could always be used for a subset. If there some 15% of some language you think you're going to use, and not much more, you could still SRS on that 15%.
Why not just google it? Seems like a better use of both time and brain space. Reminds me of Socrates complaining about how the kids these days write everything down and don't bother memorizing anything.
Why would you learn Spanish? If you got to Mexico you can just Google "how to understand Spanish" and then you'll understand it completely, just like in the Matrix.
While you are trying to Google the right thing and make use of the answer, you're missing the limited chance to be talking with people in Spanish, had you already known it.
Instead of Googling "how do I trim a string in {language}" you could be thinking about the problem you actually want to solve.
This seems like a case of comparing apples and oranges. Human language processing is largely based on sounds and requires extensive immersion to even be able to differentiate sounds, syllables, words, tone, etc. That is—you need a lot of training to even figure out what to look up (ignoring the tech-assisted technology that is still extremely rough in my experience).
There's no parallel to programming languages even in the slightest. Especially once you recognize patterns across syntaxes, the immediate value of understanding any one programming language plummets to near zero. Exceptions might be:
- SQL, just a singularly useful syntax to internalize. Probably also goes for datalog if you use that.
> "Especially once you recognize patterns across syntaxes"
That's where my original point is - you can't do that until you have internalised (memorised) several syntaxes well enough that they drop down to automatic and you can step back and look at the patterns. If your attention is on Googling for how to write a list, it can't also be on the problem you're trying to solve. If you want to read Rust you're going to have to know what the ' does and what & does and it will be very slow going if you have to google it every time - but I'm not even sure you could google it, if you didn't have enough background to understand the concepts, and still pick it up on the fly. Say a Python programmer trying to google C++ "syntax" without having used anything low level, ever, isn't going to be designing a good C++ solution, at best they will very slowly write Python-in-C++-with-bugs.
Which raises a second point - spend some time in C# world watching people write Java-in-C#, they're both curly brace OOP languages but they are different and the runtimes and libraries and common styles and frameworks are all different. Step out to people learning Prolog and APL and "knowing the syntax" is useless, the ways of thinking and solving problems are very different to mainstream languages. You aren't going to recognise the Prolog pattern `foo(bar, Baz)` because it's not a function call and you can't google "what do the parens do" and make any sense of it being a term with a functor and arity which could be a fact or a goal or a data structure depending on the context. Here, learning/knowing just the syntax isn't sufficient to know the patterns. Or spend time with people coming from Bash to PowerShell and assuming the only difference is syntax, when it isn't.
You can have conversations across language with Google translate. You take turns speaking into the microphone. It's actually pretty awesome. Obviously you probably aren't going to make best friends or fall in love this way, but you can ask almost any question and understand the answer in many languages without having had spent several years learning the language.
You probably also won't get that via learning a language via flashcards, either. That seems like an inherently different problem to solve than "memorizing a language".
I personally use Kagi, but "google" is really just short-hand for searching a specific resource (like, say, docs.python.org).
I suppose if you're googling an open-ended error with little context it's probably rougher now, but I don't see how you could possibly prepare for answering questions about arbitrary errors with no context via flashcards.
Who said anything about errors? I was referring to APIs. Often, I'll enter a Python standard library function as a Google search hoping to get to the Python docs so I can see the proper documentation for that function. It's quite often that the link to the Python docs is not in the first "screen" of results. Instead I get 3rd party sites that explain how to use that API.
For some APIs, it definitely saves more time putting it into the flashcard. The overall time it takes to type it, and then review it over the next so many years, can be less than it takes to search it, click, and then read the Python docs over and over.
As Michael Nielsen pointed out:
> In an appendix below I estimate that for an average card, I'll only need 4 to 7 minutes of total review time over the entire 20 years. Those estimates allow for occasional failed reviews, resetting the time interval.
(He's excluding the time to type, which could be another minute or so). So anything that takes, say, 10 minutes to repeatedly look up and read over your life is better suited to be in your flashcards. If you don't think you'll need to look it up often enough, leave it out.
Spaced repetition is great! Reading and making around 300 Anki cards out of Networking for System Administrators was one of the highest ROI things I did in a while - I finally understand at a high level how all those networking stacks actually work together, and I know a bunch of useful new command line tools to boot.
This is the basic idea behind https://python.cards, the site I'm building to learn Python with spaced repetition.
The hard thing is building the deck. With pre-built decks I expect to greatly reduce the effort required while getting most of the benefits of spaced repetition learning.
Writing effective cards is more of an art than a science, I've found—and seems to work best when you're the one writing the cards for yourself. A good resource for those interested in learning the craft is "How to write good prompts" by Andy Matuschak: https://andymatuschak.org/prompts/
However, he's also shown that cards can be written for a general audience with careful thought, see his & Michael Nielsen's work on http://quantum.country.
I was really fascinated with the idea of space repetition. For a long time.
I only have 1 problem. There is no good space repetition app on for smartphones. Websites & computer apps are just too clunky for me to use the effectively.
I would like to build one, but I really don't have a comprehensive on how the entire concept works and how to implement it.
Does anyone recommend any great books or resources that comprehensively describe space repetition & how to use it effectively
Every time I open the Anki app I really don't know where to start or how to use it. There are just too many options distracting me.
It would be easier if the features were reduced & the app kept minimal. Think the apple notes app & Google keep, but for space repetition. Anki feels like Microsoft Word.
Also a sample collection of decks with something to start learning right away (just to understand how the app works) would help me alot. Maybe a language, math theorems, APL verbs etc.
Which app are you using? AnkiDroid seems fairly straightforward, at least for basic usage. There are a lot of confusing options buried in settings, but the fundamentals aren't that hard to figure out. Maybe it just needs a better on-boarding experience, like a link to the download pages for a few featured decks?
Haven't tried it myself but it seems like a more modern/gamified version of Anki.
I wish there was a market place for spaced repetition decks on different topics/fields. It does seem like the closest thing we have to downloading a "topic" into our brain.
I'm not a regular user of Anki. But if I start again, how does it work when someone want to upgrade a package to a more recent version ? Does it merge correctly if I have added some cards or added some personal fields to the "Note Types" (and updated some card consequently) ?
I've wondered a few times about trying to sell a deck for some music theory stuff I want to memorize. Idk how much precedence there is for selling decks but it seems like it could easily be worth $5 or $10 to take the work of deck construction off someone's plate and just let them get cracking on learning it.
In C++, how do I declare a class? Should I put a ; after declaring it? And when creating a closure, what exactly &, = mean? When should I use std::cout and when not, and why? What exactly is the syntax for inheritance?
Ok, you can learn all that while using the language, but a card deck allows me to review it 5 minutes before sleeping.
For me, memorizing things like this is useful because context switching from flow state → searching something → back to flow state takes time and mental energy, and can derail me pretty easily.
As a complement, I would also suggest this thoughtful article with a broader perspective, explaining the proper place of SRS in learning to code to a professional level:
Anki needs a better answer for skipping a card than "bury".
There are times when you can't recall a card. But you can't move on to the next one until you answer it. You take a break for five minutes and, poof, you remember the card! In that five minutes, you could have reviewed more cards.
If you bury it the card, you won't see it until the next day; it doesn't play well into this situation.
Anki should let you review all the cards that are currently due in any order; i.e. move back and forth among them and answer them in any order you see fit.
I wrote a longish guide about learning to program from scratch using spaced repetition. I can't recommend it highly enough. It helps immensely in boosting you past the chasm of incoherence in the beginner stages when you are getting bombarded by unfamiliar terms. I included lots of example cards at the bottom.
It’s interesting to see different perspectives here. I often recommend spaced repetition for software and programming adjacent topics like networking, OS fundamentals, and many other areas, but I always recommend *against* using SRS/Anki for actual programming syntax. I find syntax cards to be low value, and surprisingly difficult during review.
I work with a guy that’s always saying he learns by doing and sidesteps explaining anything ever with that, or to cruelly put down a team member that needs some training.
I enjoy reminding him of my time in the army. We were just handed rifles and grenades and told to just go learn by doing.
When we use anything, spaced repetitions come naturally (so it is also why our brain is tuned to them!). Artificial spaced repetitions are often helpful when we learn in an artificial environment - a new human language when there is little opportunity to practice it, things for an exam, etc.
With programming languages, as long as you have a computer, there is no reason to learn it without actually using it.