[HN Gopher] How to Learn Stuff Quickly
___________________________________________________________________
How to Learn Stuff Quickly
Author : joshwcomeau
Score : 212 points
Date : 2021-07-19 14:20 UTC (8 hours ago)
(HTM) web link (www.joshwcomeau.com)
(TXT) w3m dump (www.joshwcomeau.com)
| devnull255 wrote:
| Incorporating the "learning x the hard way approach", which is
| about typing the code, rather than just copying and pasting the
| code, also aids with learning quickly and giving more lasting
| power to the lesson. The best part of this is the mistakes you're
| more likely to make by typing, which forces you to look more
| closely at the original code so you can retype it correctly. I
| remember much more that way. Even more than that, making such
| mistakes may draw more attention to the object in error and
| consequently learn more about that object and how it fits into
| what you're trying to do.
| throwawayboise wrote:
| Came here to mention typing vs. copy/pasting. When going
| through a tutorial, don't copy and paste. Type out the code. I
| turn off code-completion in my editor as well.
| milross wrote:
| I do think that all of us have a different take on how we should
| learn stuff quickly. Some of us learn through visualization; some
| of us learn by doing the stuff itself. It's just a matter of
| finding the best method for you to learn different things.
| 6gvONxR4sf7o wrote:
| > If you only follow guided resources, you'll wind up in tutorial
| hell.
|
| I disagree very strongly here. You can wind up in tutorial hell
| if you only read surface level small to medium sized posts.
|
| My "career superpower" is that I'm always working my way through
| one textbook or another. You get serious depth this way and avoid
| getting stuck with a surface level understanding. Plus, with
| depth you can end up with really strong fundamentals, which make
| learning the next thing that much easier.
|
| I know a lot of people who read tons of blog posts on topics but
| never crack open a textbook, or people who watch youtubers
| explain academic papers yet never open up the actual paper.
|
| Maybe my "learn stuff quickly" trick is... don't. Spend a decade
| accumulating deep knowledge slowly, and it'll add up. The road to
| "tutorial hell" is paved with blogposts and missing fundamentals.
|
| (I like the rest of the post)
| maaand wrote:
| two thumbs up for this comment ^
|
| May I ask you some text books you've read and on your reading
| list?
| 6gvONxR4sf7o wrote:
| Oh man, it's tough to answer this one well. I just counted up
| the books I've worked through on my shelf. After college,
| I've gone through about 15 completely, and partially worked
| through another 15 or so. Plus a couple reference texts that
| have been handy. Plus a huge number of papers. They take up
| nearly twice the space my old college texts do, which is kind
| of wild to look back on!
|
| Are you curious about anything in particular? Or if you're
| just wondering what kind of books I'm talking about,
| highlights include CLRS, Probabilistic Graphical Models,
| Mostly Harmless Econometrics, and Characters & Viewpoint.
| Next up on my list are more creative writing books and a
| couple theoretical stats books (I'm working towards a book on
| semiparametrics, but first need a better foundation to follow
| a book I've been recommended).
| dhosek wrote:
| Although a _lot_ of computer books in the last couple decades
| have bought into the model of "let's teach the language through
| building a project" structures which often means that they skip
| key stuff or shoe-horn it into the project in ways that don't
| make sense.
| Lordarminius wrote:
| > You can wind up in tutorial hell if you only read surface
| level small to medium sized posts.
|
| This.
| wolverine876 wrote:
| Agreed. The OP says,
|
| > It's often said that the internet has democratized education:
| the sum of human knowledge is only a Google search away!
|
| Mediocre to bad information is a Google search away (unless
| it's Google Scholar). Generally speaking, the published
| knowledge is orders of magnitude more valuable; don't waste
| your time and pollute your thinking on what you find on the
| open Internet.
| ddelt wrote:
| The author has definitely read "Ultralearning"; I highly
| recommend this to anyone interested in this sort of topic on
| metalearning.
| shoto_io wrote:
| That guy coming in from the side at 50% or so is really creepy...
| edo9k wrote:
| Yeah! I can't remember when was the previous time a web page
| startled me like that. But it was effective, you have to
| recognize that.
| shoto_io wrote:
| Yeah it was! I agree
| roadbeats wrote:
| I found it a fun way to ask for email and actually signed up
| myself.
| allenu wrote:
| I think the fact that it slides in slowly is what it makes it
| creepy. I was scrolling/skimming the article and all of a
| sudden I saw movement to the side and it freaked me out.
| YeGoblynQueenne wrote:
| Noone has linked to this yet? OK, I will:
|
| _Teach Yourself Programming in 10 years - Peter Norvig_
|
| https://www.norvig.com/21-days.html
|
| _Why is everyone in such a rush?_
|
| _Walk into any bookstore, and you 'll see how to Teach Yourself
| Java in 24 Hours alongside endless variations offering to teach
| C, SQL, Ruby, Algorithms, and so on in a few days or hours. The
| Amazon advanced search for [title: teach, yourself, hours, since:
| 2000 and found 512 such books. Of the top ten, nine are
| programming books (the other is about bookkeeping). Similar
| results come from replacing "teach yourself" with "learn" or
| "hours" with "days."_
| vmh1928 wrote:
| I thought this was going to be about how the brain functions, as
| in how new neuron connections are created and then reinforced.
| Although the author talks about his approach to using guided and
| unguided/independent learning it it could be reduced to 1.) use
| guided learning to establish the initial connections in the brain
| and 2.) do things independently as a way of recall which
| strengthens the connections and causes new ones to form. A third
| option would be to teach others; nothing like having to explain
| something to someone to trigger the recall of material and
| exercise those neuron connections.
| dvfjsdhgfv wrote:
| The third option is actually an extension of the second.
| [deleted]
| supernovae wrote:
| Just practice things. That's it. "Quick" is hindsight, learning
| _is_ the activity.
| lawn wrote:
| You can practice things more or less efficiently. There's
| absolutely more than "just put in the time to practice".
| nuclearnice1 wrote:
| There's no transferable guidance on how to practice?
| rohitpaulk wrote:
| When it comes to software, one approach that has worked really
| well for me is "Build your own X". Re-implement a tool from
| scratch (minimal feature set, not production-quality code) and
| learn how it works under the hood.
|
| I've done this myself for Git, Docker, Redis, SQLite, Shell and
| more - it requires patience, but I've found the approach very
| effective.
|
| There's a GitHub repository with a huge list of similar tutorials
| that you can follow: https://github.com/danistefanovic/build-
| your-own-x.
|
| I'm building a programming challenges platform based on this
| format, if you'd like to check it out: https://codecrafters.io/.
| ncfausti wrote:
| Obligatory nod to a course that changed my life:
|
| https://www.coursera.org/learn/learning-how-to-learn
| mandeepj wrote:
| Can you please share more details on how it changed your life?
| Are you a fast learner now? Can you also draw the contrast
| between your earlier and current learning approach?
| BossingAround wrote:
| And an obligatory counterpoint that the course is incredibly
| shallow.
|
| 1. Pomodoro
|
| 2. Test often
|
| 3. Just start learning, you'll start liking it
|
| There. You've just taken the course.
|
| Of course this comment is reductionist. But the course, to me,
| could be a medium-length article with the same effectiveness
| (but much less feel-good, "you can do it" content).
| deltron3030 wrote:
| Immersion into the topic and developing my opinions and taste
| first is what makes learning things quicker for me. I can be my
| own guide if I know the territory and have my preferences, and if
| I know what to do before I learn how to do it. Key for me is to
| spend enough time exploring a topic and getting passionate about
| it.
| nickjj wrote:
| I've never found anything that worked as well as:
|
| 1. Become aware that something I'm interested in learning exists
|
| 2. Watch and skim a bunch of videos at 2x speed around the idea
| of the thing (usually keynotes or videos created by the author)
| to get hyped up
|
| 3. Go through the documentation's getting started guide while
| following along
|
| 4. Immediately start building something with the new thing
|
| Treat everything beyond this as question driven development[0] or
| basically JIT (just in time) learning.
|
| _For context the first 3 steps are usually no more than a
| weekend or a few days._
|
| I do this loop all the time and it hasn't really failed yet for
| learning all sorts of things (5+ programming languages, a bunch
| of stuff about Linux, Ansible, Docker, Vim, Terraform,
| Kubernetes, video production, and the list goes on). These are
| learning things very quickly at a level where you can comfortably
| bill out freelance work or get employed.
|
| [0]: https://nickjanetakis.com/blog/learning-a-new-web-
| framework-...
| evnix wrote:
| this works for programming, but I tried something similar to
| try learn some guitar and I had no luck.
| ozarkerD wrote:
| Question driven development is a great name for it.
| Jarwain wrote:
| Any advice for dealing with tool choice paralysis?
|
| I've been interested in getting into video editing and music
| production, among other things, but I tend to get stuck trying
| to decide between different tooling and it saps my drive. I get
| the idea that I should just pick one and run with it, but get
| stuck on trying to pick the "best". Which I guess I tend to
| define nebulously, since some tools might be easier to learn
| but others are more powerful/featureful, etc.
| asauce wrote:
| It does depend on the situation, and how easily you are able
| to change tools down the road. However analysis paralysis can
| be a never ending cycle, so at a certain point you need to
| accept that you just need to pick one.
|
| If its a low cost, easy to switch tool then I'll force myself
| to stop over analyzing and just dive into the tool. Theres no
| better way to learn a tools shortcomings than actually using
| it.
|
| A high cost tool is a lot more difficult. Personally, I
| assign myself a deadline to pick the tool (eg this week I'll
| research, next Monday I'll purchase) and then I must follow
| through on that day. Otherwise I will just keep overanalyzing
| every single comparison until neither tool looks attractive.
|
| There are situations where you are going to pick the wrong
| tool. It happens. An example is I started music production in
| Logic Pro X, hated it, and ended up switching to Ableton. I
| spent a _lot_ of time researching the two, but it was only
| once I started using them that I realized which tool suited
| me better.
| afarrell wrote:
| Find a person (vlogger, friend, teacher) whom you feel
| inclined to trust and just pick what they use.
| notapenny wrote:
| Just pick one.
|
| That's probably more simple than you'd want to hear, but
| there is no such thing as "best". If you search for the best
| in anything, you can find tons of posts/articles/whatever all
| suggesting different tools are the best. That's the beauty of
| the internet. You'll always find something to substantiate
| your assumptions, or in this case make you doubt them.
|
| I can only speak to your music production ambition, but I've
| spent way to much time looking for the best DAW,
| compressor/effect/synth plugin, best hardware. All those
| things are distractions. See which ones are popular and
| available for your platform and pick one. Learn to produce
| music first, it doesn't matter what tool you do that in, if a
| year from now you end up deciding you don't like your tool
| you can still change it. Its like worrying about which
| language to program in without even being able to write
| simple programs. Just pick one.
| umvi wrote:
| My rule of thumb is: if it's free choose the most popular
| one, if it's paid pick the perceived second best one (usually
| better value for your money).
|
| Version control system? Git (most popular)
|
| Linux Distro? Ubuntu (most popular)
|
| CPU? AMD (perceived second best)
|
| Rideshare? Lyft (perceived second best)
|
| DAW? FL Studio (perceived second best)
|
| This system has generally worked out well for me. Note that
| the popular choice is just to get me started because it
| usually has the best troubleshooting/community resources,
| years later when I'm more experienced sometimes I'll switch
| to something less popular (for example I no longer use Ubuntu
| in favor of openSUSE Tumbleweed).
| copperx wrote:
| So, React over Vue and Vim over Emacs?
| vangelis wrote:
| Why the second best?
| nickjj wrote:
| It's my biggest weakness, so it's definitely not like I have
| this fully under control.
|
| The problem I have around tool paralysis is mostly related to
| permanence, especially when each choice is technically really
| good but has their own individual known flaws.
|
| I'll fearlessly try a bunch of things out, implement the same
| project in each thing, compare my results and then pick one
| based on what feels best for me when the thing I'm
| implementing doesn't take a long time.
|
| Editing a specific video is a great example of something with
| little permanence. You can try out a few audio / video
| editing tools in a few days while you actively do your
| editing and then pick the one the best meshes with your brain
| and stick with it until it becomes a problem. Each video
| might take a few hours to edit from beginning to end, and is
| a self contained unit for the most part. That's what makes it
| feel pretty temporary to me.
|
| But for me, building a long living web app, or the idea of a
| SAAS app is one of the hardest things to pick a language or
| web framework for because you can easily talk yourself into
| thinking "well this is my potential life, it needs to be the
| right tech choice or I'm stuck with the wrong decision
| forever".
|
| But this is an illusion. I know it's an illusion, I've proven
| to myself multiple times it's an illusion and there's
| countless examples online showing this is an illusion but
| damn it, this permanence magician is really good so I often
| find myself going back and forth, implementing bits and
| pieces in 1 thing but never feeling motivated to finish
| because I always think there's something better just around
| the corner.
|
| With that said, the thing that pushes me over the edge to
| actually do it is usually the act of making a decision and
| running with it. Knowing full well this isn't a perfect
| solution but a perfect solution or tool or tech stack doesn't
| exist. It's just picking the thing that checks off the most
| boxes on what you like and prefer and then embracing it.
|
| In the end, nothing beats your own personal experience. If 7
| people say a tool sucks and 3 people say the same tool is
| amazing that doesn't mean the tool sucks. It means 3 people
| found a tool they really like and it's working for them.
| Don't let reviews or others fully control your decision.
| Absolutely take their feedback into account but never follow
| the crowd for the sake of following the crowd.
| com2kid wrote:
| I did this to learn JS and React Native and it let me get
| started quickly, but wow was my code horrible. It was a good
| year before I stopped doing _really_ stupid things in JS,
| because I only ever had learned enough JS to "Get Things
| Done".
|
| This was in stark contrast to how I learned Java and C#, I deep
| dived into the internals of the languages and their runtimes
| (and at one point even worked on a version of the .NET CLR!),
| and all the code I wrote was in a mindset where I was cognizant
| of exactly what the runtime was doing to my code, how memory
| layout looked, how the GC works, and so on and so forth.
|
| I would've spent a year being 100% more productive if I'd spent
| just another week or two learning JS properly.
| 63 wrote:
| The trouble I've found with JIT learning and project driven
| learning is that it doesn't cover things I don't know I don't
| know. Often, there's more than one way to solve a problem so
| I'll solve it with what I already know how to do, meanwhile
| there's actually a simpler and more efficient solution that I
| would know if I'd used traditional learning resources ahead of
| time.
| nickjj wrote:
| Yep, this topic is covered in the blog post, search the post
| for "Expectations of Question Driven Development".
|
| The TL;DR is until you write a lot of code you'll have no
| idea what you're doing so it's fully expected you'll be
| writing, refactoring and deleting code as you go. It's only
| after you've taken so much action that you discover the more
| simple and efficient solutions.
|
| Front loading all the reading and research isn't going to
| help you get there sooner. IMO the best time to read a book
| or take a course on a subject is months after you've built
| something real, because then you can apply and understand all
| of the efficient solutions and end up with a bunch of
| takeaways to improve what you've done. Things that might take
| you 1-2 days to apply after you've read the book. This is
| also covered near the end of the blog post btw.
| netfortius wrote:
| Foreign language learning doesn't work this way.
| siliconc0w wrote:
| Diversity of learning also helps for me, if you're 'thrashing' on
| a problem without making progress, take a break to focus on
| something else - even another skill entirely you're learning in
| parallel like cooking, writing, or something physical. It's
| almost like background processing - you need to load up the
| context and let your brain chew on the problem a bit and when you
| return to the problem a solution will usually present itself.
| zuhayeer wrote:
| "With software development, though, mistakes are free! If we make
| a mistake, we can tab back to our editor, change the code, and
| try again. We even have helpful error messages that can
| (sometimes) point us in the right direction. This is an
| incredible luxury, and not one that we take advantage of enough."
|
| This is definitely very underrated and partly why I think
| computer science education is still sort of broken in some
| universities. Trial and error should be embraced as a a part of
| the process of building things. But instead, many curriculums in
| universities use exams to test your knowledge without any sort of
| debugger or console. You just have to go off of what you know,
| getting things as close to correct as you can in the first pass.
|
| All evaluations in CS should surround some type of project based
| work, it's a huge luxury other fields don't have. Students
| studying architecture or mechanical engineering, for example,
| simply can't build a functioning bridge as a test due to the cost
| of raw materials and how fatal an error may be (that would be
| really cool though). It's an advantage that we literally can
| build the bridge equivalent as a project in the CS world.
| id_ris wrote:
| One idea I've been using recently is to start writing unit tests
| around a piece of code or functionality as I'm trying to use it.
| That technique narrows the scope to a single thing, and I'm
| forced to be explicit about what I expect. That and reading the
| source code are my gotos.
| the_arun wrote:
| I think learning is a personal thing. It will definitely differ
| from person to person based on their passion.
|
| Off topic - I like the template/theme used in this site.
| Initially thought it could be like Hugo or Jekyll theme, then
| couldn't find more details. After some time using it felt this is
| custom made site with all animations and all.
| emsign wrote:
| Your site freezes my browser (Vivaldi). Just wanna let you know.
___________________________________________________________________
(page generated 2021-07-19 23:00 UTC)