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)
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.
> 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...
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.
- 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
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.
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...
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.
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?")
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.
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.
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.
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.
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 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.
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.
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.
Take a small feature and fiddle with it, it will take some time, but eventually you learn really well.
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.
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.
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 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.
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.
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.
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.
https://mattyford.com/blog/2014/1/23/the-feynman-technique-m...
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?
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.
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.
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.
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.
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.
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.
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.
https://web.stanford.edu/class/ee384m/Handouts/HowtoReadPape...
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.
You wouldn't teach kids soccer by having them practice cone drills without a ball - they need to play a game first!
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.
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".
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.
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.
- 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
Rinse, repeat.
Over time, your brain will make the connections between the parts and the patterns.
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 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" :-).
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. :)
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 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.
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 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.
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!
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.
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.
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.
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 (:
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.
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.)
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.
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.
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.
All such information looks daunting at first. But then, over the course of time, things get connected, get familiar, and make more sense.
1st pass is high level concepts, 2nd pass is more details, and third pass is anything I still dont know.
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.
- 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.
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.
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)