The most important thing for me to really cement something is producing (vs consuming). Reading docs, watching videos... those are consuming. Of course you do have to do these things to get started. When most hackers thing of producing they probably think of building something - meaning coding a small project - but for me, to really really learn something, absolutely nothing comes close to teaching it to someone else.
So when I want to learn something really well, I prepare to teach a course or give a lecture. Sometimes there is some synergy between what I'm working on and what other junior engineers on the team are working on, and if they're amenable I'll try to teach them what I know. But even if I don't have an audience, I'll tackle a tough concept by prepping to give a lecture on it. That includes practicing in front of the mirror, or doing live coding, and speaking out loud to myself.
I haven't done any blogging but writing (after the fact, not while you're consuming the course or docs or book! forcing yourself to recall is essential to cementing into long term memory) can also be helpful.
Let's say I'm doing a course on async Javascript and the instructor explains how promise.all() works. Instead of a bunch of bullet points just regurgitating the course, my notes will just say "TODO: Implement promise.all()". Then I go and do that a day or two later. This creates a surprisingly long lasting memory, for me at least.
Honestly this. When I learn something and want it to stay in my mind, I used to make videos. Then I’d narrate the videos and listen to myself, see where I actually fall short in understanding. I’d go for a drive and speak out loud in the car “Ok, so leader election in RAFT works like this”.
Very nice way of grasping theory. THEN I implement it all, from scratch.
Killer apps are hard to find. I recently thought to myself “I have notes scattered across five different services, I should consolidate them” - so I dove into Obsidian, got it all set up to cloud sync, transcribed some of my existing notes, categorized them, aaaaaaand… a year later, I now have notes scattered across six different services.
That sounds familiar! I now use OneNote just because I know it syncs and I don't need to do anything. Making notes is important but start with a dump of links of resources, then start adding comments, so you don't forget. Once you're more confident in your understanding you can refine the notes into something sensible (if you get to that point!).
A shortcut that I use for learning new technologies is to learn their pitfalls and tips.
For example: I want to learn the PostGIS PostgreSQL extension. I install the extension and make a sample database with PostGIS datatypes. Then I will make a bunch of the following searches:
"postgis gotchas", "postgis tips and tricks", "postgis common mistakes", etc. Open everything you find in a new tab.
Then I will edit the sample database to try to reproduce each of the bugs or tips, and understand why they were problems and what the correct thing should have been.
I learned this when I was learning C++ in college from the book "Effective C++", which is basically a list of common pitfalls paired with a discussion of how to avoid them. This hones the parts of my mental model that were wrong or underbaked.
This is what I really liked about Paul Hegarty’s iOS dev course. His projects sort of deliberately walk students into the common pitfalls so that you can try to figure out a fix on your own and then he explains what/why/how Swift behaves that way.
He doesn’t deliberately teach you incorrectly but he’ll set up the project in such a way that when he asks you to add X he expects the vast majority will think “oh I just do this” which doesn’t work because the real answer is a bit more involved. Bonus: when you start spotting the pitfalls ahead of time it’s super motivating!
1. Find the best book (or books) about the subject
2. Read it. Probably do some hands-on stuff while reading (e.g., writing simple programs if I'm learning a new prog. language; install a db in a VM and execute queries if i'm learning about dbs, etc.)
3. Let it sink
4. Read about the subject in blog posts, articles. Stuff like "best practices", or something like that
5. Let it sink
6. Come back in 1 year, and do it again. In the meanwhile keep doing some practical stuff, but not much
7. Profit
The good thing about this approach is that it's lightweight so I can do learn multiple things in parallel. After 3 or 5 years, all the knowledge accumulated pays off really well!
"After 3 or 5 years, all the knowledge accumulated pays off really well!"
I call this "compounding knowledge." I take any excuse to learn new skills, tackle new projects, and accumulate new information. After a long enough time, those disparate skills become complimentary and connected.
My analogy revolves around collecting keys that unlock future doors.
1. Find a good textbook on the topic that is around the right level for you, and that also has many practice questions in it. 'Good' is determined by a combination of reviews plus an initial skim of the book.
2. Read and work through the textbook. Use Anki to memorize the key points/equations and do the practice questions as you work through each chapter.
3. Continue to use Anki for several months/years to review the things that you learned. This only takes a few minutes a day, but the benefits are astounding.
Anki is great. I have a default deck named 'Stuff I want to remember', that I can just throw in anything that at some point I wished I remembered. Works great
I have three techniques that never seem to fail for me in increasing order of complexity.
1. Write a blog post about it. I'm an old school blogger and my best learning tool is to immediately start writing about it. I'll do this even before I've used the thing in question. Another writer here talks about producing versus consuming and that's the magic -- this shifts you immediately into being a producer. Most things you try and learn aren't that hard when you start actively engaging with the topic by writing about them.
2. Write test coverage. If it is a software technology then I'll start to use it by writing out the tests needed to use it. I find tests always make software technologies much more understandable because, inherently, they force you to think very atomically.
3. If I really, really want to understand something in depth then I'll create a side project about it or that requires it. Just for example I'm currently doing this as a way to force myself to build better web apps. I've chosen HotWrite and Turbo as enabling technologies and now I've got the core of a neat little app that avoids full screen redraws, uses CSS I actually understand and so on.
Great question. Here is one thing I do, for math/ML related topics, when reading a paper or a textbook or blog.
At various stages of your reading, act as if you’re inventing it — understand what problem is being solved, and before reading on, pause, and really think (with notebook and pen), how YOU would solve it. Try various different angles and really struggle with it for a few hours or a day or a few days. Only after this struggle, continue reading. This way you will have several AHA moments, these will be invaluable for your comprehension and retention. This applies even if your struggle did not get you anywhere (and ESPECIALLY if you failed to get anywhere).
In particular if there is a lemma or theorem, first struggle try to prove it yourself, only then read the proof.
Not being a software engineer I’ve been relearning to code again, and after a deep dive dived into a new framework. Which was a headf*k to put it mildly including server config etc.
What I re-learned was the “arc of despair” that initial period of complete disaster where everything wasn’t just confusing but incredibly difficult. And many many times of asking myself of whether this was worth it and whether I shouldn’t just pay a “professional” to do it. Then within days I was swimming fluently. Was a strong reminder of the various stages of being auto-didactic. The need for faith :)
And yes, in the end it was worth it, because the lateral connections and first principles you learn (complete with new learnings and questions) allows you to go much deeper than simply paying someone else to do it. Was a reasonably profound experience.
A big thing for me is going simultaneously top-down and bottom-up.
Top-down establishes the high level concepts, underlying motivations, etc. It provides a map of what there is to learn and a scaffolding upon which all new knowledge and concepts can be secured and contextualized.
Bottom-up is where the rubber hits the road. Because disrupting a system and seeing the effects of that disruption is key to learning, bottom-up is a very active and iterative process. Write the “Hello, world!” program, and then see what happens when you change the text, remove the semicolon at the end of the line, etc.
My own study tool, studywand.com - I collect youtube videos + pdfs, and learn through regular (AI-generated) quizzing based on the videos/documents. For papers/ideas I add manual flashcards. It's based on my psychology of learning dissertation and Comp Sci undergrad, and I get to label and improve the service as I use it!
I have dog fed myself 8k and growing flashcards over 4 years =)
I like to build side projects. As a general rule, I always have a few "in the works".
And when I do, I always find myself making the same mistake-ish: trying a bunch of new things, as in languages, libraries, paradigms, concepts, whatever.
The bad part is that it usually derails the whole project as I hit roadblocks, unsupported features, abandoned dependencies, etc.
The good bit is that I get to keep learning things even if my day job is with a very stable and boring tech stack. And I'm usually familiar with the cool shiny toys before they become mainstream.
So that's when we're talking about tech stuff. For the rest, I procrastinate a lot here on HN and on Wikipedia and similar places, so I just read a lot on whatever seems interesting.
For example, I learned to really shred on the electric guitar by loading this[1] custom song into RockSmith.
I followed a given section of the song at 1% speed and only increased it by another percentage if I performed it perfectly 5 time in a row. It was an all-day process, but now, years later, I can play it with hardly any effort.
My dad is a power tumbling coach and we also have the 5 perfect passes rule. The kids are eager to learn new tricks. They are young and feel like they are indestructible. When they want learn an advanced trick we make them do the base of that trick perfectly 5 times. If it's not perfect, back to 0. They don't like it but the basics have to be muscle memory, subconscious actions before we allow them to move on to the more advanced trick. For physical activities like these repetition is key.
My newest way is actually YouTube! Often there’s a talk by someone good introducing or describing the technology which is greatly informative (I typically don’t find tech YouTubers to be worth the time though).
- Emacs/org-mode/org-roam managed notes, with org-attached stuff, linked stuff (mails included via ol-notmuch) and live links (elisp:)
- a timeline (a note per month, org-captured headings inside)
- topic notes filled from links to timelined notes (eventually with org-transcode)
- a limited query system via org-mode templated in-drawers k/v pairs and org-ql, like a link on an author name in a note who gives all noted books from him/her)
- boilerplate notes (previous systems notes, unfinished etc)
- counsel-rg (ripgrep, search&narrow style UI) for bare full-text search if needed
- roam_aliases abused a bit to match anything I've tried to search a heading without finding it immediately, for the next time I access it
It's NOT complex as might sound. It's not hyper-effective, lacking a kind of "data structure" who allow things like live queries, semantic search and other modern dreams and tools at a certain scale, but offer a quick enough way to store and retrieve information, a way to traverse it both to discover and to consolidate, eliciting things out of noted stuff and a sufficient "outline of anything", since this system in NOT just notes but also pretty anything, for instance my NixOS config is tangled from a dedicated note, so my zsh, Emacs is partially (I still have to complete the last post-bankruptcy re-write) tangled from org-mode notes (one per personal package-to-be) and so on.
Essentially this system give me a way to access almost all my infos in a search&narrow style instead of manually traversing a file system, having pure textual information under a common root and "the rest" aside I can quickly search without keeping a local YaCy/Recoll or some other Solr and co frontends and still have "metadata rich" links to non-org-mode files via org-mode links and headings.
I just cooked up this description of my system. it's a work in progress, not a formal commitment.
It distinguishes between two types of learning that are easily conflated and two relationships I might have to a subject:
| Already | Don't |
| Do | Do |
--------------------------------
Learn | | |
About | | |
--------------------------------
Learn | | |
To Do | | |
--------------------------------
Most subjects naturally fall into Learn-About/Don't-Do because there is no way of doing them...e.g. The Pax Romana, Hydrogen, Milly Vannilly.
Operating Harbor Freight Sawmills, Applying Category Theory, and Using Vim are also in Learn-about/Don't-do because I don't do them and even though I could learn to do them, I'm probably not going to start doing them any time soon (if ever).
Learn-About/Already-Do is not that different from Learn-To-Do/Already-Do. The main difference is the timeline. Learn-About is in the immediate or short-term future. Learn-To-Do tends to be long term and broad.
Pick something you know how to build already, a familiar concept reduces a variable in the learning process and build something for yourself using the new tool or subject. Whether it be writing a blog/review about it or coding a medium sized project in the new language.
Find a reference or a sample codebase (which may be a tutorial or someone else’s project/blog or a by-example documentation) and copy, copy, copy, copy and copy. You always learn better by copying first and innovating later.
Predict how the the new language/subject should work according your current knowledge and iteratively improve your predictions based on subsequently being proven wrong again and again till you know all the good ways to do something and why this particular project/language/book chose to do it this way. Then pick up another book/reference on the same topic and repeat. Never trust a single source, always aggregate information and judge for yourself, only giving little weight to authority.
If you want to get really good at something you have to spam it. To that end find an IRC or discord channel meant for that topic and interact on the topic there as well.
Most new things I learn, are somehow related to solving problems that have piled up in the years. So, I just pick out that problem, try solving it with this new thing I've learnt. I start with watching a video on its simple usage or, read some sort of documentation on it. I wouldn't per say call them rules, but more of a guideline.
I'm computer scientist that finished my studies in the 2000, without system other than, going to university, getting drunk, repeat. In last years however I finished a master in game development and I'm working through a master in philosophy. I think i found my strategy: 1: Wake up 5:30 and start my day studying, while the house still quiet. Every single moment that I have free I'm either learning with audio books or extra material (coursera, udemy, etc), before going sleep review the stuff that I studied in the current day. Lunch time, I use to reflect about what I'm learning. From Sunday to Sunday. I have a full time job, sports and family, but I limit myself to sleep 6-7 hours day, no netflix, no video game (unless it was part of the studies ;) and no social media. Full immersion, is the only way for me, otherwise I give up.
im currently spending my time off work reading and understanding Jung (im a software engineer). here's what i did that helped:
- identify the names of the basic concepts that the author uses throughout his/her work. no need to grasp their precise definitions, the goal here is to get a sense of the author's vocabulary of key words. this is easier to achieve for certain authors, especially if they use sensible names that are not too abstract nor too "far" from the concepts they represent. introductory texts, wikipedia pages, youtube videos are very helpful in this regard.
- understand the key words more precisely. once you've identified the key concepts, the next step is to understand their definitions, and how they are used by the author. focus on the context in which they are used. the trick here is to use the key words as pivots for understanding the sentences in which they appear. as you read more, you will see the same words reappearing in contexts that are similar. secondary/complementary texts, primary texts+study guides can come in very handy in this step.
- deep dive. at this point, if youve done your work, you should be able to see the key words and understand them without having to consciously recall what they mean or represent. for most people this is good enough, but if you want to know more (to be able to synthesise new thoughts or relate them to existing ideas in your head), you can go further and start diving into primary texts written by the author.
more general tips:
- study every day if you can, this helps with retention
- take notes, pen and paper if possible (i find that concepts retain better when i write them down, for me personally at least)
- focus, sometimes i find myself scanning through sentences without actually reading them (this is usually a sign of fatigue, you might want to take a break when this happens)
- if you are learning something practical, make sure to practise applying them
Teaching others is a great way to learn new things yourself.
- Often people ask about things that I wasn't even aware existed. For example someone asked how to get Svelte Inspector to work, and I discovered a wonderful tool.
- You don't really understand something until you can sell/teach it to someone else. I had implemented Functional Core, Imperative Shell[1] a few times, so I thought I understood it. However, when I tried to explain why this concept was such a game-changer to someone not familiar with functional programming, I couldn't articulate it very well. Thinking about how to persuade them really helped me organize my thoughts about it.
Anki is my number one tip. For anything you need the basics nailed down to build more knowledge on top and spaced repetition keeps your foundations solid.
A small correction : irrational should be replaced by imaginary. An irrational number is a number that cannot be represented as a ration of two numbers, like sqrt(2)
It depends on what you've learnt, the way is different. According to my experience:
1. If you are learning something small, like a function API usage or a language sugar, find a suitable doc, and write some simple test cases to verify that you understand it correctly. Absolutely, you can write down some notes about it.
2. If you are learning something complicated, like mastering a web framework, or master a new programming language, such tasks cannot be done in one day. You need to break down your learning goal into several smaller goals, and make a feasible study plan. That way, you'll get closer to your ultimate goal every day.
A notepad and a pen to log my messups. Writing them seems to register better for me.
A POC/Sandbox to play with in ways I don't need to worry.
Getting some hands on functioning code that I can break and see why it broke, so a good debugging configuration.
Documentation - During the 'calm' times I will go through the documentation and try to appreciate where the creator is coming from.
After all that, when I feel confident-ish. I will create another project using that particular library/methodology/advice etc and see how to improve for my needs.
This may not be the best/most optimized method but it works for me almost by osmosis!
3. Read printout on iPad: highlight important info, add my own notes on the side, add tasks if I need to look up sth
4. Collect my notes in OneNote page, look up tasks.
If I am learning something new, I usually start with Wikipedia and grow from there. Lately, I am also using ChatGPT to look up stuff I am curious about. Prompt I usually use: "Explain to me XYZ from first principles". I write stuff down in OneNote and query stuff I dont know + supplement research with other sources.
Do you trust that ChatGPT will give you the right answer? It often messes things up! It told me that the Catalan language spoken in the west of the island of Minorca is influenced by the language spoken in the west of the Iberian Peninsula, which is completely stupid. ChatGPT does not understand the concept "west".
My notetaking process is my learning process, i derived it from how my mind functions so it's very specific to me but I've documented it here if you find it useful.
It boils down to capture, consume, execute and share.
My go-to for learning new programming languages is project E. The problems progress very nicely, from simple loops to combinatorial search and beyond. But my favorite thing about it is it's all math. I can't really be bothered to solve someone's train routing problem, but you don't have to ask me twice to sum the factors of a 150 digit number.
One recent thing I was playing with I fed ChatGPT the docs. The summaries that it spat back out were much better than the docs at explaining what was going on as the missing context was in the corpus. It's an interesting approach and likely one I'd repeat for other tasks in the future.
For technical stuff that's more on the practical sid of things I usually build projects. If it's from a guide, I try to switch out things to force me to think.
For example, I read a book about smart contract development.
They used JavaScript, Truffle and web3.js, but I did it with TypeScript, Hardhat and ethers.js.
I remember that I don’t learn by doing, I learn by doing and then resting. That way I don’t get frustrated when something doesn’t make sense: I know that if I keep trying, eventually I will come back to the subject and realize I already know what I was struggling with before.
I set up a project, and ship something. I may find a sample project, somewhere (usually a personal blog, or Medium article, as opposed to Stack Overflow), and crib off of that.
I immerse myself fully into that topic and surround myself with relevant content incl. books, videos, communities (Discord, Reddit, forums) and, of course, try to start using that skill/thing early and constantly. This is the case with both programming languages, and human languages or things like mathematics as well.
You just have to be ready and push through the many possible embarrassments and mishaps on the way. Online courses, e.g. from Udemy can likewise transmit to you how a particular instructor or a person approaches, talks and reasons about problems in that technology so you get that, while being part in various feeds and communities you will gradually see and be exposed to relevant current topics that are being discussed in that sphere.
Books pave the way for deeper and more concentrated understanding while on the other hand pushing yourself to interact and discuss with people about things, as well as constantly consuming content in that language helps you condition your mind to that environment. I sometimes make it a kind of a firehose that fires at me so I get ”immersed” with the thing I’m learning.
Oh, and of course, either early on, but rather even after first increasing your vocabary, spend time on reading through the documentation (this worked for me learning React.js, the current Beta docs, where I was coming from Vue.js before, same being the case as well for things like Django and RoR), or just learning the grammatical details or, so to say, syntactical details of a language after having some ”vocabulary” under your belt(in no case neglecting the ”boring stuff” either).
I’d call such an approach an ”immersive” one or something. But you have to be somewhat committed and motivated so it starts to pay dividends over time and you get more comfortable.
It’s not easy, so remember to spread this across a wider timespan, set goals and be systematic with your approach to learning.
This is how I learned programming in high level languages like JS and Python and became fluent in German in addition to English, Finnish and Russian.
Then what can happen, if you get too far and harsh on yourself, of course, is that you get burned out, so be careful and take care of yourself.
But it’s all part of life, so I guess just one more thing. Try to ensure and be confident that you learn the right things for yourself, it’ll help a lot.
Learning things just for the sake of learning is nice too, but over time you’ll get frustrated and start to ask yourself questions. E.g. Why learn Spanish if you never plan on using it? You’ll be able to form a sentence or two, but that’ll be just about it.
Set a small, specific goal. Brainstorm topics which might help. Research if experts agree with topics.
Classify topics: conceptual - deeply understand; factual - memorize, little understanding; procedural - practice, little thought.
Qualities of concepts: three Rs - read, recognize, react; many paths to a good result; highly flexible, agile, interactive; recognizing patterns instantly; overcoming complex obstacles; making smart, timely choices.
Qualities of facts or procedures: ABC - always be correct; few or one path to an ideal result; imagine the performance of a reliable robot.
Find good learning resources for each topic. Try to match topic classification. Try to find all learning modes (see, hear, do). Research thoroughly. Good resources save time. Emphasize or exclude parts based on goal.
Brainstorm obstacles. Find ways to overcome those obstacles.
# Study
Review prerequisites before studying. Break learning resources into chunks.
Prepare to study a chunk: preview relevant exercises and tests; scan major elements of content; generate questions from scan.
Study a chunk: consume content; try to use all learning modes (see, hear, do); take notes, and highlight key parts; answer questions from scan along the way.
Improve chunk retention and comprehension: do free recall (no prompts); consolidate notes and highlights; do active recall (exercises and tests); connect it with other knowledge; try to teach it to an imaginary student; utilize spaced-repetition.
Repeat process with next chunk. Add practice when knowledge can become skill.
# Practice
Structure practice with scrimmages and drills.
Scrimmage: good for concepts; open-ended attempt in a realistic scenario; projects, immersion, simulations; replicate complexity and uncertainty of reality; focus on making a high number of varied reps; aggressively explore and experiment.
Drill: good for facts or procedures; use the REPS method; size: proficiency within 1-3 sessions; repeat and master a chunk before moving on.
The REPS method: R - reaching and repeating; E - engagement; P - purposefulness; S - strong feedback.
Common drills: time slice - small sequence in longer one; copycat - copy in irrelevant parts; magnifying glass - one aspect among many.
# Model
Find and steal from experts. Study examples of excellent work. What are the specific, critical elements? How do experts perform differently than I do? Identify process, performance, and results.
I think creating the system for learning the thing is part of learning it, and the system will differ for each thing. Sometimes there's already a system I can download, borrow or buy. Sometimes I'm not happy with that so I come up with something else.
For example when I wanted to learn how to read music, I looked up all the information I could on how to read music, but I wasn't satisfied with it so I came up with my own system for learning to read music without using note names, then later I found that someone had done something similar because after I had developed the system I kind of had different terminology to search.
But when I wanted to learn Chinese, I downloaded a few apps and found a good one I liked, and I use it every day. I also found a good Chinese podcast that I listen to while walking, running or driving. I didn't have to come up with a better system, the apps are good.
When I wanted to learn how to swim better, I looked on YouTube for good swimming techniques and ultimately found Total Immersion, so I practised that by following the video instructions and swimming all the time. But then I found I couldn't speed up and there are no coaches for TI swimming, so I just took some advice from faster swimmers.
When I wanted to learn how to touch type as a teenager I just used a touch typing application that I found in a big box of old floppy disks next to the computer.
When I wanted to learn about MMT I read books, watched hours and hours of YouTube videos, communicated with academics, created my own content about it explaining it to others and discussed it online.
When I wanted to learn about physics I watched all the Leonard Susskind Stanford lectures on physics.
When I wanted to learn how to eat more healthily I listened to some podcasts while walking, I did take a couple of notes on some things, but then I immediately put those notes into practise by finding a couple of simple recipes I could work into my daily routine. I'll never forget those things, because I practised them immediately.
Another example of this type of learning was when I wanted to improve my chess: I didn't do lots of study, I just learned that using openings and defenses was more useful because a good strategy sets the board up better than trying to fight tactically all the time. So I learned one opening (Queen's Gambit) and one defense (Hippo) very thoroughly, and then practised chess a lot by playing simultaneous games in an app. I minimised the amount of information I would need to remember, then did lots of practise. My chess playing improved a lot!
I don't usually bother taking notes on stuff in any sort of structured and searchable way, but sometimes I write about what I've learned, and I will quite often share the most interesting parts with people in conversation, sometimes I can't quite remember something, so I'll look it up again.
If something's really interesting and I consume a lot of content about it, then usually the same concepts pop up time and time again, so I don't really have to bother note-taking, it just sticks in there because I hear it over and over again. A good example of that is Mixergy: when I first started listening, I worried about how I would remember all this amazing information, but then Andrew as nice enough to have a chat with me via Skype (in 2011!) and he told me "don't worry, all the best info comes up over and over again, it'll be in your brain when you need it" and he was absolutely correct.
Usually it's enough to know the thing I forgot exists, because I can just look it up again online more easily than I could search it in some notes that I'd taken.
So when I want to learn something really well, I prepare to teach a course or give a lecture. Sometimes there is some synergy between what I'm working on and what other junior engineers on the team are working on, and if they're amenable I'll try to teach them what I know. But even if I don't have an audience, I'll tackle a tough concept by prepping to give a lecture on it. That includes practicing in front of the mirror, or doing live coding, and speaking out loud to myself.
I haven't done any blogging but writing (after the fact, not while you're consuming the course or docs or book! forcing yourself to recall is essential to cementing into long term memory) can also be helpful.
Let's say I'm doing a course on async Javascript and the instructor explains how promise.all() works. Instead of a bunch of bullet points just regurgitating the course, my notes will just say "TODO: Implement promise.all()". Then I go and do that a day or two later. This creates a surprisingly long lasting memory, for me at least.