Ask HN: Generalists, when do you say "I know enough" about any particular topic?

I like to find out what there is to know in an area--get more context than you need. Then I figure out what I need to know now for the task at hand. Always look for alternatives rather than going with the first solution. If you only know one way to do something, how do you know it's the best or even good enough after you've covered all the details.

1. Imitate. Find a way to boil down what I'm looking at to "monkey see, monkey do". Kindergarten songs and projects. Tracing the letters. Making the same poses as the athletes.

2. Isolate. Look for the drills that simplify the goal to particular success benchmarks. E.g. "drawing" -> "draw the outline without looking at your paper(blind contour)". Turn the isolation into a primary warmup for the activity.

3. Improvise. Now it's time to actually start making new things and integrating the concepts, using the structure from the previous practice. Improvisation can be practiced with games and challenges that are loosely structured(see: actual short-form improv games like "Five Things")

The learning in tech always tends to have either a "hardware up" approach(computer engineering, operating systems, low-level protocols) or a "abstraction down" approach(problem domain languages and application interfaces). The parts in between get swept up and rearranged with great frequency; they are the implementation detail, and may have some incidental automation, but usually they just reflect Conway's law in some form - they become standard because the situation asks for a standard, and then politicking proceeds to take over as career-minded individuals jump on board and try to steer the technical conversation their way, to their standard, where they will receive credit. We also keep coming up with new things to automate, motivating new problem domain abstractions.

Thus: you stand to gain a ton by closely examining the roots of the systems you work with, just sitting there with a pen and a notebook doing the earliest imitation processes on their code and documentation. Proceeding to the more isolated parts of building an actual project with the system is often superfluous, if you've encountered the main concepts before.

You've misunderstood, I think: if I have something I want to experiment with or build, then I can learn what I need. What I have such enormous trouble doing that I'm nearly incapable of it, is going "I should learn this so I can do something, to be determined later, with it..." and then learning. Making up projects for the sake of learning, when I don't really care about the ends, also doesn't work.

I need the goal first, then I can learn what I need.

I do also learn things just because I want to and for no real purpose, but have never been any good at directing that impulse.

Studied it at uni…which is why I know people are often confidently incorrect about it.

Thankfully don’t deal with that mess professionally now

This is great advice!

A lot of what I read here so far is either “never” or “when I get the job done.” The first answer risks burnout or imposter syndrome, while the second risks failing to grasp first principles and how to do things efficiently, salably, sustainably.

Your answer helps avoid either problem.