Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do you learn complex, dense technical information?
420 points by _benj on Feb 14, 2020 | hide | past | favorite | 175 comments
When in the past I've picked up a reference manual or something of the sort I'd go slowly, lookup every word I didn't understand and started experimenting as soon as possible.

But that is quite time consuming and intense. I've been considering skimming through the whole things to get kind of a big picture of what the thing is and where I'm going and then going back a second time to catch then the details and experiment.

Any other ideas? How do you tackle learning something new and complicated?

(ps. the complicated thing for me right now is kernel development, including writing proper C)




I do not have advice directly addressing your question about how to read, but I will say this:

A lot of this complex-dense-technical stuff is difficult precisely because it can get abstract. That is true for example in writing proper C for kernel development (your field) and physics (my old field) and chess (everybody's field).

My solution is to do lots of exercises and learn lots of examples before learning these big theories. Essentially I think learning is fundamentally Pain. 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.

So like if I am learning Go, I am writing a command line Fibonacci calculator in it, then I am rewriting this ground-up with test driven development so that I can learn what testing looks like in Go, then I might try to build an HTTP server, then I might connect it to a database, then I might learn how to mock the database. 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.


>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.


I totally respect your opinion, but I think I fundamentally disagree with the idea that learning = pain. Project-driven learning seems more effective when the project is something that excites the learner. I might suggest that your ability to learn test-driven development in Go is actually driven by the fact that you're interested in Fibonacci calculators.


Interestingly there is a concept in learning research called "desirable difficulties". The idea is that learning something, forgetting it and then struggling to learn it again leads to faster learning times. It may be that struggle is inherent in the process of learning something complex. If you equate struggle with pain, then I think it makes some sense. I have found that the best learners I know are also a little bit obsessive. They can't let go of a problem. So for them, the struggle in inherent in the way that they operate. For others, I think, the struggle can seem daunting. I think it's reasonable to suggest to those people that when learning something complex you are likely to place yourself in uncomfortable situations. However, it's important for those people to realise that the discomfort is not harmful and, in fact, can be challenging and rewarding.

Often I think it is quite similar to the situation where some people can not conceive of doing endurance sports. They view it simply as pain, or at the very best boring repetition. Others thrive on it. But if you want to learn how to enjoy endurance sports, it's probably a good idea to acknowledge that there will be times where you will be uncomfortable (possibly intensely so).


> 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.


One way I try to combat that is by forcing myself to do things the simplest way (unless I am aware I'm making a technical decision I can't change later). Then I try to add more complex bits when necessary. As a bonus you learn the skill of "refactoring" etc.

For example, nobody is forcing me to use Docker from the start. I don't have to use it until I decide the development or deployment pain is big enough that I will learn how to use Docker. Similarly, why do server side rendering when you can have a perfectly working project without it. Add server side rendering later, when you project actually has real features. Not from day one. The temptation to use cool tech from the start is difficult to ignore at first, but after a few attempts to do a side project, only to give up before you've even started, it gets easier to appreciate stack simplicity :)

Trying to keep code as simple as possible from the start is more difficult, i.e. you might be structuring your code too naively and regret it later when you try to refactor. But as we know, abstracting too early creates similar if not worse problems.


Hey! I wanted to just tell you if you see this comment that your approach is more important than you may realize.

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.


If you think that I am interested in Fibonacci calculators... I mean you are not wrong: I have a Gist I think on doing Fibonaccis by matrix exponentiation which is kind of fun. But in this particular case, no, I don't need to calculate Fibonaccis for any particular reason. It is just a nice project that I can do recursively and then refactor iteratively, and it requires getting some ideas about retrieving environment variables (is Fib[0] 1 or 0?) and command-line arguments.


I think NPM ecosystem contracts your thesis. People find it too unpleasant to buckle down and type out that combination of string functions to left pad. It is less cognitive work to down load some library. When I was younger the learning was easier but even then learning is etching new groves in your brain. If it doesn’t feel like you are changing your biology you aren’t getting real deep learning. Not that learning isn’t sprinkled with moments of happy enlightenment. There comes a moment when to truly understand something you have to totally push against it. I am presently learning AWS, AWS api and terraform. It is exhilarating and also very hard. First month or two I collapsed asleep at the end of each day and dreamt of HCL and so on. Now, six months later, I can help my coworkers get around obscure gotchas in AWS and terraform.


> People find it too unpleasant to buckle down and type out that combination of string functions to left pad. It is less cognitive work to down load some library.

That's not the case though - why would I reinvent the wheel when I have finite time to get something done? I love to suss out solutions to all sorts of things on my own time, but if I have to left pad a field, I've already got lodash, I'm using that.

In addition, when someone goes back to read the code "_.padStart" just makes sense to read.

I'm not saying that understanding doesn't lead in repetition and effort, but I think you're wrong on why people use libraries. It's not because people don't want to know, they gotta get whatever it is they are working on done.


Another reason to use a library is once you write that left pad function yourself, you have to go copy it around from project to project whenever you need it, then fix or improve it and copy the changes all over again. Second time you do that, might as well pull it into a library. And now you have a library that you lug around, might as well host it somewhere. In a few short decades you roll your own package management infrastructure and fill it with all kinds of useful things like string concatenation subroutines and macros for flow control primitives built on jmp instructions and stuff like that.

Might as well shortcut all that and see if there is something in standard library or in an existing package...


I approach languages in a similar way. I will often start with solving Project Euler problems in the new language, then I re-implement my perennial favorite project (a password manager) using the new language (mostly the server side and command line client). It's a long and hard way to do it, but I actually learn the language instead of knowing how to copy paste from Stack Overflow and Google even little things like "How to get substring in <lang>"


I wouldn't be so sure that "learning = pain". This could be very different among personalities, ages and cultures.

People who enjoy video games and trying new board games are constantly playing with new rules, because they like it. If for you "learning = pain", it maybe a sign that you simply lost interest in what you initially wanted to learn. You might still enjoy learning about something entirely different.

I guess age could also be a biological factor to learning aversion, but that would require solid scientific results to prove.


I agree, except for learning = pain. I find that, like most things, it’s all to do with context. If I’m “forced” to learn something (e.g. exam, deadlines,etc) I find it painful. If I’m doing it on my own, with no pressure, I find it enjoyable. And I think it’s independent of subject (having started some subjects as a requirement but then moving on to learn them as a hobby).


It's a weird feeling when I don't know how to do something so I practice a lot and I then still don't "know" how to do it but somehow I can do it.


Indeed, this is the subconscious aspects of your brain presenting information to your conscsious parts. I notice this too! It's amazing, and I think it's where the whole "gut feel" comes from.

If you're interested in more of this stuff check out "The Believing Brain" by Michael Shermer, and "Consciousness Explained" by Daniel Dennett.


Then the best part comes next: you read some more theory again, and suddenly it connects - the abstract becomes understandable in the context of pains and solutions suggested by gut. And now you have a solid piece of understanding you can reason from.


I always save the big picture books for after a bit of successful hands on stuff. Often then i want to go back and redo the original learning efforts.


Quoting Linus on a topic directly linked to what you're studying[0]:

