[HN Gopher] How to Learn Complex Things Quickly: A Guide
___________________________________________________________________
How to Learn Complex Things Quickly: A Guide
Author : fmccaffrey
Score : 213 points
Date : 2021-04-08 13:56 UTC (9 hours ago)
(HTM) web link (product.hubspot.com)
(TXT) w3m dump (product.hubspot.com)
| asimjalis wrote:
| 1/ Try to solve a real problem with it. 2/ Try to teach someone
| what you learned in 1.
| apples_oranges wrote:
| This reminds me of a discussion about NFTs recently. I caught
| myself having an opinion without really knowing how they work. So
| I googled it and only found vague descriptions. Then I looked for
| an actual ETH blockchain contract that implements NFTs on Github
| [1], read it, and it was all very simple and clear. (So for me it
| was "How to Learn complex Things Quickly by realizing they are
| not that complex at all.")
|
| So in some cases I'd put "Read the Source Code" at the top.
|
| Code is not quite mathematical notation, but it is a concise way
| to express something..
|
| [1] I read this one:
| https://github.com/larvalabs/cryptopunks/blob/master/contrac...
| okprod wrote:
| _So in some cases I 'd put "Read the Source Code" at the top._
|
| Only if source is available
| lbotos wrote:
| I work as a support engineer and I often say "sufficiently
| advanced technology is indistinguishable from magic. My job is
| to explain magic." I had this same realization as you a few
| months ago when I was learning about DeFi and Eth proof of
| stake.
| eindiran wrote:
| The ERC-721 standard is also quite clear and fairly consise:
|
| https://eips.ethereum.org/EIPS/eip-721
|
| Cryptopunks was used as the jumping-off point for defining what
| an NFT standard needed to do.
| itsokimbatman wrote:
| "How to Learn complex Things Quickly by realizing they are not
| that complex at all."
|
| This is such a good observation. When I was first getting into
| my field, I looked around at the smart senior people around me
| and thought there was no way I could ever do what they did.
| Total case of imposter syndrome.
|
| Things like compilers, operating systems, etc. all seemed like
| magic, and I thought I was too dumb to do that kind of stuff.
|
| But once I started working, I didn't really have a choice... it
| was either learn or get fired. And digging down into the code
| made me realize just how... simple? ... some things are. Being
| able to pull back the curtain and realize there's no magic
| there. Want to talk to this piece of hardware? Just write this
| bit pattern to this particular address, then put your data over
| here, and then send it this command and it works.
|
| Not to say I immediately figured everything I read out.
| Sometimes it took me hours or days to work through something,
| especially if it was heavily templated C++ code.
|
| One of the things that really surprised me was looking into
| build systems for large projects. When I thought about how I'd
| do it, I could only imagine a disgusting, hacky series of
| scripts and code generators and things that any sensible
| developer would scoff at. But when I actually looked at how
| some projects are put together... they're a disgusting, hacky
| series of scripts and code generators.
|
| Learning that there's nothing magical about any of this was
| life changing. I still deal with imposter syndrome, but I feel
| much more confident that I can learn if I just make myself dive
| in, even if it seems scary at first.
| iagovar wrote:
| I hope to get there some day. I'm learning to code currently
| (until now, I was only capable of scripting, which is code,
| but you know what I mean) and I feel like there's just
| massive knowledge out there just to make simple things.
|
| Managing systems and environments make my head spin very
| fast. I try to keep it simple but now im peaking into the
| node/react ecosystem and I feel all over the place.
| depressedpanda wrote:
| > I try to keep it simple but now im peaking into the
| node/react ecosystem and I feel all over the place.
|
| If you want to keep things simple you should probably stay
| away from modern frontend web dev.
|
| Or, if you must do web, start with vanilla HTML, CSS and
| ES2015+. A solid understanding of the basics will always be
| valuable, and you can always build upon that knowledge when
| you reach the pain points that node, webpack, React etc
| help you solve.
| Jgrubb wrote:
| I'll get blown up for this but you're not all over the
| place, the node ecosystem is.
| the_only_law wrote:
| I've gone through the demystification phase a number of
| times. Unfortunately it's always very surface level. There's
| been a ton of things I've been trying to read about and learn
| about the past couple years. I could probably give a pretty
| decent, albeit rough description of most of them and how they
| work, but I could not implement them myself from scratch or
| anything.
|
| And I still look up at some people and wonder how the hell I
| could ever get to that level. People who seem both wide and
| deep in knowledge. Even people who cross outside different
| domains and seem well versed across all sorts of fields. I
| recall being among some reverse engineers quoting seemingly
| from memory undocumented behavior of random Windows API
| calls.
| bostonsre wrote:
| At least for me, reading is not enough. It gives some good
| context, but actually using that knowledge to accomplish
| tasks helps to solidify that knowledge. Viewing my
| knowledge as a network of interconnected nodes also helps
| me reason about it. Reading a key/value dictionary from
| start to finish doesn't leave enough interconnected nodes
| for that information to persist long. Knowledge seems to
| solidify when it is connected and linked to other bits of
| knowledge but islands of knowledge seem hard to retain.
| E.g. Those seemingly random windows api calls are easier to
| remember when you know of their Linux equivalent, in what
| cases you call those methods, what other methods call that
| method, what methods that method itself calls, what
| happened last time you called those methods, etc. I doubt
| they remembered them because they read the source code once
| and have a photographic memory.
| nneonneo wrote:
| Or, having been there, maybe they remembered them because
| they were interesting/weird tidbits that caused them to
| have to debug something for hours. Or perhaps they ran
| into those weird things last week. (I will never forget,
| for example, that certain glibc functions such as
| system() use movaps to copy data from the stack - because
| it'll crash the program when you call them from an
| unaligned stack ROP...)
| shoto_io wrote:
| I think for most people, learning is iterative. You need to
| peel off the complexity layer by layer. You are lucky enough to
| understand what a blockchain is. That's an unknown concept for
| many who want to understand what an NFT is. I guess most people
| (including me) will have a hard time understanding the link
| you've posted.
| atoav wrote:
| I think very often the most crucial information is not given
| when teaching people complex topics:
|
| - Why is this important? What problem does it really solve?
|
| - Why this solution and not another one?
|
| - What do I really need and use this for in practise?
|
| To realize it is not that complex at all you have to be able to
| sort it into a box first. Many teachers may take a big effort
| to break the complexity down into small pieces, but if you
| don't know where the whole thing fits this can break the whole
| teaching effort.
|
| I will never forget when I realized my (really bad) maths
| teacher managed to not tell us the perfectly good and
| understandable reason why integrals are a cool thing that solve
| real problems for a year of needing to deal with them. She
| really broke down the steps etc, but totally forgot to tell us
| what the thing was actually for, and why the stuff we already
| learned couldn't be used to solve certain problems.
| [deleted]
| th0ma5 wrote:
| If you didn't get the sense that they are just a glorified
| bookmark list then it wasn't clear enough.
| astrange wrote:
| The people who named them don't seem to realize they are not
| "non-fungible" since you can start another chain. And of
| course the NFT of a real thing is not the real thing, it's a
| URL to a picture of the thing, so they don't necessarily have
| the same owner.
| th0ma5 wrote:
| If you used private key encryption on both sides you could
| securely transfer data between two parties, and prove that
| you did so in a way that is very hard to dispute. But like
| Snowden says, it is still unencrypted going in and coming
| out at the endpoints. It is very hard to watch my creative
| friends wish that digital data behaved like real world
| items.
| jimpudar wrote:
| Also related - don't read random tutorials on "how to do X", go
| and find the official documentation for X and RTFM. In my
| experience this is the easiest and most direct way to learn any
| new technology.
| evrydayhustling wrote:
| This! There is very little selective pressure reducing the
| quantity or visibility of bad intros/tutorials. But for
| successful projects, the community puts a lot of pressure on
| the improvement and accuracy of core documentation. Truly
| complementary tutorials often ended up getting linked from or
| incorporated into primary project docs/pages -- so it is
| safer to explore from there than a Google search.
| idolaspecus wrote:
| And it's much, much rarer but equally as important corollary:
| UTFM (Use TFM). UTFM means: when you're designing a system,
| adhere your design so f**ing tightly to standard usage.
| RTFM/UTFM with standard tooling gets you so, so far to
| building high-quality software.
|
| Edit: I actually just made up (as far as I know) UTFM, but I
| _really_ wish it were a thing.
| pm90 wrote:
| I recently found the need to teach myself Java. While the
| Java Docs and official Java tutorial seem to be decent,
| especially once you know what you're doing and want to dig
| deeper, the "Baeldung articles" have been really useful as
| starting points as a survey of options available. Since this
| seemed like a pretty random website, I've been cautious and
| cross referencing everything I read. But I have to admit, it
| was pretty damn useful.
|
| So unofficial tutorials do have their place in introducing
| design patterns or listing trade offs between different
| approaches. But I do agree the source of truth should still
| be the official docs.
| the_only_law wrote:
| I've had the opposite experience. I've attempted to read a
| number of specs, and by the way I'm completely unable to
| parse them, you'd assume I was illiterate. On the other hand,
| I've found good, technical articles detailing how the same
| things worked and have found them much more digestible.
| jimpudar wrote:
| If you're competent enough to judge the technical article's
| credibility, this can be a good supplement to the official
| docs. I see junior developers running into this problem
| more often because they don't know how to tell the
| difference between a quality writeup and a garbage tutorial
| written by somebody trying to pad their blog.
|
| There are definitely cases where the official docs (or
| RFCs) are practically incomprehensible to a newcomer, but I
| usually will try and come back to them quickly after
| getting a foothold using a blog post or YouTube video.
|
| I find that even with the best technical writeups, there
| are often things applicable to MY use case that may not
| have been relevant to the author. The official docs (or
| sometimes the source) is the best place to find out about
| those.
| JJMcJ wrote:
| Sometimes the official docs are just right. Django is good,
| for example. I had to do small Ubuntu sysadmin task
| recently, the tutorials I found were incomprehensible. The
| official docs were crystal clear.
|
| But we've all seen the reverse, as well, and a combination
| of SO, YouTube, Reddit, and random tutorials is the only
| way to figure it out. Especially when you encounter the
| "This describes version 3.1, and everything in 4.5 is
| completely different, good luck" official docs.
| bigwavedave wrote:
| For me personally, the answer is a combination of the two.
| Having the docs open side-by-side with a good technical
| write-up usually helps me understand a lot faster and
| better than either resource does on its own.
| cratermoon wrote:
| > go and find the official documentation for X and RTFM.
|
| Yes and no. The official documentation can be obtuse and bad
| for new learners. (I'm looking at you, gradle[1]). Ideally,
| the official documentation includes tutorials, but also three
| other forms: 1) how-to guides showing the steps for
| accomplishing a common goal. Think of them as extended FAQ
| answers. 2) simple reference docs. Your typical api-centered
| doc, or man page cli flag list. Answers the question of "what
| was the function/class/flag to do that?" Assumes you already
| know how. 3) explanations, the discursive articles about how
| and why. A lot of people can get by with never reading these,
| but once in a while they can clear up some problem you're
| having. The tutorials, which should exist, would be short
| guides for learning by doing. They aren't how-to guides,
| because they don't assume you know anything yet. They are
| often the best entry points for picking up something entirely
| new.
|
| [1] https://www.bruceeckel.com/2021/01/02/the-problem-with-
| gradl... and https://melix.github.io/blog/2021/01/the-
| problem-with-gradle...
| treyfitty wrote:
| Eh, I have the opposite experience. When I was a beginner in
| a any language, RTFM didn't work for me because:
|
| A) Reading a manual requires some requisite knowledge due to
| esoteric references.
|
| B) RTFM is a skill in and of itself.
|
| C) Manuals rarely mention corner cases or "gotchas" which can
| cause confusion to a beginner.
|
| D) Manuals never comment on best practices, which tutorials
| do.
| elevaet wrote:
| The F'ing M is often an afterthought, and sometimes you
| need to dig into the source code to understand how the
| thing works, or at least to find the right handles to
| grasp.
|
| Not necessarily the right approach for beginners, but I've
| wasted a lot of time trying to find the thing in the
| documentation, when I should have just lifted the hood in
| the first place.
| iamcreasy wrote:
| I think code is equivalent to a math notation. A mathematical
| notation is unclear in the first read as it tried to cover all
| edge cases, while being rigorous at the same time. A piece of
| code that implements the math formula is somewhat similar in a
| sense it's trying to implement a core idea while also covering
| the edge cases. Both needs training, patience and some
| background knowledge to parse accurately.
| JJMcJ wrote:
| More times than I care to admit, I've been totally confused,
| and then decide to actually watch that 14 minute video on
| YouTube, and read the entire doc page, and the mystery
| disappears.
|
| RTFM: words to live by.
| shishy wrote:
| Right, often the actual thing isn't so complex but sifting
| through all the abstractions people created over it is.
| ineedasername wrote:
| This entire writeup describes the process of learning complex
| things to only a shallow or, at best, medium level of
| understanding. Following these guidelines and then believing you
| have a solid understanding of a complex thing is a near-perfect
| recipe for the Dunning-Kruger effect.
| AJRF wrote:
| What in gods name is hubspot and how do I keep ending up on it's
| website. It sounds like a CRM but they have a side hustle of
| producing blogposts about every topic under the sun?
|
| Edit: I just searched "hubspot blogs about everything" and had a
| full page of results of blogs about blogging from Hubspot. The
| entire page of results!
| bognition wrote:
| They're building a CRM for the mid market. Think salesforce but
| for small/midsized businesses.
|
| A few years back they were only focused on marketing automation
| and driving organic search traffic to your blog plays a big
| role in that (Inbound Marketing). As such they've produced a
| lot of content to drive traffic to their blog.
| bibinou wrote:
| Their shtick is Inbound Marketing, making clients come to you.
|
| Spamming blogposts on HN works really well for that. Works even
| better if it's good blogposts.
|
| edit: Dan Lyons (Fake Steve Jobs) wrote a book on his time
| there.
| andrei_says_ wrote:
| I recommend "Disrupted" by Dan Lyons - about his time at
| Hubspot, about the unicorn phenomenon and the cultish culture
| of tech startups.
| [deleted]
| 627467 wrote:
| I read this as "just do it" (sue me nike). Learn by doing
| something, what you are able to do will increment organically so
| start somewhere you can start doing.
| m3kw9 wrote:
| When will I get a guide on how to learn complex ways to learn
| things quickly?
| [deleted]
| ergest wrote:
| The guide is ok, but I will say that nothing works better than
| having a problem you're trying to solve. The rest comes
| naturally. I taught myself data mining (now called machine
| learning or data science) in a matter of months because I was
| trying to build a lead scoring model.
| hyperpallium2 wrote:
| The opposite of "Deep Work". Great for getting stuff done; but a
| poor substitute for understanding. Good for practitioners not
| researchers.
|
| Because a working but incorrect mental model is a terrifyingly
| insidious, almost impenetrable barrier to actual understanding.
| ineedasername wrote:
| Yes, this is, at best, a recipe for understanding how to
| properly _use_ a complex tool (say LTSM networks) but by no
| means a mechanism by which you would gain actual understanding.
| And if you mistake the two, you run into the Dunning-Kruger
| effect, believe you know more than you do, tweak things in ways
| you don 't completely understand, and end up with utter crap
| that appears to be gold.
| swader999 wrote:
| Nobody is saying this so I'll put it out. A good way to learn
| anything is to teach it to someone else.
| brujo wrote:
| I will read it for sure but seeing Hubspot as a source sparks
| serious doubts about the value of this article XD
| runningmike wrote:
| Nice, but imho complexity is never ever a technical problem.
| Solving complexity is imho more effective than learning to deal
| with it. So learning system thinking will always help. Some reads
| https://www.bm-support.org/problem-solving-methods/ or try to use
| principles before building software. Like
| https://nocomplexity.com/documents/0complexity/abstract.html
| u385639 wrote:
| While the advice is good advice overall, it stumbles on its own
| hindsight.
|
| > Break whatever you're trying to learn down into use cases.
| Start with bite sized chunks that take a few minutes and build on
| them incrementally. "Learning python" is too broad. Installing
| python, printing hello world, installing and using a dependency,
| reading from a file, etc. are more well-defined, and it's easier
| to know when you're done, therefore helping to reinforce
| progress.
|
| Yes "learning python" is too broad, but the subtlety here is that
| it's usually actually "learn my first programming language", in
| which case it's unlikely you would understand how to break
| anything up into any steps. If "learning python" is _not_ your
| first language then the advice is just obvious.
|
| The truth is that the only advice that matters is "don't give up"
| and "have the courage to learn however you want" because there is
| no such thing as "teaching".
| pessimizer wrote:
| > it's unlikely you would understand how to break anything up
| into any steps.
|
| Sounds like a job for a teacher.
| PeterisP wrote:
| Or a textbook writer.
|
| Seriously, if you need a decent breakdown of "Learning X"
| into steps, then it's useful to look at the table of contents
| of a related textbook even if you'd be learning from other
| sources (experimentation, documentation, whatever) because
| the split and order of topics will be at least somewhat
| reasonable.
| tsejerome97 wrote:
| I totally agree with this. This approach can work only if you
| have the big picture. It is a lot easier for a web development
| background person to learn app development as the person knows
| it is still a "frontend". However, it would be really really
| hard for me to learn Astrophysics and Quantum Physics. (would
| appreciate a lot if anyone can offer any advice:D)
| DickingAround wrote:
| Not that I'm good at this yet, but I've found one solid way
| to do it: Read a textbook on it cover to cover. Don't do any
| of the problems, that'll like 10x the time. But the textbook
| will have an overview of the entire space and then as you
| have questions you'll know how to dive into them. It's helped
| me get into technologies that are wholly and totally
| different from what I work in and studied.
| billti wrote:
| Totally agree with this. A lot of details don't make sense
| until you understand the big picture. Skim as much as you
| can, then (re)read that which helps get the next level of
| understanding, ... and repeat.
|
| It's time consuming, and can feel frustrating when you're
| reading stuff you don't understand, but you learn more in
| the long run (and understand how it fits into the bigger
| picture better).
| atsushin wrote:
| I've often found that "skipping the details" and learning only as
| much as I -need- truly is the most useful thing you can do to
| learn something new.
| dazc wrote:
| Yes, me too, making mistakes and finding solutions is also a
| great way of learning although it doesn't feel like it at the
| time.
| chrisbaldauf wrote:
| Glad it resonated! You have to choose where you invest your
| learning time or it is too easy to get overwhelmed and lost.
| asimjalis wrote:
| How did HN figure out you were the author and render your
| name in green?
| thelean12 wrote:
| Green just means it's a new account.
| asdff wrote:
| This strategy becomes a mess when you finally learn the
| crippling problem was due to one of these details you've
| skipped. It's important to read all the documentation at least
| once if you can. Sometimes a lightbulb might go off that saves
| you a lot of time.
| thelean12 wrote:
| This completely falls apart at big tech. If you read all the
| documentation once for all the components you're working on,
| you'd be out of commission for months just for your first
| project. Actually understanding what you're reading takes a
| career.
|
| Learning only what you need to is essential in this
| environment.
| ternaryoperator wrote:
| My experience is just the opposite: there is far too little
| documentation of most components and I have to scramble to
| places like SO and other forums to get the basic info I
| need. In my experience, it's principally the big enterprise
| packages that suffer from the problem you describe.
|
| But, of course, YMMV.
___________________________________________________________________
(page generated 2021-04-08 23:01 UTC)