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

I concur with everything here but I would say find a solution to your problem plus a little bit more. In particular, try to find out about where the boundaries of the problem are such that this solution wouldn’t work anymore. Maybe it stops working at a certain scale, or with less behaved input, or if you need to support Chinese characters. This helps me really understand the solution, and not feel like I just have a book of incantations.

> I stop when I find a solution to the problem

That.

I’ve embraced that I cannot direct which topic my self-directed learning will take up and sustain (almost none of which ends up going toward tech stuff, aside from a span of some years in my teens and early 20s—and all of that was motivated by wanting to accomplish specific things with computers) and rely on assignments to motivate me for career-relevant learning.

I’ll learn whatever it takes to get the job done. Then stop, because I don’t actually care about the tech per se, most of the time, and trying to force myself to learn “just because” does nothing but make me miserable and waste time.

This isn’t even “how I approach learning as a generalist”, it’s how I became a generalist.

My interest in continuing to fiddle with stuff after the job’s done is basically zero.

My experience has been that it takes amazingly little effort to be above-median among practitioners at a lot of things. How many React developers have spent one entire hour reading through the core logic of React itself? How many people working with LLMs have read the Attention Is All You Need paper? How many people read about the disk storage layout of a database they’ve been told to use? It’s way less than half. It takes so very little to stand out.

I follow the motto: "Don't spread yourself thin."

What I try to do is get into the core of whatever product I work on, as close to the beginning of the product's creation.

Then, I implement "good enough" solutions that work as a bridge until the team can grow to hire experts.

For example: At a startup I worked with another engineer on a desktop client. I focused on working mostly on the business logic, and muddled through the UI. We brought in a UI expert to polish the UI. Later, when we added a driver, we brought in a driver expert to implement the driver, and I worked on how it integrated into the product.

On that product I also became "good enough" at Mac programming because it was a cross-platform product, and I focused on our cross-platform logic abstracted Mac and Windows. We later brought in Mac experts who filled in the pieces that required more extensive Mac experience.

You learn just enough to get your problems solved appropriately. What's approriate is the thing you have to judge specifically within your problem space.

If you're working on life-sustaining / life-saving problem space, appropriate better be very robust. If you're hacking on a hobby project, appropriate is whatever you feel like.

Personally I learn something new (almost) every day. Some of it is related to my work, some of it I learn just because I find it interesting. That's how I've grown to be a generalist. I didn't strive to be one, it just happened due to life long learning.

When it is possible, when you can afford it and when such an expert existsand you know of them and can contact them.

Interesting factoid is that for many fields, such experts do not really exist. Unfortunately we do not get hired as researchers at this particular rabbit hole.

Tax and accounting is not one of those things.