> Because you should never ever think that you're clever enough to write your own locking routines.. Because the likelihood is that you aren't (and by that "you" I very much include myself - we've tweaked all the in-kernel locking over decades, and gone through the simple test-and-set to ticket locks to cacheline-efficient queuing locks, and even people who know what they are doing tend to get it wrong several times). There's a reason why you can find decades of academic papers on locking. Really. It's hard.

This is only about a single area of kernel development. While not really about how to learn something quickly, I still think one thing that's very important is keeping in mind that learning complex things takes time, potentially a lot, and that it all depends on your objectives, i.e. what level of understanding you want to achieve. So maybe your method of learning is actually what's working best for you. Maybe the speed at which you grasp concepts and internalize learnings is not as fast as you'd like, but maybe going faster would leave you with shallower knowledge.

That doesn't mean you shouldn't look for more efficient ways and methods of learning, but I think it's still important to keep in mind.

[0]https://www.realworldtech.com/forum/?threadid=189711&curpost...


I am fairly sure this is not the optimal way, but I've been learning complex information/structures in passes.

For example:

- 1st pass - I consume the materials as well as possible, and apply my knowledge. Typically, I have to look things up, some things are unclear, I can't remember much. Applying the knowledge is quite difficult. That's ok.

- 2nd pass - I return to the materials, re-read much less thoroughly. I realize some things that I missed, or got wrong. I apply my knowledge, without looking information up again. This is, from my experience, when I get most of deeper understanding, but also where I learn most things that I remember long term.

- 3rd pass - if necessary, I can go through the materials again, just like in the 2nd pass. Diminishing returns start to kick in.

- (3+n) pass - diminishing returns start to manifest even in form of being bored with the materials, and starting to build up mental dislike for the materials/topics.

The passes are effective if and only if they are some time apart. Ideally, they are spaced in increasing time, i.e. 2nd pass is a day after 1st pass, but 3rd pass might be 3 weeks after 2nd pass.

The above has been useful for me, for example, when learning math or when I started to learn development way back. Note that in all passes, knowledge is applied. Without applying the knowledge, I learn much much less (though not nothing).

It also assumes that you have quite good theoretical source of information (e.g. a math textbook) and practical problems (e.g. math problems with correct solutions). If you're missing one or the other, e.g. if you're memorizing history lessons for your history 101 test, I'm not sure how effective the passes are.


I do this in reverse. First blaze through reading with very little comprehension, then go back thoroughly.

My reasoning is "I don't know what I don't know" on the first pass and my first goal is to understand that all of the things "exist", then how things individually work.


Me as well. In one of my CS courses, I was recommended Keshav's How to Read a Paper (https://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/...) which I have adapted to all kinds of technical material, not just papers.


I also do this. A trick I've learned is to grab a PDF or Word or any editable copy of a document, then highlight sections with various pastel shades to indicated "don't care", "maybe care" or "get deep". Then on the second pass I can focus more intensely on the sections I need to get deep on.

Another trick I've learned is to find an older copy of a specification and read that first. Usually the older copies have less bulk, are more directly addressing the core conceptual issues, and are easier to read.

Sometimes if I want a rapid and superficial understanding I just go after the diffs or change notes for the last few versions of whatever it is. This can give a scattershot coverage of the contemporary state of the thing. It's not much but it's a place to start from.


I do the same. First pass is mostly getting a feel for what the extents and pieces in the system are, and getting familiar with the vocabulary. Then one can search targeted and efficiently afterwards when working on a task.


This is my philosophy as well. Start by touring the forest quickly, then go back to appreciate the trees. When learning technical material, the first pass means skipping any exercises.


This is my exact approach - get familiar with the vague concepts and where you might use them, having lots and lots of these concepts to dig through in your head can be extremely helpful - then go back and learn in detail when it seems like one might be applicable to a given situation.

In defense of the other people here - often doing this properly involves a bit of a dense pre-read to make sure you can at least understand where these might be applicable. With a totally new area to you there's a big learning curve there.


For me, it takes multiple passes too, but their quality varies significantly depending on how familiar I'm with the subject. If the subject is challenging and truly new to me, my approach is more or less like this:

On the first pass, try to understand as much as possible, but don't push too hard if I hit a road block. It's OK to not fully understand or be hazy on key details after the first pass.

Then take a break, and ideally work on something else, sometimes for a for a day or two, until I feel ready to take another pass. Also, go for walks or watch a movie or do something else that takes my mind off the subject. Try to explain things to myself, to get a sense of which things I don't really understand.

On each subsequent pass, spend time only on those things I don't really understand -- until my little brain gets tired or I hit another road block.

Then take another break, and ideally work on something else, until I feel ready to tackle again. Again, go for walks or watch a movie or do something else that takes my mind off the subject Try to explain things to myself, to get a sense of which things I don't really understand.

Keep doing passes like this this until I can explain everything to myself because I fully understand it.

Throughout, I look for and rely on informal explanations, friendly tutorials, video lectures, and other auxiliary materials that can be readily found on the Web. Also, try to replicate experiments, do exercises, and/or write code if and when applicable.

My approach is best described as "long-term persistence."


Overall similiar to this, except I get a pencil and a couple of sheets of 11x17” paper and I incrementally build concept maps[0]. These help me memorize entities and relationships, identify abstractions, chunk details, etc. I also use Visual Understanding Environment[1] and there are other good concept mapping tools available.

IMHO mind maps are a more recent, dumbed-down subset of concept maps. I don't use them. My daughter has been using the 11x17” paper and pencil approach for the past few years to ace science and other subjects.

[0] https://en.wikipedia.org/wiki/Concept_map [1] https://vue.tufts.edu/


This describes my process as well. I'd add that one of the huge benefits of the 1st pass is that it is low pressure. You just have to get through the material.

For example, I put off SICP for a very long time due to not wanting to put in the time for the exercises. Eventually I just decided to take a first pass, and made I through in a month. Second pass did the exercises.


I'm a big fan of the idea of using Spaced Repetition for this. The idea is that it allows you to both:

- be able to keep your knowledge / understanding of an area around for the long term; but also

- be able to gradually build up your understanding by first committing the fundamentals to memory, and then using that to build up your level of abstraction and get to the more complex ideas and principles.

Michael Nielsen has written fairly extensive explanations of two slightly different approaches in:

- Using spaced repetition systems to see through a piece of mathematics [1]

- Augmenting Long-term Memory [2]

I've only used this particular approach for a handful of subjects so far - indeed, it seems to just take time to build a high-quality, long-term understanding of a thing. However, I've been pretty happy with the process so far.

[1] http://cognitivemedium.com/srs-mathematics [2] http://augmentingcognition.com/ltm.html


Personally, I am a big anti-fan of the Spaced Repetition.

IMHO it is a wonderful solution to a wrong problem (i.e. memorizing random things). Sure, there are use cases: learning words in a language one is not exposed to on a daily basis or cramming for a medical school exam.

When one actively uses something, there is a natural spaced repetition of the things that matter. With the frequencies as these things are used in practice. Everything else can be looked up later.

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". In programming, it is even more the case: libraries, their APIs, and good practices keep changing. Rote memorization may be highly counterproductive in this case.


> When one actively uses something, there is a natural spaced repetition of the things that matter. With the frequencies as these things are used in practice. Everything else can be looked up later.

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.


My general practice with mathematics is and Anki is to:

1) Understand the material I'm learning. 2) Put explanations of any algebraic procedures (for instance, the dot product of two vectors) as a flip card. 3) Put a single example of doing the work in a flip card.

For important proofs, I put them in Anki using Cloze deletion. I just drop in the whole proof, and knock out portions. This has been extremely effective in remembering and understanding the proofs. I also do this for geometric explanations of procedure.

This is definitely not overkill, and creates cards that you can go over really quickly. Ever since I have begun doing so, I have found that it is far easier for me to apply what I have learned, and that I can more easily understand the options that I have for finding solutions to problems, because I have all of the options available without requiring me to look over old information. It's just there.

Ever since taking Barbara Oakley's classes (Learning How to Learn and Mindshift), I have been a more productive and emotionally stable human being, and my ability to learn and understand the information that I am learning has exploded. One of the most important things I remember mentioned in that class was that memorization and understanding are actually quite tightly linked.

There are things that I have dealt with in the real world that would have been solved by math lessons that I've forgotten since I left University twenty years ago. I was never very good at studying because of anxieties and procrastination. The simple fact that I know I'm going to put information into Anki allows me to concentrate and gives me procedure no matter what I'm trying to learn, regardless of source (readings, lectures, etc.). I wish I had this ages ago.


> For important proofs, I put them in Anki using Cloze deletion. I just drop in the whole proof, and knock out portions. This has been extremely effective in remembering and understanding the proofs.

Thanks - I still haven't used it for mathematics, but this is good to know. I do have a few proofs of theorems in statistics in my flashcards, but the whole point of the cards is to spend only a few minutes a day on them - and doing a few proofs requires a paper, pen, and time. So I keep those in a separate deck and do them only when I know I have time.

My concern with mere cloze deletion is that I'll likely get the illusion of understanding without real testing (being able to rederive something is a real test). I'll likely go for a hybrid approach - full proofs in a separate deck and either proof sketches or cloze deletion in the regular deck.

> One of the most important things I remember mentioned in that class was that memorization and understanding are actually quite tightly linked.

This stood out to me when I took the course, although my memory of it is different. I don't think she said memorization, but "covering it and reproducing it in your own words" - the latter requiring understanding. But yes, she claimed that the research showed this outperforms things like mind maps, and that nothing has so far been shown to outperform this.


I’ve done some cloze deletions for math and related things, but I generally feel like having almost the whole proof in the prompt gives me too many cues. It often leaves me thinking that I indeed wouldn’t be able to come with the answer with fewer hints.

What I’ve tried the last couple of attempts is to “chunk” the proof (also terminology touched on in Barbara Oakley’s course) so that I end up with a question that’s something like “what’s the high-level idea / approach in the proof for X?”. That card would likely require an understanding of some underlying concepts or “chunks”, so I add questions for these too until I get to something that’s less abstract and easier to rederive.

I’m still not 100% confident if this will work well when these particular cards get into the 6-month range or so, and they start showing up at completely unrelated times. My main concern is that if I’ve forgotten some idea from “the middle”, it would be hard to reason about cards that build up on top of that.


"Covering and reproducing in your own words" is a combination of recall and synthesis, both necessary for remembering. This was a different section, and it might have been the Mindshift class, where she mentioned in US schools, we focus too much on understanding and conceptualization, while in Chinese schools, it's mostly memorization. Unfortunately, the two ideas only really work optimally together. Either model produces extremely well educated on occasion, but if you use both, then anyone can not only educate themselves well, but retain it for a far longer time period. Further, understandings of subjects are compounded by the memorization process. In my own practice, I've found this to be true, but that's anecdotal. Some nation is going to get their act together and try this on a larger scale, and I can't wait to see the output.


Well, I finished a mathematical physics PhD, without a hint of SRS.

During my undergraduate time I knew people memorizing instead of trying to understand theorems (especially ones with background in chemistry). Often they got good exam results... and almost never it helped to build a bigger picture, or do research in mathematics.

That said, I have ADHD and any small-dose-but-regular learning (typical for classes!) was painful to me (and not to effective).

