
Ask HN: How do you learn complex, dense technical information? - _benj
When in the past I&#x27;ve picked up a reference manual or something of the sort I&#x27;d go slowly, lookup every word I didn&#x27;t understand and started experimenting as soon as possible.<p>But that is quite time consuming and intense.
I&#x27;ve been considering skimming through the whole things to get kind of a big picture of what the thing is and where I&#x27;m going and then going back a second time to catch then the details and experiment.<p>Any other ideas? How do you tackle learning something new and complicated?<p>(ps. the complicated thing for me right now is kernel development, including writing proper C)
======
crdrost
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.

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

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

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

------
Ragnarork
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...](https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723)

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

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

~~~
764_OC
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/...](https://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/paper-
reading.pdf)) which I have adapted to all kinds of technical material, not
just papers.

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

------
IvanVergiliev
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](http://cognitivemedium.com/srs-mathematics) [2]
[http://augmentingcognition.com/ltm.html](http://augmentingcognition.com/ltm.html)

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

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

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

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

~~~
stared
Read "Driven to distraction" [https://www.amazon.com/Driven-Distraction-
Revised-Recognizin...](https://www.amazon.com/Driven-Distraction-Revised-
Recognizing-Attention/dp/0307743152), 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).

------
ncfausti
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://en.wikipedia.org/wiki/How_to_Read_a_Book)

[https://www.coursera.org/learn/learning-how-to-
learn](https://www.coursera.org/learn/learning-how-to-learn)

[https://www.khanacademy.org/science/health-and-
medicine/exec...](https://www.khanacademy.org/science/health-and-
medicine/executive-systems-of-the-brain)

~~~
sgslo
Something similar to this is the SQ3R method:
[https://en.wikipedia.org/wiki/SQ3R](https://en.wikipedia.org/wiki/SQ3R)

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

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

[https://youtu.be/nqYmmZKY4sA](https://youtu.be/nqYmmZKY4sA)

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

~~~
dghughes
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-...](https://www.npr.org/2016/04/17/474525392/attention-students-put-
your-laptops-away)

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

------
Frost1x
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?")

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

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

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

------
confeit
[https://fs.blog/2012/04/feynman-technique/](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)

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

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

~~~
all2
> 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).

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

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

------
ashton314
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](http://ccr.sigcomm.org/online/files/p83-keshavA.pdf)

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

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

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

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

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

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

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

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

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

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

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

------
plughs
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...](https://kubernetes.io/docs/concepts/extend-
kubernetes/compute-storage-net/network-plugins/)

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.

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

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

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

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

------
melling
Feynman Technique is often mentioned:

[https://mattyford.com/blog/2014/1/23/the-feynman-
technique-m...](https://mattyford.com/blog/2014/1/23/the-feynman-technique-
model)

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

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

------
kevas
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?

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

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

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

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

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

------
hasperdi
Write them down, create mind maps and use this article as your guide
[https://fs.blog/reading/](https://fs.blog/reading/)

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

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

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

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

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

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

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

------
girfan
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...](https://web.stanford.edu/class/ee384m/Handouts/HowtoReadPaper.pdf)

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

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

------
aliabd
Check out fast.ai's teaching philosophy.
[https://www.fast.ai/2016/10/08/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!

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

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

------
cborenstein
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...](http://lsc.cornell.edu/study-
skills/cornell-note-taking-system/)) 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.

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

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

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

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

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

------
chadcmulligan
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" :-).

------
wiseleo
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. :)

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

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

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

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

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

------
lewisjoe
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!

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

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

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

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

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

------
brudgers
one of my favorite tech essays,
[https://norvig.com/21-days.html](https://norvig.com/21-days.html)

------
dotjosh
This guy has tons of great content like this:
[https://www.youtube.com/watch?v=Cky0O-hANDI](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.

------
whatthexue
[https://blog.phuaxueyong.com/post/2020-02-15-list-of-feb-
art...](https://blog.phuaxueyong.com/post/2020-02-15-list-of-feb-articles/)

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 (:

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

------
lallysingh
Basically, what he said:
[https://www.scotthyoung.com/blog/ultralearning/](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.

------
logicallee
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=kernel+development+easy+explanation)

[https://www.youtube.com/results?search_query=writing+proper+...](https://www.youtube.com/results?search_query=writing+proper+C+easy+explanation)

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

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

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

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

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

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

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

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

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

------
agumonkey
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 ?

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

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

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

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

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

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

------
beat
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!

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

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

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

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

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

------
leesec
By leaning softly but persistently against the problem / topic.

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

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

------
tsukurimashou
being smart probably helps

------
hathym
practice.

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

~~~
sitzkrieg
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

------
abrax3141
The same way you get to Carnegie Hall.

~~~
tartoran
Subway also takes you there

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

------
goph0
Complex and dense? Wrong crowd, this in HN.

