Ask HN: What is your system for learning new things?
It can be a new programming language, or learning a new subject or subtopic or whatever. What rules do you follow to pick up the new unknown thing?
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.
Very nice way of grasping theory. THEN I implement it all, from scratch.
I may steal this method.
2. Spend a couple hours configuring it
3. Install a bunch of extensions
4. Run into some obscure bug, spend a couple hours debugging it
5. Report the issue
6. Go to bed, satisfied with how productive I've been
This is why I learned to just accept imperfect systems.
Perfect systems just don’t exist.
For the time being I’ve settled on mediawiki per notes and digital garden.
Ymmv.
My notion configuration is so complex now, api posts, conditional formatting and quirky ui features...but I'm still a human blob.
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.
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!
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!
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.
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.
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.
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.
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.
I have dog fed myself 8k and growing flashcards over 4 years =)
- Can you compile and run a basic program?
- Can you “Hello World” your own code?
- Can you effectively re-use your code via functions and subroutines?
- Are you able to effectively work with any OOP classes, enums, structs, and other types, if present?
- Can you create and manage libraries, that can be used by other programs?
- If the language supports it, can you use auto-documentation tooling to provide API and functional information?
- Can you properly debug code with tooling?
- Can you create test cases for your code?
- Do you regularly educate others on the use of this language?
- Are you a contributor to, or the creator of, this language?
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.
Find a tutorial where you build some simple thing.
Then start coding, see what roadblocks you hit, and hopefully those words you indexed will come in handy.
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.
See the four stages of learning model.
Unconscious Incompetence
Conscious Incompetence
Conscious Competence
Unconscious Competence
[1] https://www.youtube.com/watch?v=2xjJXT0C0X4
Oh, before that, my only experience with the electric guitar was a couple of weeks with the game at the start of the lockdowns.
- 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.
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 | | |
--------------------------------
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.
Like I said this is a rough sketch and YMMV.
Good luck.
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.
- 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
- 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.
More ideas: https://www.learningscientists.org/
This way, I may be spending some extra time on reinventing the wheel. But I enjoy programming and this is a hobby project.
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 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!
1. Print the page/article/book as pdf
2. insert printout in OneNote
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.
It boils down to capture, consume, execute and share.
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.
Took a bit longer, but helped tremendously.
If it’s maths I’ll try to copy the book by hand and do the recommended exercises.
If it’s CS ill start with the labs/exercises. I use that as a guide to see what I am struggling with.
If it’s humanities, business etc - I’ll follow the CS path.
Then I do the Feynman method and explain it to someone else.
For things that require pure memorization I do spaced repetition with flash cards and katas / koans.
I start with a YT to get comfortable.
Once things start to make sense, I try to extrapolate that feeling or thought and build something immediately (hoping to be wrong or get stuck).
gets stuck
bp:
Back to consuming but with a more specific intent.
Back to building.
goto bp;
That always works.
More points of view --> better understanding
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.
Good luck!
2. Explore open-source code
3. Dig into language documentation
4. Hack together a working system
5. Refactor until there's a coherent system with a consistent analogy
Sometimes when doc is unclear about best practice to set stuff up, I will consult youtube.
I built a blog and several side projects to learn React, GraphQL, and ended up using them to get jobs.
Plan -> Study -> Practice -> Model
# Plan
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.
Reaching: challenging, ~85% success rate.
Strong feedback: immediate; concise; accurate; direct; actionable.
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.
Edit: formatting
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.