YMMV.


> During my undergraduate time I knew people memorizing instead of trying to understand theorems (especially ones with background in chemistry).

As I pointed out in another comment, this is a false dichotomy. You can do both. I contend that one who attempts to understand and memorize will know the material better than one who doesn't. The thrust of my argument isn't that it is necessary. It's that you will gain from it. Of course, if you make that your only tool in the toolbox, you will suffer.

And I never claimed that not memorizing will prevent degrees. I'm sure while in grad school you came across plenty of less capable people than you who nevertheless still got a PhD ;-)


I would be curious as to any techniques you used to overcome this painful regular learning. I find certain 'plain' tasks (for lack of a better word) excruciating.


Read "Driven to distraction" https://www.amazon.com/Driven-Distraction-Revised-Recognizin..., you may resonate with some of these points (even if you don't experience a full-blown ADHD).

In my case, well, if something really needs to be regular, the only way to go is external pressure (external deadlines, people meeting at a given time with the goal to learn) and bringing some intensity (instead of 1h learning, a day focused on that).


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.


> 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.

To derive things, you need to have memorized a basic set of theorems. As you go deeper and deeper, the "stack" gets bigger. If you only memorize the very basics, there's a good chance you will not be able to derive the deeper stuff whenever you need it.

If you are in second semester measure theory and you haven't ingrained a lot of the first semester of real analysis in your head, you likely will do poorly. Quick: When is a closed set not compact? If you do analysis a lot, you can easily answer this question. However, if you do it only occasionally, not knowing this will limit you (or even worse, and common, believing that all closed sets are compact).

I used to be in the camp of "Memorization sucks - just solve enough problems and it will stick". Its only recently that I'm realizing I was wrong. Everyone will have things stick if they do enough problems, but also everyone will have a different capacity for how much sticks. You'll hit your peak eventually by just solving problems, and a better memory will take you further beyond that small peak. Once you realize how effective SRS can be, you don't want to be limited by a poor memory.

> 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

Often when reading the org mode manual I'll come across something that makes me say "Oh wow, I wish I knew this keybinding" and then would promise to remember it or look it up when needed. It's depressing how often I've said that about the same keybinding. Now that I use SRS, this phenomenon still occurs, but at less than half the frequency it used to.

Although to be frank, I now use hydra on Emacs often, so it's not as common for me to memorize keybindings.

> 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.

Emacs is timeless :-) I will be using it for probably as long as I can use a computer.

But yes, I would be selective on what to put in SRS. Reviewing takes very little time, but creating new entries is time consuming. It needs to be worth it in the long run.


Yes. This is spot on. Another issue is losing the larger picture.

In the language learning example, Extensive Reading leads to not only picking up and remembering words, but also collocations, grammar and even cultural beliefs of the speakers of the target language. Single word flash cards miss all of that. Full sentence flashcards do a bit better but still fall short.

I think the best use for SRS for something like a language or programming is for laying down a scaffold in the very early stages of learning, and then moving to more productive uses of study time as soon as possible.


Do you have any suggestions on alternative methods, personal or otherwise?


Their suggestion is in this sentence:

> When one actively uses something, there is a natural spaced repetition of the things that matter.

So if you're trying to learn react, don't try to memorize the API. Just use react and you'll naturally have spaced repetition of the important bits. The unimportant bits that are rarely used you'll have to google when you occasionally need them.


I agree, but with something like react, I may use SRS to memorize the order of the lifecycle methods, etc.


I second using SRS--it's been very helpful for me to remember API minutiae or commands that I would otherwise have to google each time I needed it.

For programming topics, I also try to make sure I'm using the information. I unfortunately have too many cards about topics that I never actually used, and they are frustrating upon review because I never had some practical structure to place them into mentally. Don't waste time trying to memorize thing you don't ever use.

That said, SRS is good for memorizing trivia if you want to do that too. I've been using the Anki deck Ultimate Geography for a couple of months to memorize every country, capital, their flag, and location on a map. Useless, but kinda fun.


SRS is great for memorizing truly unconnected pieces of information, like names of capital cities.

For anything where the information is connected, it's a lot better to use those connections instead of drilling it in a decontextualized fragments via SRS.


> it's a lot better to use those connections instead of drilling it in a decontextualized fragments via SRS.

Or, you can use SRS for "spaced repetition" of making these connections. That is, instead of treating it as rote memorization, use it for the timing effects. When I see a card about X1 which is part of a larger concept Y, I don't think "what was the exact answer to X1, which I remembered without any understanding and will just recite now?".

Instead, I often think "how do I come up with the answer to X1 right now? how does it connect to the larger concept Y?". Even better, if I've recently seen card X2 about the same concept, I might think "how does X1 relate to X2, which I just saw recently?". Sometimes, this actively helps you to make new connections. Of course, you need to explicitly make an effort to do so, yourself. If you practice pure recall only, that's what you'll get from SRS.

As another commenter mentioned, it's a false dichotomy.


Maybe this will be a clearer explanation of what I said: https://alchemist.camp/learning-machine/spaced-repetition-sy... (starting at 11:27)

> "[00:11:27] These SRS flash card apps are very good for learning vocabulary and depending on what's included in the flashcards, they could be for grammar as well. But the problem for a language learner is that it's de-contextualized. So say if you just study vocabulary words, then they're going to be a lot of things that you'll miss like collocations. You won't know which words are normal to use with which other words. For example, in English, if someone asks, "How are you?" it would be completely normal to answer, "pretty good". It would also be fairly normal to answer, "absolutely fantastic". But it would be strange to answer that you're doing "absolutely good". There's no grammatical reason. It's just not something that English speakers tend to say.

[00:12:17] And there are many, many, many language features that are like this. There are also questions of word boundaries. For example, in English, the word "nose" refers to a person's nose or a dog's nose, but not every kind of animal. For example, an elephant in English doesn't have a nose. It has a trunk. In Japanese, the same word, 鼻 (hana), is for a person's nose and the elephant's nose. So the question is, what exactly does "nose" mean? Well, really tedious language teacher could explain this for every single word that you study, or even put this on the back of every flash card for every word that you're reviewing. But, it's not going to be efficient. You'll spend so much time worrying about edge cases for every single word that you're learning that you're actually not going to get anywhere.

[00:13:11] The solution in language learning is extensive reading. If you do a lot of reading and the material is easy enough that you can go at a decent speed, then you'll just get so much input that you'll have a feel for what words are used when and you'll know what the specific definition boundaries around though are. And of course, it's not just language learners that have this problem with spaced repetition systems—that everything is reviewed out of context.

[00:13:11] You might remember from when you were younger and taking math classes, there were certain techniques that you had to get good at or you had to be able to do at least on some tests, like say, use trigonometric identities and some information to figure out how tall something is or how far away it is or completing the square to derive the quadratic formula... something like that. Mastering these kinds of problem solving techniques has the same sort of issue revolving around context. If you just mechanically memorize each piece of a method, you won't necessarily be able to apply it when you're given an actual problem on a test or any other situation.

[00:13:41] On the other hand, if you put the entire problem into a flash card like say you just write out a math problem and that's the cue part of your flash card, and every time you see that card, you have to solve the whole problem. Well, that's going to take enough time that you won't be able to do those problems very often. You might want to do it for some really important things, but it can't be your go to study method.

[00:14:55] Similarly with programming, you can memorize a lot of things about a programming language, but you're not actually going to learn that language or learn how to program at all if you don't write programs and if you don't have the experience of making mistakes and then the experience of debugging those mistakes and fixing your programs."

Trust me, this is an issue I've thought about a lot. I contributed to Anki in the mid 2000s, have previously made 10k+ decks I used for years and spent two years trying to integrate them into a curriculum for other students.


Cool, I’ll take a read.

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.


> For anything where the information is connected, it's a lot better to use those connections instead of drilling it in a decontextualized fragments via SRS.

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


It's not a false dichotomy because time is limited.

Every minute spent on flashcards is a minute that cannot be spent on more contextualized study.


> Every minute spent on flashcards is a minute that cannot be spent on more contextualized study.

I often spend less than 5 minutes in the morning on my flashcards. There's not much deep contextualizing you can do in 3-5 minutes. Certainly not in areas like physics.

It is a false dichotomy. All minutes are not equal. I'll gain much more by spending less time on HN than by cutting out flash cards.


I find that my brain sort of automatically uses connections. The really interesting thing about SRS is that you don't have to consciously think about how you're going to remember the cards. Like, you don't consciously think, "Ok, what's the pattern here, how can I turn it into a mnemonic..." Rather, your brain subconsciously does that for you.


I have used SRS and found it powerful, but not that powerful. SRS only commanded the times of rehearsal but not the way memory consolidated. And it consolidated by creating connections. So I needed mnemonics, prompts and all the likes, on top of SRS.


In my ~20 years of experience, the only way to get good at something that is incredibly complex like kernel development, you will need to actually try to build the thing. Over and over and over. It doesn't matter what those reference manuals or books say. The computer doesn't give even the remotest feasible shit about the implementation reference or some particular author's opinion. Your tools do not know you are a noob trying to become a master. There is no gradient to follow that will allow you to meet this challenge in a fair way.

