Ask HN: How do you learn complex, dense technical information?

Several other comments on this thread mention similar methodologies, as well.

Disagree: There's a grey area in the middle where it is costly to always look it up, but you don't do it often enough to ever be ingrained in memory. SRS is a fairly effortless way to cure it.

When I started my current job (somewhat math heavy), I didn't know enough background material. So I got put on a "side" project while I learn the main material. Unfortunately, that side project became fairly big so I didn't have too much time to study the bread and butter of that job. I would read a little from a text book every few weeks. Without SRS, there is no way that I would be able to do it. The frequency is low enough that natural reading would not preserve anything in memory, and it is one of those books that constantly refers to prior theorems/definitions.

> For programming, maths, physics, etc - "I forgot" means more or less "it is more time-efficient to google it once a few years than put effort in storing in in my memory".

You really cannot do mathematics well that way. When proving a theorem, you often will not even remember there is a theorem that could help you unless it's already in memory.

I once took a course on measure theory where it was a given that at least one question on each exam would be to prove a random theorem in the book. This was frustrating - since when should math require memorizing? And memorizing all the theorems? Sheesh!

When I was preparing for the final exam, I did attempt to memorize all the proofs. And then it hit me: There were certain proof techniques that were common to many proofs, and I had not picked up on it by merely doing the assigned problems.

This was a decade ago, when I did not use SRS (did try, but failed that time). Looking back at my experience in math courses, I realize that memory was definitely a bottleneck. Remembering certain theorems you took in a course a few semesters ago just wasn't happening beyond a certain young age (20). If I ever were to go back to math, I would definitely attempt some SRS use.

Of course, SRS alone won't cut it. You still need to solve lots of problems.

Oh, and after a decade of very heavy Emacs use, I tried using SRS to get better. And I did. A lot. So even heavy use isn't much of a guarantee that things will stick.

It's a false dichotomy. You can, and IMO should, do both.

For software, it's often about decomposing problems vs infrastructure to work on them. There's a great xkcd about that. Someone asks for an app that can take photos and tell if they're in a national park (easy)... but also tell if the photo is of a bird (incredibly hard). Lack of expertise is why people don't understand this. They don't recognize that they are two entirely separate problems, jumbled together as if they were one problem.

An area of expertise for me is playing guitar. Now, melodies are for the most part made of scales and arpeggios. So playing scales/arpeggios efficiently can be isolated from "music". And they're tied intensely to physical technique. So for instance, playing two notes per string is physically much different from playing three notes per string. By isolating scales and arpeggios into small chunks and practicing them independently, we can then easily integrate those chunks to form streams of melody, without having to do conscious thinking, because when playing music, conscious thinking is the enemy. It destroys rhythmic flow. But with a collection of instinct-level arpeggios and scales in my hands, I can just play, with my mind focused on emotions, ideas, and musical shapes, rather than which finger needs to land on which string to hit which note.

Programming is a lot like that. Once you've learned effective data structures, control flow, conditional behavior, etc, you shouldn't have to think about it much while you're coding, so you can focus on the problem, not the act of writing code. Or as I like to say, "That's not programming, that's just typing". And then you learn things like unit testing and TDD so you can free yourself even more from the line-level anxieties of the code.