How to Learn Complex Things Quickly: A Guide | Hacker News Reader

How to Learn Complex Things Quickly: A Guide

product.hubspot.com

267 pointsfmccaffrey61 comments

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...

"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.

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.

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.

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...)

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.

> 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.

I'll get blown up for this but you're not all over the place, the node ecosystem is.

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.

> 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...

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

> So in some cases I'd put "Read the Source Code" at the top.

"Read the source" is often seen as an aggressive or dismissive response, but sometimes it's pretty much the best way to figure out software.

Right, often the actual thing isn't so complex but sifting through all the abstractions people created over it is.

If you didn't get the sense that they are just a glorified bookmark list then it wasn't clear enough.

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.

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.

I think you can explain it pretty easily at least. A blockchain is a Google Docs spreadsheet. An NFT is an entry with the name of an item next to the name of an owner. Magic prevents other people from editing it, but you can just start another spreadsheet and put your name in there.

Plus if it's the NFT of a physical item then you can just steal the real thing.

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.

So in some cases I'd put "Read the Source Code" at the top.

Only if source is available

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".

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)

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.

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).

I am quite curious if you will study textbook when studying a programming language or a development framework :D

> it's unlikely you would understand how to break anything up into any steps.

Sounds like a job for a teacher.

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.

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!

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.

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.

I recommend “Disrupted” by Dan Lyons - about his time at Hubspot, about the unicorn phenomenon and the cultish culture of tech startups.

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.

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.

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.

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.

Glad it resonated! You have to choose where you invest your learning time or it is too easy to get overwhelmed and lost.

How did HN figure out you were the author and render your name in green?

Green just means it's a new account.

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.

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.

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.

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.

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

Nobody is saying this so I'll put it out. A good way to learn anything is to teach it to someone else.

1/ Try to solve a real problem with it. 2/ Try to teach someone what you learned in 1.

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.

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.

I will read it for sure but seeing Hubspot as a source sparks serious doubts about the value of this article XD

When will I get a guide on how to learn complex ways to learn things quickly?

Reply on news.ycombinator.com