Many times, this frustration just boils down to cleverly-disguised subconscious procrastination. For me, the fear of trying to do the hard thing and failing at it is ultimately what keeps me from engaging certain things. This is a good sensibility to have so you don't bash your head against the wall, but sometimes you have to override it, start writing code, and accept that you will make some horrific mistakes. There is a light at the end of the challenge tunnel, that is if you actually begin to overcome it. This is one of the most addicting sensations I have experienced and I find it can carry me the rest of the way to mastery. That feeling you get when the browser actually loads your first web application, or when the ipsec VPN tunnel you've been fighting for days actually connects and you can ping both ways. Finishing a YouTube video or a chapter in some C kernel development book will never give you the same result.


Similar to what others have said, do a quick pass once to get a sense of what the context/main concepts are. pass 2) read the headlines of each section. pass 3) read the bold words of each section and make note of them. pass 4) read the first and last sentence of each paragraph in the chapter. pass 5) read the whole chapter as you normally would. The increased/repeated exposure helps you to contextualize/relieves anxiety associated with unknown terminology/concepts.

Make notes and use "chunking" to group similar ideas into groups and build up from those. It's easier to learn a bunch of small pieces and combine them, than it is to attack an entire subject all at once.

Use multiple sources and YouTube extensively (lectures/enthusiasts explaining difficult concepts). Sometimes a slight tweak to how a topic is presented, along with the context from past passes in other sources is enough to improve understanding.

Work through problem sets and free-recall to avoid cognitive biases of thinking you know some material better than you actually do.

Spaced repetition systems like Anki.

Experiment with all of these (and other approaches) and be objective about which work best for you.

Some helpful resources I've found over the years are:

https://en.wikipedia.org/wiki/How_to_Read_a_Book

https://www.coursera.org/learn/learning-how-to-learn

https://www.khanacademy.org/science/health-and-medicine/exec...


Something similar to this is the SQ3R method: https://en.wikipedia.org/wiki/SQ3R

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


Thanks for the link. I watched a YouTube video[0] about this but the guy never gave it a name.

https://youtu.be/nqYmmZKY4sA


Never heard of this before, thanks!


I've learnt recently (not much former higher education) the power of making long hand notes on pen and paper. It helps me connect with and think through the material and take it in at a pace I can process it.

It's not quite the same, but I recently studied for a technical exam/certification where the syllabus included about 400 slides (about 10 days of teaching & lab work). I failed the exam just reviewing the slides, even when it was sat quite quickly after I had taken the courses.

The next time I sat it several months after doing the training, I spent about a day and a half writing out the slides. I went through two A4 pads and a couple of pens. I will never review my notes (I have the searchable PDFs), but I found that exam really easy the second time round.


There is a reason for that I've seen articles on it. If you take notes using a pen to write on paper you retain more. Using a computer to type notes into a text application is terrible. There is a disconnect between listening, then looking to type (or at the screen).

I've noticed it myself. I went back to school late in life (48) and at first I wrote in notebooks. Feeling a bit old compared to my much younger classmates I went digital. In class I typed notes into Word. I convinced myself it was neater, safer and I could make backups. In reality I discovered I learned the material better if I wrote my notes by hand in cursive, block printing was too slow.

I'll see if I can find the article about it.

edit: this isn't the exact article but it is similar: https://www.npr.org/2016/04/17/474525392/attention-students-...


> then looking to type (or at the screen)

If someone is looking to type or at the screen, whoever taught them to type failed them. This sounds like the same stupdity of pair programming where "one can type while the other thinks." I'd be curious to see differences in note-taking retention between those who can touch-type and the hunt and peckers.

For me, the benefits of digital are too many: sorting, searching, organizing and of course the backups. I'm also left-handed and do not miss my school days where I would end up with smudges on my hand. I might buy that scrawling something out by hand leads to slightly higher retention rates than touch-typing notes, if only because the ROM is much higher, or it forces you to either go more slowly, allowing more time for reflection (Neal Stephenson wrote the Baroque cycle this way because of this), or have to condense lecture notes more, which would require more active thinking.


I've experienced something similar though I find that I hate my handwriting and messy notes.

My wife and coworkers have found a solution in using a tablet like the iPad with stylus or something like reMarkable. The technology may be at the point where it is a satisfactory solution to the digital type vs note writing problem.


Reading, digesting, internalizing, and interconnecting information to your internal knowledge pool is a time consuming process, no matter how much business demands want everything yesterday and how competitive the world gets. The true factor for me is time and I've found no shortcuts around it.

For me, I re-read multiple times with gaps of time between which allows me time to internalize information and then pickup and incorporate concepts I missed before in subsequent passes.

Often in a given set of knowledge or information, there are interdependencies that are overlooked by authors/editors and information you gather chronologically (or in the sequence present) later actually helps (or is even needed) to understand concepts correctly that you covered before (or may be outside to body of information you're studying).

Some gaps are omissions, some are due to gaps in your own understanding of a concept (everyone has them), some just require a lot of thought to properly internalize.

There's this trend of rapidly digesting and spitting out information as knowledge as a facade of understanding and I think neglecting critical thinking along the process is a fool's errand, personally. This leads to blindly following trends and taking everything at face value to me.

I couldn't count on my hands and toes the number of times I've heard people say "singleton" in the past 6 months who don't understand what it actually means or how/when to use the pattern (they're not developers). They heard some developer say it and then try using knowledge transfer to confidently use it outside the context where it actually fit because they never truly understood the concept but want to appear they do (instead of, for example saying, "hey, I've heard of a 'singleton pattern,' would that work here?")


A. Build general familiarity. Do a shallow pass, just to get familiar with the information mapping, general concepts, and their relationships. Don't worry about understanding everything.

B. Create feedback loops:

- Go someplace where I can talk to myself, and summarize as much of what I read as possible. Note anything I couldn't explain to someone else, and go back and fill in those gaps.

- Write out my own summary of the material, as simple as possible (no fat), such that anyone could read the summary and learn the material. This is basically technical writing, and also creates an artifact for others who need to learn the same content.

- Draw out the main components on a whiteboard.

C. Start to apply the material.

- Copy a "known good". Transcribe good production code to get a feel for the principles. Hunter S. Thompson used to spend hours copying Faulkner to develop a muscle memory for the rhythm of the language of good writing.

- Choose a small goal and use the material to implement it.


I use a process I made up based on how suspension bridges are built: 1) literally an arrow is shot from one side to the other over the span the bridge is to occupy, and that arrow has a kite string attached; 2) the kite string is used to pull a thicker piece of twine; 3) the twine is used to pull rope and the rope is used to pull steel cable; 4) with the steel cable in place, the large scale bridge construction can begin.

In a software context, first just get anything operating in the target space you are trying to learn and develop. Then expand that minor nothing piece of software to be just slightly more capable, and observe what adjustments were necessary in your thinking to get that minor adjustment working. Repeat this process of small iterative changes with a formal review of what you're learning, and at some point you'll realize you have developed both a body of knowledge and a small framework for further work, and probably several ideas how to "fix" your mini-framework. Now spend some time trying to fix the mini-framework and use that to solidify what you've learned. And throughout this entire process: take notes, review the notes, and observe the scientific method in your notes: meaning write down a hypothesis, test it, write down the test results, write down you thoughts on the test results, and repeat. The writing down portion is important, as the act of writing it into notes forces fragment sentences to be formalized, completed and that can catch incomplete thought processes, which are critical, as they are the edge cases that also need to be handled.


Note: I realize this response sounds similar to what you have already tried, but it's slightly different in a way that might be useful to you.

Background: senior year of college I took one of the deep learning courses my CS dept was offering, and I was nervous about it early on because I nearly failed the math pre-req test they gave to assess whether we could handle the concepts in the course and get some value out of it.

I ended up doing well in the course and passed with a great grade, even though I felt like I was drinking from a technical firehose the whole time. The technique I ended up using to get myself through was what I call depth-first learning. Basically you start from the beginning of a non-trivial, legitimate starter project or material, and work through it as you normally would. When you hit a point of confusion or a knowledge gap of any size, pause everything and follow the concept graph all the way down until you bottom out or hit something you have seen before and understand, then backtrack and continue from where you first branched. Taking notes in a gdoc or something is also crucial.

I'm not claiming to have reverse-engineered cold fusion or anything by learning this way, but my main takeaway was this: everything I thought was complex was really just a huge pile of simple things that I understand (or could understand with minimal effort). It was all about understanding the essence of what is going in the big picture and how the smaller pieces relate to it. The main difference I think in this approach vs what you have already tried is that you are using a similar approach with a reference manual, and not a legit near-state-of-the-art project with a concrete goal in mind. If you don't try to accomplish something specifically, you're just going to load up a bunch of information in your head, then eject it when you come across a problem you are actively trying to solve.


I’m a big fan of osmosis learning on really complicated stuff. I just read everything I can get my hands on, with the frustrating realization that I will not understand the vast majority of it. But I read it anyway. And lots of variety, from lots of different writing styles and perspectives, writers with different levels of expertise. Just soak it all In. At some point, it is always true, that things will start clicking. Then I can go back and reread that stuff and actually understand it.


