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

But once we get past a certain stage, it’s more about connecting all the dots you’ve collected. It gets exciting as you get to see interesting patterns, and eventually get a sense of all the abstract ideas your learning materials where talking about.

Past that point, it’s faster, easier and exciting!

Just to clarify something in case it’s not obvious from my other comments. I’m not arguing for SRS as a replacement to all other forms of learning. You still need the extensive reading, problem solving, experimenting with a programming language.

However, I’ve found SRS to be a great addition to the methods above. For example, I haven’t found the methods above to give you long-term retention on their own. (And I’ve done a lot of problem solving.) Math is also a lot about building up the level of abstraction, and SRS can help with spacing the practice of lower-level concepts so you can more easily apply them to more complicated ones.

I’ve never been a fan of memorization in the past. However, I’ve found that:

1. Memorization (as in knowing foundational facts and being able to recall them efficiently) is actually pretty useful, as much as I didn’t want this to be true.

2. SRS can be used for thinking + deriving the answer to a card in addition to just memorization. It just gives you the right timing to do so.

If you write internal tools for a company then it is SO powerful to write a front-end without a back-end.

Ultimately this gets into a method of Extreme Programming (viz. waiting on features until the absolute last minute) married to the philosophy of Domain-Driven Design.

In DDD you want to establish Bounded Contexts for language, then within that context you want every programmer to speak in terms that clients could understand. Being able to change your data model cheaply is deeply powerful here as you can just give someone an interface saying “it won’t save your changes yet, just try it and see how you would do your day-to-day work with it and tell me what doesn't make sense.” And then they will say (assuming an accounting app) “what do you do with purchases that don't belong to a contract, how do I input them?” and you say “what do you mean, I thought we were tracking purchases for contracts?” And they will be like “A pitch is different than a contract, but we still purchase things for pitches but we don't need all of these details for it.” And you're like “if I were to show you a list of both pitches and contracts, like what would that be a list of?” and they reply “that would be a list of projects!” and then you build a list of all projects into your app.

And then when you build the back-end, you have one database representing the bounded context, and it has a projects table (UUID id [PK], string name, UUID pitch_id [nullable], UUID contract_id [nullable]), a constraint to make sure that exactly one of those IDs is NOT NULL, and a purchase table that foreign keys to a project. the key point is not that this is a clever database structure, but that it was molded to the hands of the people who use it, by delaying the binding of that data structure into a concrete relational form as late as possible.

For me, that's mostly not the case and I always start with trying to find concrete examples rather than abstract explanations. If it's coding-related, even more so. Most documented pieces out there are poorly written so code examples can help me explain the intention of what's written.