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

For an actual framework I always like to step thru a typical unit of work line by line in the debugger, from accept to write (I mostly do server processes). It is surprisingly illuminating to see how IO is managed and hoe the layers interact and fit together. It gives data to build a robust mental model of the framework. This is why I weep when I see some Spring backtracks with 100 or so stack layers.

>You have to take on the pain before the learning can alleviate it, if you try to skip the pain then you have only a superficial idea of what you're talking about. > [...] > Each of these tasks I am setting for myself needs to be answered by consulting tutorials and references, but if I just follow a tutorial I will not build true knowledge, I will just know how to do things when someone is holding my hand.

That makes so much sense, thanks for the advice. I struggle with this too much nowadays, I just try too much to reach perfection too soon when learning new technologies. Thinking about this made me realize how this wasn't how I started when I was younger. I wasn't going for perfection, I was going for something that worked. Slowly afterward I learned the more technical parts, mostly by need, and the best practice, first by need, but then by desire. Nowadays I think that because I can handle some pretty technical knowledge, I can start by learning that, but seems like I waste quite a bit of time doing this and it just doesn't stick in my head.

Next time I'll learn something, I'll start that way, a crude experimentation, and then see from there the next steps. Screw the best practice, that'll just be another experimentation down the line, could even be some rewrite of previous experimentation.

Hmmmm. Maths is one area where I have felt you hurt yourself by remembering things (except maybe definitions but then usually people state the current in scope definition in the preface or something). You can derive most things about as fast and more usefully than you can remember it. Except maybe a couple identities per area. But these will tend to be beautiful enough you will run over the derivation just for pleasure from time to time.

With enacs I find if it is not in my muscle memory it doesn’t matter if I consciously know about a feature. I can think “there must be some way of doing this” and then googling it and finding it as fast as I can stop my work and recall that in 2005 I used to have some good method of dooming this obscure use case of editing/process management.

Especially now with everything changing so quickly I find paying attention to the deep constraints and reserving the possible solutions from those conditions is more effective than trying to memorize a bunch of library or platform specific capabilities.

> I think I fundamentally disagree with the idea that learning = pain

I'm not OP and my interpretation is probably not what he meant, but when I saw that line, I wasn't seeing learning as pain, but more so as living the pain that justify the better practice.

> Project-driven learning seems more effective when the project is something that excites the learner.

I agree completely on that, but we can easily screw up that part by going too technical too quick. It transform a quick and fun project, into something much bigger (learning take a long time) with much less direct result. Fibonacci is a great example I think because it's so quick to achieve, there's so much potential to improve it in multiple ways, and it doesn't require much technical knowledge of the development environment.

When I tried learning React, I was going for a fun quick project, but then I thought, well if I'm going to do that, I'll go with some database to store my data, an authentication layer seems also an obvious requirement, all deployed in dockers, with some server rendering, etc... Which individually all could be quite simple to add in crude ways, but theses decisions all stemmed from the fact that I wanted to reach perfection from the beginning, which make all theses individual feature now become something much bigger and much more complex to reach. If instead I just do the same project, no database, just a big array that I modify, stored in a cookie, no authentication, no dockers, no server rendering, I can build it much quicker, and thus learn what I need to improve much quicker too. Afterward I can add a database if that's what I want to go for, and then authentication, maybe some server rendering afterward and maybe, a docker to deploy it easily.

Repetition of source text or other teaching material combined with hands on practical application of that material.