My approach, which I don't claim to be necessarily the fastest, somewhat resembles what you first mentioned (going slowly, looking up every word etc.). I recommend the following:

1. Give yourself time and accept that there will be things where you will get terribly stuck.

2. Ideally work with other people, or find other people trying to learn the same thing that you can exchange meaningful questions and comments with.

3. Allocate chunks of uninterrupted study time every day, but don't force yourself to hit rigid targets (e.g. I need to do 1 chapter a day etc.).

4. Go through the material slowly and never gloss over smth that you didn't understand. How do you know you understood it? Try to explain it to somebody else, try to explain it to yourself in the simplest way possible, ask yourself any question no matter how dumb, no matter how absurd regarding that thing.

5. When you're stuck on something try to ask other people, use the internet etc. If you're still stuck make a note of the thing and come back to it not too far in the future.

6. Make sure that you don't let too much time pass without actually applying the knowledge. If you're reading a textbook try to do the exercises, even the weird looking ones. Once you know enough, make a little project, re-implement something yourself, prove things on your own without looking at the textbook etc.

7. Try to review things later on, even if you understood them well. You will often see them in a new light.

8. Use multiple reference texts for the same kind of material, but try to have one main one that you're following closely.

I hope you will find some of these ideas useful.


> Give yourself time and accept that there will be things where you will get terribly stuck.

I don't remember where I heard it, but this situation was described to me as the "moment before a breakthrough". I was told to look for these moments of stuckness because that's where the biggest wins are (and where many, many people quit).


Sounds about right. The nice thing is that if you're mentally prepared for it you have a good change of pulling through.


Slowly!

Learning tends to be inefficient. You do have to put in the time.

Working with people who have experience in the field will save time as they will be able to guide along the way.

Articulating what you have learned to someone will re-enforce your understanding.


For reading technical papers, I've found the 3-pass method in "How to Read a Paper" [1] helpful.

For longer/more complex topics, I like having an experiment that I work on, try stuff out, etc. While I'm working on the experiment I take notes on what I want to do, what I did to accomplish said objective, and what things I learned during that.

[1]: http://ccr.sigcomm.org/online/files/p83-keshavA.pdf


How does one do the third-pass? "re-create the work" it doesn't seem feasible because you would need some financial and human resources to do so.


For programming, I think learning by doing is the best.

I can read big fat manuals, nod knowingly at all I read, and then forget most of it when trying to build something.

If I have something concrete to build, figuring out how to do just that works much better.

Of course, there is a time for reading a lot in my model too. But it's interspersed with the doing.


Go from the big picture to the small. Begin by summarizing the information on a high level, then start drilling down in select areas but always be sure you know where it fits in the big picture.

This is good because to remember something you need to anchor it to something you know. It's impossible to learn something in isolation, which is why you'll often become confused if you start from the details working yourself up. You simply have no context for the details.


I can't read the information to understand, I need to try out, make it work/break it/ make it work again. If not it wont get stuck.

Take a small feature and fiddle with it, it will take some time, but eventually you learn really well.


This is how I learn mixed with understanding the tool / framework / language from a first principles point.


Which means that for me, dense technical documentation is useful when I know how to read it.

Reading Cisco documentation is painful, but every word does matter. But it won't be worth the read if you don't know about the tech beforehand. Again talking from my own perspective.


For anything complex, usually, I'm trying to build a mental model so that I can reason about it w.r.t new scenarios. To get an accurate mental model, if a nice and clean documentation exists that you can read and understand all the elements – high-level, low-level, layers, how things connect and interact – its awesome.

For something that has evolved over many years (like Linux kernel), you will find documentation for different parts of the system but it would seem like they all assume some knowledge of some other part of the system.

There would be lot of circular dependencies for pre-requisite knowledge to even understand what would be considered as good documentation. So, obviously, you will have to do multiple passes. You will have crawl through this dependency graph of knowledge multiple times to build a mental model for yourself. This takes time and focus. Good memory for details is crucial.

Don't be afraid to work with partial information and partial understanding and work through those intermediate knowledge passes and still do useful work (like reading lot of code, find and fix bugs, add small features or even big features in isolated areas etc).

Putting in work (fixing bugs or adding features) helps you test your understanding and gives a meaningful way to engage with your peers who can help improve your understanding of the complex system.


I do this by creating a side project with a concrete objective. I then do my best executing the side project.

After I get something useful doing the Side project then I try to give a presentation about the side project.

Note that I have failed multiple times with getting something useful enough to justify the Side project.

Another way you can do this is just promise to give a presentation about the topic at a local meetup. And keep on giving presentations about it.


> I've been considering skimming through the whole things to get kind of a big picture of what the thing is and where I'm going and then going back a second time to catch then the details and experiment.

This is what they recommend in "How to Read a Book". First one is called "inspectional reading" and can be anything from a fifteen minute pre-reading to decide if it's the correct book to read, to a read-through without stopping to look things up, but make notes (especially of questions).

Second one is called analytical reading, and is much more focused on asking oneself questions about the book and how it covers it's topic. Very active reading.

I've often found it is helpful to go in the order they recommend, as you can often get all you need out of a book with an inspectional superficial reading. Sometimes you can eliminate a book via the pre-reading, but the ones that are valuable enough to justify an analytical reading are well worth it. In particular, I class books with questions or exercises very highly, as I retain much more information when I have to work through problems.


I found that book quite superficial and superfluous. Content of few pages stretched out to a book.


Ha! I'm glad I'm not alone. I tried to take an interest in it as well but found the writing style to be extremely tedious and verbose. It's amazing that a book that professes to show you 'how to read' would be so poorly written and such a slog to get through. I'm only half-way through it and I'm not sure that I'll ever complete it. The content is good and interesting, but there's far too many words used to communicate what I think are concise, actionable ideas.


> I found that book quite superficial and superfluous. Content of few pages stretched out to a book.

Perhaps you need to do more than a superficial reading, as they suggest.

In seriousness, I found it very good and deep. Perhaps I just was lacking in my education, and you may have had learned the lessons they sought to impart before you read it. To each their own.


I use the several pass method where each pass is a deeper dive. After each pass I write down or review what I have learned before moving to the next pass. I also like going from the full scope down to the focused details in steps. Finally break the big parts down into sub parts. In some cases I identify the parts I understand and then build out to the parts I don't know.


I use confluence ( you can get a one person license for free) and completely outline everything I'm reading. Sometimes I use bullet points, sometimes I type in code samples using the code-block plugin. I use headers to divide chapters and sections.

I write everything - and if I can't understand it I type it in verbatim. Just the act of reproducing it often clarifies it in a way that reading ( or, if we're frank, skimming ) can't match. If I'm trying to understand Kubernetes CNI plugins

https://kubernetes.io/docs/concepts/extend-kubernetes/comput...

I'll type in exactly the statement

* Kubenet plugin: implements basic cbr0 using the bridge and host-local CNI plugins

And trust that as I go further in to the documentation I'll understand more and more what that means.

No copy-and-pasting. Type it in and force my brain to process it in and out. I've found it invaluable.


Dense technical documents require several passes of reading. Often it's difficult because unfamiliar terms and concepts.

Do a first pass just to quickly skim through the documents, looking at titles, subtitles, introduction, first paragraphs, summary/conclusion, etc. The goal is to get the scope of the document and do a quick assessment of the landscape.

The second pass would be do a detail read but note down the terms and concepts you are not familiar. Do some research on them.

The third and later passes would be to go into detail to understand what the document is talking about. When reading, try to build concrete examples and try to relate to what you have known before.

Nth pass, it helps to write down what you have learned. Do it as though you are teaching someone. Writing/teaching often forces you to understand the real detail.

Remember more practice brings more understanding, so do it more often.


When I was in grad school, I fell into a habit of going over everything up to 3 times.

The first time was a real quick read-through - really more of a skim - just to get a sense of the overall shape of the subject.

Then I'd go back and actually read the bits that I needed to understand more thoroughly. While I was doing that one, I'd take some notes, because I find that helps a lot with retention. I wouldn't be trying to memorize everything here, more just trying to get a thorough enough understanding that I could quickly re-find information when necessary.

Finally, for anything I absolutely had to have in my head, I'd make flashcards. This part can be indispensable, but I tend to be pretty conservative about it. I'm fond of that (apocryphal, I think) Einstein quote about not memorizing such information as can be readily found in books.


>I've been considering skimming through the whole things to get kind of a big picture of what the thing is and where I'm going and then going back a second time to catch then the details and experiment.

That's what I would recommend ... quite often every detail is not necessary, but it helps to know where to look should you need more detail in the future.

Mortimer Adler discusses this, where first you want to get an overall gist of a book, and then skim it and dip further into areas. It helps you to start to formulate questions that you can answer with deeper reading. Then you might read the whole thing ... but maybe not, based on what you learned on grasping an overview.

It is particularly freeing to realize you don't need to completely read a book to get the most out of it FOR YOUR PURPOSES.


I think time plays a role. Trying to learn complicated stuff fast usually leads to not learning them well enough, in my experience. If I do so, jumping to wrong conclusions or applying a method on the wrong place/in the wrong way is almost guaranteed. So just keep reading, studying, picture yourself explaining it to a classroom, talk about it to colleagues and friends, engage on discussions about it online. Eventually you'll master the craft before you know it, and the good part is that such things may be on constant evolution and there will always be something new to learn. Just avoid being that one trick pony that knows a lot about one specific topic and that's it.


