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 would say never stop learning but also never stop practicing. I flip back and forth between study and coding (or music, or any other practice) to get some hands on in using what I just learned. Often, I stop in the middle of "real work" to learn something, or stop reading in order to try something.
For workflow stuff, I more or less do the generalized version of the xkcd Worth the Time (0). There's always initial friction bringing something new into a workflow, both from a learning and practice standpoint, which I treat as an expected upfront cost. But pretty much once I start spending more time (actively) learning about a tool than I get back in saved time, that's about the end for that workflow update. I can always revisit it if I hear about a new feature of the tool, and of course I'm passively picking up stuff as I use it.
tl;dr: Fundamentals, then just enough to get me through that next step.
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.
Optimize for engagement. Are you engaged with the topic? Keep going. Are you bored/way over your head? Try to find something else in the field that's more engaging.
To be honest, I find that this idea is really underappreciated.
I use a concept called timeboxing combined with deep work. If you wanna learn something, estimate, how much time you gonna need, how much time you really have a day and then split the estimation into timeboxes of at least 1h, better 2h or even more.
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 ;)
I look for things that are immediately applicable to me.
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.
Everyone learns a new thing and it seems magical. We tend to over-apply it while we're finding its limits. So I try to do that intentionally, up-front, when there's nothing at stake.
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 totally agree with this too! Sometimes its nice to have a project that's meant to go nowhere, but it teaches you a ton and you get a lot of that yak shaving out of the way.
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 immediately play with it and slowly build up a prototype publicly so I get input from other engineers. I think a short feedback cycle on anything complex is key, so you don't over-invest.
0. Is it interesting to me and has useful applications? As deep as possible while still gaining new applicable knowledge.
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.
I'm a depth-first learner. I prefer to have the time and focus to learn as much as possible about a new area, as deeply as possible, and in one "chunk".
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.
I start with wikipedia or the intro to the documentation. Then I read deeper on whatever seems interesting until I think I know enough to be productive.
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.
Minsky labelled our minds "difference engines". This means,
we work best with a goal. The moment some sort of goal is
set, the mind keeps diffing goal and your current position
continuously. Given this framework, I always tend to have
a higher goal, some result I hope to see. With such context,
then it is simply a matter of asking "is it working now? am I there yet?".
If it is not, learn more. If it is, then I sort of know enough.
And if I have a stronger urge, I may go on a curiosity-ride
for as long as (economically) possible :)
I will read the full surface-level of the docs just so I understand all the nouns and verbs. It's okay if I don't understand something at this stage - it's all about learning the existence of unknown unknowns. Just need to get them to known unknowns.
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.
If I just start learning, I don't stop until it's too late and I'm probably burnt out on the topic. If I have a goal but haven't started working on it, I study what I think I need to accomplish that goal until I think I understand or realize it's not what I needed in the first place. If I need to know something to complete a concrete task, I learn the very least I possibly can to do what I need to do, and return to learning if I fail, until I succeed.
Breadth first thinker here: Understand the jokes, these are the edges and shape of its applicability, and mnemonics for its concepts. Get very good depth first in a few other foundation areas so that you know what discipline and rigor of real depth looks like, figure out how to identify people who also have depth in something, and then use their minds to scale yours.
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."
50 comments
[ 3.3 ms ] story [ 140 ms ] thread(0) https://xkcd.com/1205
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.
To be honest, I find that this idea is really underappreciated.
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 ;)
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 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 :)
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.
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.
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.
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.
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.
This requires that you have a real practical job to do in the first place.
Rinse and repeat with more and more difficult tasks.
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."
So all of the way, I guess.
I aim for the center, and I know I'm done when there's nowhere left to go.