Ask HN: How deep do you go?
When you’re learning about a new topic or technology that you want to incorporate into your workflow, how do you know how to scope the learning and when to stop?
I plan to fail. As spectacularly as possible. Then I have to figure my way out of it - time to finally read those docs in detail!
I usually try to do a (toy) project that seems ridiculous. I try to misapply the tech if possible to some domain it's unfit for. Finishing the project isn't important. I just need to fail a lot and learn.
Once I stop failing so often or once the failures are smaller, that means I'm familiar enough to not embarrass myself too much.
I get caught up in the most ridiculous yak shaving and never make any real progress.... but always have a blast.
By the end you might have so little to show, but I found writing down what I learned a great way to "mark" the project with a healthy milestone :)
I have absolute respect for depth of skills, and arguably even a rare appreciation for them, but with the caveat that there are diminishing returns and limited scalability on them, and this is the problem I typically index on solving. That is to say, I often tell people deadpan (to the point of it almost being my catchphrase), "I don't know very much, but I have opinions about everything."
1. Is it really interesting to me but no, or few, applications? Then I won't stop until I hit a wall. Then I rotate out topics to avoid frustration, potentially abandoning some paths if they're just too much for self-study with no application.
2. Is it useful to me (professionally or personally) but less interesting? Until I hit a point where there is little to gain from deeper study.
There are usually a lot of abstraction layers, all of them leaky to differing degrees. I like to have a broad picture of the big abstraction layers pretty much all the way down, and then details proportional to how much they manage to bubble up through the abstraction layers.
For example if I was trying to teach someone how to program in a reasonably high level language (rust, python, etc). I'd (eventually) want them to know that assembly and machine code exists - if we're talking about python also that bytecode exists, but I definitely don't care if they know how to read/write it because there's a strong abstraction layer between the language and the concrete machine. On the other hand I'd (eventually) want them to know not just that file handles exist, but that they're integers allocated by the OS and how syscalls work with them, because the abstractions on top of file handles are quite leaky, and it's often useful to understand what they are when looking at various forms of debug output (especially strace output).
And this is a luxury. If you're learning a technology that you need to use immediately, skip out learning on things deeper in the stack until you have free time and are already productive. Even if you're not in a hurry, generally learning lower level things is motivated by wanting to know how the higher level things work.
In the first instance, I try and build a simple but complete model to ensure that there aren't any gotchas. For example, I am looking at Hashicorp Vault. It does a number of things that will be useful and which all need to happen. I will spend some time, therefore, getting one example of each of those working. This will prove the docs are good, there aren't any weird limitations and it is something I can work with.
If, on the other hand, I am only evaluating something, I can very easily drop it just because of some poorly maintained docs or an error in the first 5 minutes after following the installation instructions.
Like another poster, I then try and keep the breadth as narrow as possible so I am not learning things I don't need, but using my experience to spot things that might need some more careful learning. For example, I quickly spotted that K8S default networking was very open so I invested more time working out options for having it more locked down.
Once it stops crashing, i try to slowly refactor it for my use case. Crucial part is not taking too big chunks that you lose focus and not getting stuck on irrelevant things. It can get messy but as long as you have loaded it up in your work memory, it should be ok. Later i'll rewrite everything once i understand the domain better.
Obviously sometimes that isn't well-supported by my immediate needs. In those cases I tend to be incremental - I work on the problem that I need to solve until I run into a roadblock. I solve that roadblock and continue until the next one. This approach makes it more difficult to estimate "time to completion", but it's proven to be most efficient for me so far.
How broadly and deeply I go depends on how well I know a topic already. The less I know, the broader and deeper I go, in a not-particularly-predictable way, until I feel like I just went past the point where I could have taken action.
At that point, I have a glom of unconnected data and factoids. Then I do something (code, cut, brew, cook, wheel, weld, bend, hammer, whatever), with every expectation of failure and every hope for at least a step forward.
Then something doesn’t pan out and the failure crystallizes knowledge.
Until going hands on, I had no context to appreciate what part of breadth or depth was practical, what was theoretical, and/or what was background/historical.
Suddenly confronted by practical problems, I backtrack up and in, sort of, to find paths that I can evaluate as to utility, whether to the immediate task or to a firm theoretical foundation.
Lather, rinse, repeat, until things start to take shape and I start to understand the subject.
Then I start using it. If I get stuck, I find more specific information until I'm not stuck. Rinse and repeat.
So in short, I read the smallest amount of info possible to start and then let my practical experience guide me after that.
Usually, I know in advance what I want to build with the new technology and what quality level my customer needs. I'm always super impatient to try new knowledge out in practice. So I'll learn for a day, then try it out in the evening. And then I only go back to learning as long as the results are still too bad to solve my problem.
To be honest, I find that this idea is really underappreciated.
It helps you understand the shape of what is possible, debugging becomes far easier and sooner or later you will probably have to fix it anyway, or live with horrible inelegant workaround at your target level of abstraction.
I’ve never regretted going deeper; being able to keep going down all the way into the kernel is a superpower. But I’ve often regretted not going deeper earlier.
Focus on your work / task and if you finish early and are still interested, dig deeper. If not, stop as soon as you get where you want to.
Works pretty well, but Focus is the main point. No tiktok, youtube, twitter, smartphone or whatever ;)
As a general rule: there is no too much knowledge. The trick is just avoid dispersion, concentrating on something leaving something else aside. And there is no magic formula IME for that...
Once I have the outline of the possibility space I start to dig in on the topics that seem most relevant for my objective and try them out.
https://jondouglas.dev/five-to-thrive
Think of your progression as the following:
- I’m a little familiar
- I’m a bit more excited
- I’m seeing the big picture
- I’m understanding the main ideas & opinions
- I’m getting an idea of where the future is headed.
If it's something I want to learn to satisfy my curiosity (e.g., Golang, TCP/IP, architectural patterns, linux kernel, etc.) it takes me months and I usually stop after building a couple of projects and after reading a couple of reference books.
He said something along the lines of 'Most people are pattern matchers, they are good at applying known patterns to problems they face. However, the best people know when to pattern match, and, also, when to go deep and apply first principles thinking.'
He then cited Elon Musk as a great example of this.
A tangential example is to think about how Amazon Basics (household items) took over without any advertising (maybe shopping placement was privileged inside Amazon platforms though). It solved people's problems that were being dismissed as too basic to solve.
When I think about workflow adjustments, its usually one thing I'm looking for. If the solution has some other cool things about then, now I'm getting somewhat exposed to them too.
If its not immediately applicable, I'm not really prioritizing it.
I started brewing beer last year. Now I'm growing my own hops and grain. If that goes well, I'll be malting it and turning it into beer.
But generally, I only go as deep as I need for it to work. I only go deeper if there's a problem or a true interest.
For work/assigned learning, I go as deep as is either required or "seems" to be relevant to the task(s) as hand
This requires that you have a real practical job to do in the first place.
Rinse and repeat with more and more difficult tasks.
In general, I take an iterative approach: learn the basic fundamentals for basic situational awareness, and then learn enough to get going, and keep learning as I encounter roadblocks.
Sometimes, if I feel like doing a massive deep dive into a topic, I generally allow myself to do so.
I aim for the center, and I know I'm done when there's nowhere left to go.
So all of the way, I guess.
I recognize that I get a dopamine hit from learning new things and so tend to just keep digging in. That said, for a lot of things, there seems to be very roughly three levels of "understanding";
1) Surface level - this describes the basic principles of the thing, how it relates to other things, and how it influences or is influenced by other significant things.
2) Engineering level - this level then has the information needed to develop a new thing, or modify an existing thing, or counter or enhance a thing. Sort of the fundamentals of the thing's makeup and/or construction and lets you find or make new things of a similar type.
3) Foundation level - this level then is where the nature of the thing, how it fits into the overall understanding of things in the universe and usually the process by which it's nature has come to be understood. This level will have a set of tools and processes that have evolved from the general set of tools to evaluate the nature of these things more specifically.
So level #1 is pretty easy and when I'm not thinking I'm going to contribute new original work to the topic or technology is where I'll stop if I'm just trying to use what ever it is to get something else done.
Level #2 is where I end up most often because I'm curious and learning something to that level can often inform how applicable it will be in other efforts. So if a technology is generally useful to a wide variety of applications I'll get down to this level, if it is pretty specialized for one kind of application, I'm less likely to go into its engineering.
Level #3 I don't go as often. The calculus is what will I learn vs what else could I have learned in the same time. My basic education focused on physics, electrical engineering, computer science, and some chemistry with the math necessary to support that. When level #3 is pushing into fields that are adjacent to that base like geology, biology, and philosophy I find there is a bigger hit to go back and pick up more fundamentals and that can be time consuming. So I have to ask myself do I really want to know this topic at a fundamental level or not?
But all of that to say that I am not a good role model here, I often spent more time learning about something than my employer's would like. A common experience in my work career was an increasingly irritated/impatient manager that I had not gotten "anything" done, followed by surprise that I had solved problems they didn't even know they were going to have. You don't get credit for knowing more than you "need" to know to accomplish a task. (Well I would give credit for that to people who worked for me, but it was rare that someone I worked for to credit that).
So two answers;
In your job, stop when you know enough to make progress to please your task masters.
In your life, never stop learning new things.
https://subgenius.fandom.com/wiki/ShorDurPerSav
>In the Church of the SubGenius, SubGenii often worship Short Duration Personal Saviors (ShorDurPerSavs). ShorDurPerSavs offer all of the features and services of regular personal saviors, but are disposable. Thanks to their planned obsolescence, no SubGenius worships the same ShorDurPerSav for very long before switching to another one. The most common ShorDurPerSav is J. R. "Bob" Dobbs, followed by Connie Dobbs and then The Fightin' Jesus. Other common ShorDurPerSavs include Jehovah 1, Francis E. Dec, Eris Discordia, Adolf Hitler, Emperor Norton, The Bleeding Head of Arnold Palmer, Robert Anton Wilson, L. Ron Hubbard, Alien Sex Goddesses, Satan, the number 23, Barack Obama, and Cthulhu.
>[...]
http://www.subgenius.com/bigfist/goods/shordurpersavs/X0012_...
>From: Purple Kitty <pkitty@netcom.com>
>-= SHORT DURATION PERSONAL SAVIORS - A LESSON =-
>BEGINNER LEVEL - CLEARED FOR ALL BOBBIES - BEGINNER LEVEL - CLEARED FOR
>Shockingly, some Bobbies are still unclear as to what a Short Duration Personal Savior is. The concept of the Short Duration Personal Savior (or ShorDurPerSav, the proper Tibetian term) is a new one-- traditional religions tend to emphasize "unwavering servitude" over convenience. But is absolute devotion to one savior always best? Buddha is a wonderful role model for certain aspects of life, but when that po'bucker shoves you out of the way as he walks by, don't you wish that you worshipped George Foreman instead, if only for the next few minutes?
>Well, you can! The Church of the SubGenius heartily endorses the concept of disposable saviors, or ShorDurPerSavs. Choose your messiah to fit the situation. If peace and compassion are what you need right now, follow the teachings of Gandhi. Later, when you need to cut a business deal, emulate the wisdom of Sam Walton. When you need a witty remark on the spot, let Samuel Clemens into your heart to inspire you. And when you need Slack in your life, sell your soul to "Bob".
>"Bob" is the most frequently invoked of our infinitely varied Short Duration Personal Saviors, with good reason. He has Slack--he IS Slack. He symbolizes the "easy life", where one follows the Path of Least Resistance and gains Slack effortlessly. But no one is expected to worship "Bob" 24/7! If you're trying to get that PC to work, choosing "Bob" as your ShorDurPerSav will hinder you far more than helping you! "Bob" couldn't use a PC if he wanted to (though he sold more of them last year than IBM and Packard Bell put together)! Read through Stephen Levy's _Hackers_ and let the TMRC be your ShorDurPerSavs! There ARE no limits!
>[...]