Feynman Technique is often mentioned:

https://mattyford.com/blog/2014/1/23/the-feynman-technique-m...


There is no easy way. It'll take time to build the knowledge, while occasionally getting ridiculed, praised, demoralized, excited etc. Just keep pushing! and best way to do that would be pick a small domain in kernel which "truly" motivates you. Try and understand each and every line of it, no matter how much time it takes. Take breaks, take detour, but keep coming back. Eventually, that one small domain will not only help you understand bigger picture, whole exercise will help in understanding other complex topics too. Remember, brain is like muscle too - it needs similar regimen of disciplined exercise to strengthen those muscles.


To clarify on "Try and understand each and every line of it", don't try to do it sequentially. Initially, understand at 10000 ft level and leave the abstractions as is. Then dive deeper in second pass understanding one-level down of abstractions, then deeper in third and so on.


For the past few weeks, I’ve been going back and forth with the notion of hiring a private tutor/teacher (not in school and not for work) that’s in a PhD program at a local uni for a few months.

For the past +5 years, I’ve been teaching myself programming, math, and any related matters, yet it’s a slow and grueling process with many side paths that I go down. I’m tired of this! I want to dive into a book on financial derivative modeling and have someone next to me explain any concepts I don’t understand instead of me going down the rabbit hole and extending the time it takes to complete my goal.

Have any of you ever tried this? If so, how’d it go?


> I want to dive into a book on financial derivative modeling and have someone next to me explain any concepts I don’t understand instead of me going down the rabbit hole and extending the time it takes to complete my goal.

Sounds like you need to take a graduate level course in derivatives modeling. Graduate level courses are typically seminar style and have lots of hands on work and discussions.

You might be able to find a school that does this kind of course online. I'm not sure how that would work for seminar style classes, but it might be what you're looking for.

Another option is to hire a tutor, as you said.

Just do it. See how it goes. Go on "Rate My Prof" or whatever and find someone who will challenge you (and who also cares that you learn). Have deliverables ("homework", readings, etc.). Be willing to pay them up front for developing your "class" syllabus. Planning how to teach complex materials is an arduous task, especially because most text-books aren't quite right for any given person's learning/teaching method.


You can get access to many (perhaps even most?) of MIT’s class material: notes, problem sets, even videos of lectures, on the mit open courseware site. They are just copies of what students see/get rather than being designed as online courses, but perfectly suitable for self study.


I’m completely self taught and the strategy I use most often is to grab a book on the topic. Either a lame men’s copy or a college text book and skim as much as possible.

Once I’ve skimmed it I pretty much have a good idea of the outline and where the material is at within the book. After that I just read the parts I need most and implement them into a project.

I will often times go back and read things again an reimplement until I’m happy I understand most of it.

It might not be the best way but it’s worked for me and has helped me implement new things in a short amount of time.

Also becoming obsessed helps.


1. Learn the vocabulary fluently. If you don't know what the words really mean, you can't follow the material.

2. Study before bedtime. Sleeping right after studying is a proven means to help you assimilate the info.

3. If you get stuck, take a break. Eat something, drink something, maybe even sleep on it and come back to it later.

4. If x material isn't jibing, look for other sources that explain it differently.

5. If there's a weak area in fundamentals necessary to get it, work on that area. It's pretty much guaranteed to be "the weakest link" in the learning process.


There's no single answer because it's a function of how you learn, and the subject matter in question. I'm one of those people who doesn't believe that anyone can learn anything -- there are some constraints (despite having a growth mindset) that will limit how far you can go.

I think semantic tree/first principles/physics-based approach (popularly attributed to Elon Musk) is one way to approach it. It's actually a really difficult approach and you need a certain level of intelligence and personality to do it well, so it's not for everyone. I can do it to some extent but it's actually really difficult to hold lots of ideas in tension and to be questioning all the time -- it's just not my thinking style.

The other approach is what many smart (but non-geniuses) take: the buffet approach. You graze at the table of books, Wikipedia, online articles, and hang out in online communities (like Twitter) to overhear what experts are discussing. The thing about most areas of knowledge is, there's usually only 20% of the subject that matters--the rest rarely come up (Pareto Principle). To know what 20% to focus on, you need to understand the sociology of the subject matter and what experts think are important. Unlike the previous approach, you won't have watershed-level insights, but you'll know enough to be considered "educated" on the subject.


When you say "learn", I am assuming you mean getting to the point where you can apply the knowledge. It sounds like the problem you are trying to solve is to decrease this "learning" time and not so much increase your retention of information.

I haven't done any kernel development, I'm assuming it's highly technical and you get can't skim through materials.

I think if you are able to painstakingly go through technical documentation, that is a special ability. My guess is it probably sets you apart from many devs.

Getting a big picture is a great idea as you build a mental map of important topic areas to cover and gives you some form of mental motivation or direction. Better if someone has already done this, so you can save your time.

For more technical subject matter though, those fine details make a big difference when trying to apply it. I don't know if there is a way to avoid doing that. Skimming things I find wastes a lot of time because when you try to actually build you get stuck because of some important detailed buried on page X paragraph Y.

Some other areas of development aren't as intense so you can get away with not knowing everything and be able to build something pretty impressive.

For dense technical information, my method is to take research-like notes, cross-referenced in my note-taking app and improve these notes over time. I save time by not re-learning and re-searching supporting materials.


Write them down, create mind maps and use this article as your guide https://fs.blog/reading/


I'm going to answer how I do it; not because it's the best, but because it's probably the worst.

First, I'll go to youtube, hoping that someone gave a talk about whatever tech it is, these are good because talks often distill the high level architecture into a 45 minute presentation and it gives a decent starting point to understanding the minutia.

However, what often ends up happening is I see lots of videos and pick up nearly nothing (as most are not talks, they are mostly indian people making course materials).

After I fail to do the youtube thing, I usually go to the quickstart guides, or copying example code and messing with whatever it is, stepping through each item of the code or futzing the configuration to try to make it do weird things, reading up documentation on each config key.

After that I start branching out into other areas, how do I make whatever it is much different? if it's software, how do I scale it, what are the individual components- if it's a library; what else does it support etc;

I very rarely read an entire manual, but after back-and-forthing a bunch of times with experimentation I have usually read a huge chunk of the manual.

However where this really fell down was with kubernetes, as a concept it's very large and hard to break down into smaller sub-components, and when you're testing the entire thing at once it feels like "magic inside" which is not ideal for my method of experimenting (try/break/fix/repeat) as too much breaks at once.


Over the years I've learned many many things in depth. I've worked on codebases totaling hundreds of Mlocs. Perhaps I can say a thing or two about this.

First, it takes time to develop a method that will work for you, and I won't pretend that mine will, but as that's what I know... The first time you have to do this is the hardest, but each time you'll feel like you're at the bottom of the Himalayas and have to climb to the top without help -- you might always feel a bit helpless at first, and you might have to defeat that feeling every time, and that's OK.

Second, you need to get a handle on concepts first, details later. When you deal with hundreds of millions of lines of code you just can't know enough of the details. Instead you need to know how to navigate your way around the landscape, and you need to know the general lay of the land, and key landmarks. This will help you organize the details that you must remember, and discard the ones you can refresh as needed.

Third, the ABAB pattern to dealing with prerequisites is essential: learn as much of A as you need to before you block having to learn some of a prerequisite B, then switch to B enough to get back on track to A, lather, rinse, repeat. Even establishing all the prerequisites and topologically sorting them might be ETOOHARD, and learning them all in the right order might be ETOOBORING or not good enough to build the muscle memory you need for the earlier topics.

Fourth, learn the tools early. Whether you use a proper IDE or integrate usage of a bunch of standalone tools into something like an IDE, you'll need one of them.


Every answer here are super good and I agree with most of them. What I would add is:

Try to find a way to make it easy to test a lot of things, for example, get yourself a good environment to do kernel development with automatic virtualization, automatic setup of debuggers, automatic generation of initramfs based on what you want to do, etc.

So that you can focus on a write-build-test cycle ; this way you minimize cognitive load.

To summary, automation & environment setup matters.


I guess my method for new frameworks / languages / etc is sort of a combination of top down and bottom up. I start with very high level overview, followed by a very simple tutorial, then work my way up in the hands-on path, and work my way down in the reading and theory path. One reinforces the other, so the reading does not remain abstract, and the practical has context.


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.


I was reading the first half of your comment and immediately went "but.. but... what about those huge Java stack traces?".


It seems that good spring developers are able to work without a mental mode of the execution environment. Or they are much more able to hold 40 items in their working memory than I. (I have always been happier in smaller environments than larger, more Scheme than CL, more C than C++, python not perl, node but not npm, presently falling in love with Golang. I help my Java friends with OS or crypto knowledge but I don’t type much into their code base.


Here is something that has helped me a lot. It's a paper on how to read academic papers. You can extract the general idea and apply to many other technical reading material.

https://web.stanford.edu/class/ee384m/Handouts/HowtoReadPape...


What works for me is I know a lot my weaknesses. I have a low attention span, get bored and sleepy when learning hard things. So I literally close myself off from every distraction in a quiet place, where I can also nap...read as much as I can...nap...continue, all the while taking notes, scribbling drawings etc. Its like my brain gets tired from all the new stuff, but after a nap, it sticks. Sometimes this is a slow approach as I don't pressure myself and fully accept that I will fall asleep and I accept this as ok...but I found I get the deeper comprehension out of this much more than watching or listening to a thing and it seems to store long term. This mostly applies to problems that I really don't want to learn necessarily but I know I have to go to the next level. Most things are not this way as everyday work is pretty straight forward but you'll definitely get paid more if you understanding harder stuff because most other people won't.


I always just tackle things head on, hit a roadblock, research how to get through it, and continue. But having a goal that's interesting to me is paramount.

Wrote learning doesn't do much for me, but having a goal, finding working examples of solutions or implementations of the parts of solutions helps me internalize how things actually work, and put it all together.


Check out fast.ai's teaching philosophy. https://www.fast.ai/2016/10/08/teaching-philosophy/

You wouldn't teach kids soccer by having them practice cone drills without a ball - they need to play a game first!


So, I can only say this.

I teach very technical material, and when I'm teaching, students nod their heads, "Yes, yes, makes sense..."

But then when I give them an exercise and say "OK, you all told me you understand this, now go design X", many (not all) of them start to implode.

I've realized, the only way you get better, in addition to constantly feeding your brain, IS BY //DOING//. You have to go out there and slay the beast. Go ahead and fail en route, I did. But stay in the fight, kick ass, learn, struggle, ask questions, grow.

There are way too many armchair experts. Go do it. I did it. It was hard. But then you've proven you can persevere and win. Everyone's a legend in his own mind.

I love to see self-appointed "the smartest guy in the room" struggle. Not because of Schadenfreude (sorry, I'm bilingual) but because until you've triumphed on new ground, you're a learner like everyone else.


Everyone learns differently with a combination of what you mentioned. visual aids, auditory aids, reading. There is no secret to learning only that you are consistent.

There are times that a technical manual comes along and there is a need to go off into the bowels of other technical information that is also provided and that to me does not help in any way. I must learn what I set my eyes out to learn and nothing more. The rest comes naturally as I begin to experiment and running into the same learning curve as others. That is when I begin to dig a little deeper. Again with all of the aids available, visual audio, reading and experimenting, until I feel that I have a strong grasp on that specific subject.

There is no secret, the only thing I suggest is to stay on it, and stay consistent. The more you do it the more understanding you will get. There is truth behind "practice makes perfection".


Break things down.

I'd start by getting an overview of the problem - in this case it's probably chapter names in a book.

Then for each module, break down what you'd like to learn further into sections that take < 2 hours to complete thoroughly.

After each 2 hour module, write down your key takeaways of the trickiest part you learn and pause.

Then, when you're ready, resume for the next intense chunk.

You can re-read your highlights at the end of the day to help absorb more deeply.

I've also found the Cornell Notetaking method (http://lsc.cornell.edu/study-skills/cornell-note-taking-syst...) to be a helpful guide.

It includes the "summarizing" step and a recommended structure for organizing notes both as you're reading/watching and when you're solidifying this knowledge.


I've been trying out Anki for some of this. It's a digital flashcard tool, widely adopted by folks learning new languages or studying for med school. It combines three important learning concepts:

1. Repetition. As they say, "Practice, practice, practice"

2. Spacing. You need to let the concepts wander out of short term memory.

3. Forced recall. Once a concept is out of short term memory, you need to practice recalling it. The act of doing so is what reinforces long term memory.

Anki doesn't help you understand things though, so I use it as part of a broader multi-step approach:

1. read stuff. books, journal articles, blog posts, etc.

2. re-read stuff. make sure i understand it well enough to extract information into good cards.

3. Anki

4 (optional) do something with it. Build a program, use the word in a sentence, or however you might apply it in daily life. This is, after all, the point of this whole exercise.


I’ve found that I’m able to absorb math and programming resources well, but I approach each slightly differently. With math, I pick up a textbook and read through the exposition, trying to work each sample problem based on the explanation before I read the author’s solution, then compare my solution with his. Then, of course, I work as many sample exercises as I can. With programming, on the other hand, most of the materials don’t (unfortunately) include sample exercises, so I at least type in each sample program by hand rather than cutting and pasting them. Then, when I run it, I try to modify different parts to make sure I really understand what they do - that is, I try to predict what making each change will do before I do it, and then verify whether or not I was right.


I just completed a difficult cybersecurity certification exam (OSCP) and if I had to summarize my learning path for that:

- Figure out a time where you want to become proficient in the skill by – something that balances between setting a fire under you while not being impossible to meet – then develop a weekly learning plan roughly based on that

- Learn a lot of things from many resources, instead of learning everything from a single resource. Some things that one author lacks the finesses in explaining might be easier to digest coming from another. Cross-pollinate the ideas of several authors. I like to combine text books, audio books, hands-of practice with things like labs or side projects and just talking to others about what I'm learning

- Don't burn out and take a couple days off the learning path every once in a while


Dive deep into some aspect of it. Doesn't really matter which, so find something interesting and dive in, even if it makes no sense. Do that for about an hour or until your head feels tired, then leave it until tomorrow.

Rinse, repeat.

Over time, your brain will make the connections between the parts and the patterns.


Embrace it and immerse yourself in the material. For example what is the fastest way to become fluent in a foreign language: full immersion.

In terms of software just write the new code and build a product with it. Fail, fail, and fail against until you get it working and then wear away at the rough spots until it becomes familiar and muscle memory.

In terms of some abstract concept like security or accessibility or performance simply read the material and apply the concepts as immediately and directly in your real life as you can. After theory and practice come together it won't be so challenging and then after a few times it will become familiar.

There isn't any magic to this. Just be disciplined and muscle through it.


I used to get a few books on the topic and skim between them and flick between the books (in large time chunks - hours or days) and practice things (like C). I have found myself just watching videos now, there seems to be a video or two on everything, made by the experts in the fields. Watching one from Udemy right now - $10 (wait for them on special), they mightn't have the very technical details but enough to get you started so you can find the details out.

I remember first watching Gilbert Strang's videos on linear algebra and thinking back to my days of sitting in lecture theatres watching my lecturer teach the same content. I became very envious of "kids these days" :-).


If I find I am not getting something immediately, I study its pre-requisites.

Ultimately, I wanted to stop reinventing algorithms, which in turn forced me to review math. After that, additional layers of knowledge became much easier to stack.

Remember that C was easy for its creators. :)


Try a printer + highlighter.

It’s hard to explain why it works, but I find that having a physical copy helps me grok technical documents and re-find the details later.

Apply other the advice in this thread too, but add a highlighter, notes, and light manual indexing.


For new stuff, I like to start with something I want to make using it. And a popular textbook. The first something should be useful but simple.

For electronic logic, for example, I found something I wanted to build, on a breadboard and learn from. Then I referenced the book to understand what was going on. Then I played around with the circuit ... 'what happens if I do this'. You pick up the jargon slowly this way.

A year or so later, I actually got a computer-hardware troubleshooting job offer after I destroyed their logic test. Luckily, a teaching job came along to save me from that.


for topics that are well established, I highly recommend using a textbook! Since a college or grad level course is intended to give someone a lot of background, historical and otherwise, they tend to cover a wide range of information and can be more efficient than piecing together knowledge from blog posts and reference docs.

Systems, networking, databases, machine learning have fantastic resources available. I usually look up the syllabus of a course at Stanford or MIT and check out their recommended reading. Some professors publish their own books for free as PDFs as well.


I come up with the smallest viable project I can think of that requires the given knowledge, that I'm also genuinely excited about building. I then try to get started, usually fail right away for lack of understanding of the "framework" parts of the problem, and then go off in search of examples, always keeping the goal in mind of getting my small project working.

I find this is applicable to a wide variety of subjects. I absorbed math in high-school with the mindset that I wanted to write a small theorem prover, for example.


Everyone has their own preferred mode of learning. Mine is hands on, learning by doing. I can't learn new material just by reading a book (although I have friends and colleagues that appear to be able to do so). I have over thirty repos on GitHub, most of which are the result of one learning experience or another: GPS, SQLite, yacc/lex, Go, Rust, etc. For some of these, I had to buy hardware, e.g. an eval board, GPS receivers, etc. That's what works for me. Your mileage may vary.


Learning complicated stuff is a compound process. There’s no framework as such. It takes slow, methodical, frequent look-ups, trying out, dead-ends and everything inconvenient at first.

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!


This is mostly related to systems or data modeling, but what works best for me is drawing diagrams that have lines which connect all the related components. Whether it’s call stacks, data (or energy flows in the case of circuits), or data models. I usually use a pen and paper. You’ll probably make mistakes or run out of space on the first attempt but that forces me to redraw it a few times which helps with memorization.


Lucid charts is outstanding for this sort of thing. First diagramming tool I have found that competes with white board for brainstorming / fleshing out protean ideas. It is easy to use - you rarely think about it and like can stay in the problem/solution space.


You’re right, but I usually find myself wrestling with the technology and having too many choices with the components they provide. There’s something about the simplicity of using a pen and paper that makes it stick better for me.


If you are very knowledgeable and understand most of the contents of the topic you're reading, then I recommend continuing to read.

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.


Yes skim first. When you start you have no sense of the shape of the topic or what's important. Skimming gives you that information quickly and typically will reduce the amount of time you spend doing exercises.

But skim multiple sources before really committing to one.

In your I'd skim K&R plus some other C books, at least two of the giant kernel development books. Then choose something you feel is interesting and challenging enough.


one of my favorite tech essays, https://norvig.com/21-days.html


This guy has tons of great content like this: https://www.youtube.com/watch?v=Cky0O-hANDI

He's currently a Junior Doctor in the UK and is great at consuming lots of complex content and describing how he does it. Some clickbaity videos in there but most of it is fantastic.


https://blog.phuaxueyong.com/post/2020-02-15-list-of-feb-art...

Interestingly, i wrote a brief paragraph about this as well. Thought to share with the community. Long story short, just work at it. Be comfortable with you not knowing (:


Y'all are gonna call me a crackpot, but consider P, PSPACE and IP. PSPACE is (probably) much more powerful than P. Also PSPACE=IP (interactive proofs). Learn interactively. Treat your compiler as the prover, you as the verifier. Don't try to understand everything by simply reading the manual -- that's only utilizing P, not PSPACE.


Basically, what he said: https://www.scotthyoung.com/blog/ultralearning/

It's the only thing that sticks and has worked for me, and I've been (successfully and not) learning dense technical info for 30 years.


Just put into youtube the name of the subject and "easy explanation" (or similar words) and pick one of the videos to watch.

Since this is my go-to method, I tried it for the two subjects you suggest: "kernel development" and "writing proper C".

Check it out my results:

https://www.youtube.com/results?search_query=kernel+developm...

https://www.youtube.com/results?search_query=writing+proper+...

For the first one, I expect if you watched the top few results (17 minutes: Kernel Basics, 9 minutes:What is a kernel - Gary explains, 43 minutes:Manuel Schölling: Linux Kernel Development for Newbies) you'll be well on your way to learning this information. (The ones I didn't just quote are great too: "Basic Linux Kernel Programming"; "Write and Submit your first Linux kernel Patch"; etc etc etc etc. The whole page of video results is great.)

My second search above was a bit less of a match. The first four results seem too beginner for you, but the fifth result on that page is a 1 hour 40 minute Bjarne Stroustrup (the inventor of C++) talk titled: CppCon 2015: Bjarne Stroustrup “Writing Good C++14”.

So as you can see this method isn't fool-proof (even the result I just mentioned is about C++ rather than C) but in my experience, a fantastic way to learn that has not been mentioned in these comments so far. (There are currently 38 comments in this HN thread and 0 mentions of youtube.)


Why was this downvoted? I've learned many technical things using this method.


Use your body and mind creatively.

1. Bring in your other senses with music, sound, lyrics, take some cognitive load off the rational and put it into the physical.

2. Take naps, doze off...allow your mind to rest into a dissociative state. I make all kinds of technical realizations about my SQL code in the bathtub.


Very often the very first thing you see when you open a very technical book is the book giving you the finger so to speak. You must remain calm and continue. You'll be surprised how much useful info you pick up that way. Anxiety is the killer of progress.


"A math textbook might be fascinating page turner, if only it were written by a writer instead of a mathematician" -Paul LaRocque


Never underestimate the power of a good night's sleep.

I found that sometimes the forceful reading everything top to bottom and getting focused and trying hard... Well a good night's sleep and a mind wandering in the shower sorts a lot of it out naturally.


You can learn big systems by tearing it down to subsystems, and learning them one-by-one, the same way how you would split a big implementation (waterfall) into small steps (agile).

Here is a concrete example how I learned Kubernetes:

1. I tried to get an overall sense of what is it: "Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications." - Ok that makes sense, but don't know what big part is it made from.

2. What problems does it solve and why? what are all the solutions? What features does it have?

3. What is the overall architecture? What parts does it have? API server, scheduler, controller managers, etc...

4. I installed it so I had to learn networking. What is a network plugin? How do they work? Learned most things which needed to running them.

5. What is the structure of it's API? You don't need to go into great details, just to see the big picture, like main api endpoints: /api/v1, /healthz, /logs, etc, etc...

6. Kubernetes Objects model high level overview. What are objects in Kubernetes? What Fields do they have? What are Controllers, Pods, Labels, Deployments, etc.

7. Authentication. How does it work, what methods does it have?

8. Services

9. ...

And so on. So basically you take ONCE concept at once and read everything until you feel you got the thing. For example, if you already understand the overall concepts, you can dive into what a Pod is by reading the article about it. I usually try to read the minimum number of manual PAGES until I confidentially grasp the entire concept I want to learn about.

By splitting huge and complex systems into small subsystems like this, you can become productive much sooner. Don't try to understand the whole thing at once.

You said you want to learn "kernel development". That's not gonna work, because the kernel itself consist of I don't know, thousands? of subsystems. So try to get an overall feeling. What are those subsystems? How can you split them into easy-to-digest parts? What is a driver? What parts does it have? What data structures are in the kernel? So if you try to learn "kernel development" from day one and learn "kernel development" until you can "develop for kernel", it won't work. First, you need to know what you don't know. :)

This is to verbose, but hope it helps.


One trick that works well for a limited set of situations: When reading a math or science textbook chapter, read the questions before the text of the chapter. The keywords in the questions will clue you in to the keywords of the chapter.


The only thing I will add is that you need to make a goal that will keep you motivated to move forward. Also, you can't stop and hope to return at a future time. You need to work through it until you are done.


Do you guys allow for a dipping period ? as in not getting anything for a while but saying that's ok. Let it sit in your mind and let the idea sink in smoothly, then you do a full blown effort to master it ?


If I am learning something new then I find it helpful to copy down on paper what I read out of the book, word for word, as I read it. That slows down my reading and prevents me from spacing out.


Read it three times: 1) Big picture 2) Some details 3) More details


The only thing which I can think of except good tutorial videos is a "teacher" who has the proper knowledge and the sessions focus is about giving you the whole picture.


Material is dense because some me times we don’t know the background material. So you need to understand it. Ask question search internet read books. there is no easy way.


Time and practice, there is no shortcut.

All such information looks daunting at first. But then, over the course of time, things get connected, get familiar, and make more sense.


I use the 1st, 2nd, 3rd pass methods but use SRS.

1st pass is high level concepts, 2nd pass is more details, and third pass is anything I still dont know.


Just as an aside, I'd like to give a hand to the HN community for all the great answers on this thread. Very enjoyable read!


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


As I'm learning something, I cannkindnofnput placeholders/blackboxes in where I don't know the details, but where at this level or stage knowing the details doesn't help advance my understanding of something.

We do this all the time, using simplified models, but for some reason it feels alien when the end goal is to get rid of the model and make it more detailed, like when learning a new codebase.


Only ever by trying to do something with it. To learn information you have to have a ‘hook’ to hang it on.


Learning new things just takes a lot of time. In my experience the method doesn't really make a huge difference. Your conscious effort is the part you control, the unconscious effort you also need to make is not really something you can force. Don't forget to rest/sleep so there is time for your brain to process things in the background.


I usually dive headfirst into a project and start coding. The first step is often the hardest but once you start you will have some difficutlies but be rewarded in the end with a deep understanding of why you should do this or why you shouldn't do the thing you want to accomplish.


By leaning softly but persistently against the problem / topic.


- Recognize that while the jargon is often complicated, the underlying ideas are not. As you read, keep asking yourself what the basic idea of what you've learned is.

- Think about the topic yourself from first principles as you read.

"Economics is the study of how we deal with scarcity.

One approach is a market-based approach where each item has a price and whoever pays the price gets it. However, this isn't really fair towards the poor.

Another solution is a socialistic approach where everyone is given equal amounts of everything. However, this can lead to rationing.

Another solution is the government decides who gets what. It doesn't have to give everyone the same amount of everything. But this is vulnerable to corruption and also this seems like a hard problem to solve.

Another solution to scarcity would be a lottery-based approach..."

- Watch videos on a topic if you're not getting something.


Complicated things are the product of a system of simple things. To do complex things well, you need to be able to do the simple things without consciously thinking about them. Expertise is what happens when a large mass of related things become easy so you don't think about them, so you can think about complex things made from the easy things.

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.


being smart probably helps


practice.


https://fs.blog/2012/04/feynman-technique/

There are four steps to the Feynman Learning Technique:

1. Choose a concept you want to learn about

2. Pretend you are teaching it to a student in grade 6

3. Identify gaps in your explanation; Go back to the source material, to better understand it.

4. Review and simplify (optional)


proper C, get Zed shaw's book python the hard way it has a good deal on proper C coding.


what? zed has an entire series 'learn c the hard way', ignore the python stuff. it'd teach you modern c, but even going completely through that would leave some gaps of whats used in kernel code


The same way you get to Carnegie Hall.


Subway also takes you there


No joke! I learned all my QM, OChem, MolBio, and tensor calculus on CalTrain.


Complex and dense? Wrong crowd, this in HN.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: