I stop when I find a solution to the problem. Most of the time the learning happens along the way, not necessarily in the solution itself but all the things you try and iterate on your journey to the solution.
Everything changes in tech by the minute ... but also nothing changes. For web applications it has been HTML, CSS and JS for nearly 30 years. XMLHttpRequest/AJAX came out 25+ years ago. There have been many improvements along the way, like applying design patterns instead of cgi-bin directories with scripts that had a +x modifier on them in the file system. But the base technologies have not changed all that much. We still submit HTML form's with input fields to a back-end server that handles that data. We're still rendering HTML and using CSS to style it. Gone are custom UI toolkits like Flash or Java Applets. Maybe WASM is something to look into but it feels like its not mainstream to me.
If you don't want to get left behind, learn the basic building blocks at a deep level, they don't change much.
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.
That's funny, I often love learning for the sake of.. experimenting, building things. I just recognize that I cannot do it all and prioritize immediate needs first.
> That's funny, I often love learning for the sake of.. experimenting, building things. I just recognize that I cannot do it all and prioritize immediate needs first.
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.
I say, "you're going to need to pay a team of PhDs to work on this to maybe get a solution, eventually, or change your approach. Here's why: [evidence]"
I've never worked with or for anyone who wanted to hire the team of PhDs.
I go for "I can understand experts, but not add much to the conversation" as a benchmark for knowing enough to participate in discussions at work. Then I use that "I can solve my immediate problem" method going forward.
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 do a lot of repairs on electronics. I stop when I understand enough of the theory of operation to get things fixed. I've worked on everything from industrial control like 480 volt 3 phase SCR packs to Cesium beam atomic clocks.
If it was interesting, I'll dive in to learn more in case I encounter something similar in the future.
I never aspired to be a generalist, but I have come to realize my process has made me into one.
If I had to generalize how I work, I'd say it comes down to:
1. Identify the highest value thing I can work on that is feasible
2. Learn what I need to finish the work. Invest as little time/effort as possible into topics that have not proven to be timeless. Lindy's Law is your guide here.
3. when the solution is good enough, go back to 1.
Being a generalist doesn't mean you aren't an expert in anything. There are topics that I've identified as being so timeless and high value that I've more time and effort into them than others (making me a relative expert, I guess).
For me, it is more about targeting the goals at hand and learning just what I need than setting out to master the tools I like. Over time you will become an expert in the tools you trust.
You never know 'enough'. You just have broad interests and see how all things are more interlinked than any one specific branch of knowledge captures. So you naturally wander through a host of subjects rather than exclusively deepdive into a single specialization.
I don't understand the question. One does not simply decide to stop falling down the rabbit hole, you keep going until it stops or you get taken down a different path. Never in my life have I made an active decision to stop learning about any one thing. You learn whatever skill is required to deal with the problem at hand and go on keep learning until you need a new skill or just get distracted.
But also you're making an extremely bad mistake in your thinking here. Being a generalist does not preclude being a master. In fact, I've found that in today's market you must have specializations. Right now I'm selling myself as an electronics engineer and embedded C programmer. But my deepest expertice is C#, where I consider myself to be a fairly high level expert. My current job is writing react native with some EE on the side.
You're trying to actively spread yourself even thinner which is a huge error. Knowing almost nothing about everything is not useful today, we just use AI for that. You need some real, solid skills to work from. You also need to be able to be a specialist and do specialist work because you are not likely to find a good generalist role. There aren't many such roles and they're getting harder to find.
But all in all my answer is no. There is no point where you should stop learning any one thing. Follow your passions and what's interesting. Finding a subject you're interested in and spending a ton of time learning about it isn't a bad thing. That's how you figure out what you like and how you build real skills. You should follow particular subjects into mastery because a generalist without any specialization is not actually very useful unless you're a world class engineer.
It's clichéd, but genuinely follow whatever subjects make you happy and find a way to make that work for you.
If I run into a problem where I can't interpret the tax code myself, I'll schedule an hour appointment with a tax expert to get the answer to that specific question. If their answer sounds too good to be true, I'll schedule some appointments with other experts and take the most pessimistic answer. Ultimately, it's my responsibility that my taxes are correct, so I need to understand how they work.
I switched off of using tax software and do my taxes by hand, including rental income and stock sales. I'd estimate my tax return is 20-30 pages at this point.
If I ran my own company, I'd hand my taxes off to a tax expert at the point where filling out all of the forms represented such a significant investment in time that it detracted from my ability to run the company, but they would have to be significantly more complicated than anything the average person encounters. I would also hand them off to a separate firm if they reached the point where I needed credentials for the tax return to be valid - such as to assess the value of inventory.
It really doesn't take that much effort to learn how to do your own taxes, and the VITA program provides good free training in exchange for volunteering, which provides essential practice time anyway.
It's actually pretty simple. "Where I can't interpret the tax code myself" means "where my attempt to interpret the tax code leaves me with two or more possible interpretations."
The tax forms are very comprehensive. I go through each line of the 1040, following the instructions. Wherever the 1040 references some other form, I find that form, go through every line and follow the relevant instructions there. This approach has even gotten me through obscure edge cases like a company over-contributing to an HSA.
The tax code isn't magic and isn't full of gotchas. The rules may be arbitrary, but they're easy to follow and the IRS won't punish you as long as you're making a reasonable effort and report all of your income. There's an IRS help line you can call. People only really run into trouble when they try to take absurd deductions or claim that whatever tech investment strategy they've invested in doesn't count as income.
If you're scared of filing your own taxes, I really recommend volunteering for a local VITA program for a year.
As a generalist myself, I have decided not to require myself to become an expert in some tax issues, and so as a corollary decided not to complicate my finances with things that could invoke those issues.
I hand off to a tax expert when things are too complicated for a 1040EZ. Basically I hand off to an expert when the problem grows beyond my capabilities, same as any other kind of problem.
I'm not saying be great at everything, that's literally not possible. What I'm saying is that specialization is not antithetical to generalization. A good generalist should have areas of expertise because we can't cover everything. You don't need to be a world class expert, but you do need to find a niche for yourself and IMO the best way to do that is to simply follow what you find interesting.
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.
I often find myself feeling like an imposter when describing (I know enough of) the different skills I possess i.e Product Design, UX Design and Frontend Engineering. In my opinion the person solely doing one thing will probably know more than you in any of the above. But when it comes to a problem and solving the problem it becomes easier (saying I know enough) after researching and learning about it from different perspectives. The scope is narrower here than talking about an entire discipline. I don't know if it made sense tho
My approach is to understand the topic one level deeper than is needed to satisfy my immediate needs. It’s not always enough but it usually exposes any obvious traps you’d run into with only a surface level understanding, or at least lets you know if the thing really is too complex to not understand deeply and still succeed.
> My approach is to understand the topic one level deeper than is needed to satisfy my immediate needs.
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.
You aren't really a generalist if all you do is solve the problem without understanding anything, and this approach will usually bite you or your replacement down the line. Just consider solving "I need a message queue", "I need to add Elasticsearch", or gods forbid, "We need a frontend JS framework". I've been at companies where this has happened, and it's a dumpster fire weeks afterward.
In my case being a generalist is less about knowing a lot about everything, and more about knowing how to work things out, and how to bridge the gap between specialised fields.
I do end up knowing a little bit about lots of things, but in terms of "knowing enough", I only need to go into a scenario with enough knowledge to get some traction on the issue I'm working on. Once I've established a bridgehead, the rest follows naturally.
You don't become a generalist intentionally, you become one by wanting to do something that requires learning a bunch of things. So, I've never consciously thought "I know enough", I've just learned enough to do what I needed to.
Kevin Kelly says that 7 'why's are enough. As in, if you ask 'why?' 7 times, that's about as deep as you'll need to ever go.
I've heard that if you read the top 3 books/articles in the subject, that's pretty much enough too.
Pareto principle works too. Aim to learn the 20% of concepts that will give you 80% of the material
The Feynman technique is also great. You try to teach the material back to someone. Chatbots are great for this one if you can manage the prompt well enough.
Decide in advance how much time the topic deserves. No cluse as to how to do this well though, sorry.
Ask yourself: 'will knowing more about this change my decisions?'
In fast-changing fields, it’s more useful to set a rhythm for refreshing your knowledge (quarterly or annually) than to go endlessly deep once.
Some topics I end up needing to know a lot about despite lack of interest (looking at you UEFI), and so I learn until I can solve all the problems I’m having. Others I quickly pass up my needs and then continue with interest for a while (networking, routing, etc).
First I ask a bunch of questions in a chaotic manner. I explore the topic, check references, etc.
At some point the dots start to naturally connect. Then I start paraphrasing what I learned and the LLM either confirms it or clarifies where my understanding falls short.
At some point I feel naturally satisfied with the level of understanding that I have—it's likely because there's no „one more page of Google search results” trap there.
One thing to watch out is the „GOAT trap”—for instance, the default ChatGPT tends to reply with sth like: „You are the GOAT and your understanding and insight are unmatched. Let’s just clarify a few minor points”, followed by a destruction of my line of thinking, but worded in such a way that you're happy for the upcoming trip :). So you need a system prompt like „be very blunt”.
I learn what I need in order to achieve my task or solve a problem at hand. So that is the "i know enough" point. And that goes for everything, even my main focus do day to day work. It is good to be aware of some tech/capabilities but learning it only for the sake of learning it is a waste of time as if anything that you do not use, you forget. For example, you can learn 70% of features of a new language you are picking up and that will get you through 99% of your time. There is absolutely no need to learn the remaining 30% of the features that you'll never use.
So in short, learn what you need, but be aware of the options in case you might have a use case for some of them in the future in which case you will know where to look and what to learn.
> when do you say "I know enough" about any particular topic?
Never. That's the trick. There is no good answer to this question. Only the one which works for you.
You need some to come up with some other mechanisms to trigger your move-onto next stuff (or stay-on subject depending on natural tendencies).
Overall my strategy is keeping my core competencies sharp. Don't be early adopter, but keep an eye on them to pick up when things more or less prooved their workability.
The things outside of my core I dig as much as I'm interested or as much as task requires. This gives freedom to pursue whatever seems to be interesting.
--
> In 2025, with everything in tech changing by the minute,
Based on what do you build that? Based on news?
It's a FOMO. Are there objective reasons for feeding that feeling?
Can I use this now/today for something immediate? Do I otherwise think it's cool enough to play with taking time away from other activities?
That's most of it... I tend to read tech articles, documentation, etc pretty voraciously. I'm okay-ish at remembering names, or at least enough to remember what to look for if I need something and read about a good fit a few years ago. So I tend to continue to take in what I can, staying somewhat shallow outside of what's in front of me, or otherwise has my interest.
Right now, my secondary interests are around rust and adapting legacy tech (BBS Doors, Telnet, etc), so if I look into something more, that's where I'm more inclined to do it. I'm also a bit lazy.
I'll dig fairly deep in terms of what's in front of me. I'm actively working on a green C# backend so I've brought in FastEndpoints (new to me, but similar to other tech I've used) while also relying heavily on Dapper and MS-SQL Server and Grate for migrations. The use of C# and SQL Server are outside my control, as is deploying to Windows. That said, having some awareness of the ecosystem over the years lets me be able to bring in newer options that fit well over time.
By contrast, if I were working in a JS target (Node, Cloudflare, etc) I'd probably be leaning heavily into Hono+Zod+OpenAPI libraries. Again, relatively current in that space.
In the end, I just try to have awareness of what is shaping up in the communities and trying not to dive into anything I can't make use of now.
In my experience you become a good generalist by learning deeply about many things. My real skill is learning the essence of a compoex topic quickly. It also becomes easier over time to learn deeply about a new subject.
I’m not setting boundaries - and I think you will notice when to shift! When noone and no book seems to teach you anything new about a certain topic. When you read the latest book and think, „hmm yes, but i think they omitted a and b and c and in reality this isn’t so nicely separated and way more nuanced“. Then it is definitely time to shift your attention to a different topic. I’m doing this for decades now - and i think lots of others too. You will never learn all about everything. But it’s fun to try :-)
I think it goes in cycles. I used to work with Kafka and so I learned something about it. I haven’t touched kafka for 4 or so years, not sure what has changed but I feel like I want to revisit it. Same for k8s, clickhouse, etc.
Happens the same with the fundamentals (networking, OS, etc). I revisit new aspects of these topics every now and then. I still haven’t worked deeper with llms. Last week I tried for the first time coding with an agent. I take it slowly.
For instance, I never cared about learning react or vercel. I guess it paid off.
It took me decades to find a "learning routine", but it now looks like this:
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.
I don’t think I consciously became a generalist, it just happened based on necessity. I’ve worked on a lot of things that have required me to jump around a lot. I learned enough to get the job done. I always think it would be nice to know more, but there is only so much time on the day, so I don’t sweat it.
Going out of my way to dive deep on something I will never use seems like a waste of time to me. My company sent me to Citrix training years ago. I was going to get certified, but didn’t end up doing it. The class and certification seem designed for someone setting up the entire Citrix infra for their company. In my role, I just made a publish app here and there, which I already knew how to do. After the training, our use of Citrix went down, and I haven’t touched it at all in 10 years. I’m glad I didn’t waste my time deep diving on technology I’d never actually use. If we use it again in the future, I’ll have to re-learn it either way, since it’s been so long.
I go beyond on topics I actually find interesting, or seem like they will be relevant to my job for a longer period of time, where I will see some pay off.
TBH it's very difficult to gauge when to stop pursuing something. Personally, I learn something up until it stops becoming useful and/or it starts becoming more of a burden on my mental overhead. Doesn't mean I'm never going to go back to it, it just means I accomplished what I needed to do with the minimum amount of knowledge. From there on out it is entirely dependent on how much the topic interested me. Most of the time I'll end up going back to a topic anyways since making things isn't just about designing and creating the thing, it's also maintaining it. At that point it's more about whether or not you can pursue a project due to it's knowledge requirements, but I believe that falls out of the bounds of your question.
This is my rule of thumb:
Learn what you need to know first for your task at hand. If your curiosity can't be contained, make a mental note. If that mental note doesn't go anywhere and you keep dwelling on the thought of it, pursue it until your curiosity is satisfied. If done successfully, repeat.
You COULD write it down, but if you're anything like me you'll just end up with a desk filled to the brim with post it notes and never actually going back to 90% of those topics. Which kills a lot of trees. If you're into that sorta thing, don't let me stop you. Making a mental note is much better since if the topic is of interest to you, then you will not forget about it. Therefore, you'll let your curiosity build up until you cannot contain yourself and have to learn more about the topic.
NOTE:
Being a generalist usually comes because of a deep sense of curiosity in a wide range of topics. Take your time and enjoy the process of learning things since that will guarantee the longevity of your curiosity without burnout.
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.
All you need is decades old CS mostly. Then you apply this to production via software engineering principles. Systems design is the key. Always systems design. If you find something that happens to be novel then you research until the novel thing fits your mental map.
Not a generalist--don't even know what that is, Jeopardy contestant? I'd call myself a multi-specialist.
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.
Communication and execution. If you can talk about a subject precisely enough to monitor and delegate work upon that subject or execute it yourself then you know enough as a generalist.
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.
IMHO knowing when to accept defeat in a professional setting is one of the most important skills a generalist can learn. As with everything in tech the answer is "it depends" :)
When possible I'll ask to be either continue to be involved or kept in the loop until a solution is found.
By reaching these boundaries at work it provides me avenues of exploration in personal time to understand where my knowledge gaps are - and quite often find new interesting subjects along the journey.
It depends on what purpose I have for learning something. If it's to accomplish a specific task, then "I know enough" when I have learned enough to accomplish that task.
If I'm diving into a topic because I'm interested in it, then "I know enough" when my interest in it wanes or is eclipsed by something else.
But the majority of my generalist knowledge didn't come from either of those things, but from a lifeline habit of recreationally reading about things that are not "my usual kind of thing".
Generally, some amount of production deployments in a tool, language or ecosystem over time. Having an application, any application, being used by X number for Y years will expose you to the frayed edges. Sometimes you dive in on an edge case but that is when you know how deep the ocean is and how shallow your knowledge. That, vague as it is, is the line between generality and specialty in software. When you finally have to peek into specialist issues.
Try to stay up to date on anything you don't know, but suspect you probably should know to provide value in whatever it is you're doing. You could treat this to everything under the sun, but I try to apply this principal to current .Net topics that make me a valuable .Net consultant.
Entirely dependent on the people and projects you’re working on.
If the projects are simple and the people you’re working for or with don’t even know how to do the work themselves, you can be the relative expert with only a shallow knowledge of a subject.
If the people you’re working with are experts or the project is complex, you’re not going to be considered capable at all unless you can demonstrate you have significant experience and understanding on the topic.
Projective geometry and octonions and complex numbers
Soldering electronics
Transistors, resistors, capacitors, coils, and diodes
Linear Algebra
Statistical Calculus (step functions and Ito integration)
Exponential function
Gamma function
Table saws
Screws vs nails
You want a nice little ball of knowledge with a comparatively large surface that you can attach stuff to. And then you also know what kind of expert to get.
I consider myself a generalist, but, to be honest, I don't remotely think that I "know a lot of everything". In fact, I suffer about the contrary :-)
About the "when do I say 'I know enough'"...well, never. I just follow my curiosity and it's infinite ramifications. I loss/gain interests about very diverse topics in a somewhat short amount of time.
When I get bored? I mean, the learning is a huge motivator to me, but on most topics I reach a point I don't really want to go deeper or I get distracted by something else.
When you notice that you may be getting too deep into the wrong topic. Solving a problem is not just taking one approach, one relevant topic, one way to solve it. That depends on the problem, the situation and the system it is in, it might worth it to go all the way down for some of them, but you have to evaluate.
This is only true if you are studying the wrong thing. Irrelevant implementation details change by the minute, but they are irrelevant expect in the very moment you need that detail, so only learn them by repetitive use. Meanwhile the fundamentals do not change, as a generalist you will be looking to learn those so that when you need details you understand what the implementation is doing. As you get older (more experienced) you will start to see how the the latest implementation is change either for the sake of change, or corruption (that is you can convince someone it is innovative and thus make money even though you are making things objectively worse - see touch screens in cars), soon you with be shaking your first at the stars and yelling to the wind how much better it used to be (while ignoring all progress!)
Tech is not changing by the minute. There have been only minor changes since I was in elementary school in the 1980s. 8 bit to 64 bit CPUS are a minor change since they fundamentally do the same thing. We were doing some interesting GUIs in the 1980s. (I'm not old enough to remember the XEROX systems of the 1970s much less tech before then). Learn the fundamentals and things won't be changing fast.
In my case, my “generalism” is mostly driven by ADHD, it happens when my brain gets bored with one subject. I don't think it's conscious in any way. I tend to go through phases: I’ll get into a topic, then switch to another, then another. After a few months, I circle back to the first subject, picking up where I left off (minus whatever I’ve forgotten). And the cycle repeats.
I stop when the immediate business need is fulfilled.
I see it a lot like tools in your toolbox. You start buy buying the cheapest of whatever it is you need. If you end up either using a particular tool a lot and a nicer/more expensive version of it will make your life better you then upgrade. If you end up breaking the cheaper one you also invest the money into upgrading. You generally find that you are only upgrading a small fraction of your toolbox this way, and save quite a bit of money vs. buying an entire set of expensive professional grade gear.
I see that for skillsets as well. Why waste time on knowing the nitty gritty deep level of something if I will rarely come back to use it again. If I can cargo-cult my way into getting the thing done and moving on I will. If I end up coming back to the thing on a constant basis I will then invest the time into learning the deeper internals/details/tricks etc.
I have one rule that I have kept for a decade - I don’t touch the clusterfuck of front end development.
My value proposition is simple. Like Joel Spolsky hiring criteria, I make sure I continue to have experience that shows “I am smart and gets things done” and I pick a lane to go deep in - “cloud native green field implementations”. If that lane starts to narrow, I’ll jump on projects at work that get me into another lane. Technology is just a tool. Anything you learn new, Tens of thousands of others will learn the same thing.
Learning technology and not knowing how to communicate with the “business” and how to communicate adding business value will not help you stand out.
“I know enough about X,” is willful ignorance. But “I have reached the limit of my interest in X for now,” is subtly different and healthy because interests come and go.
But, you can’t keep up and feeling like you ever kept up is an illusion of youth. So my advice:
If you have to pick something to learn (because you do not know useful things to learn) consider things that have been around a while like Linux and JavaScript and C++ and RDBMS etc.
because they probably aren’t going to stop being relevant. Good luck.
I have a good sense of when I'm ignorant, and google very fast. If I feel the right mix of ignorance and curiosity, I will procure and devour relevant books. The trick is knowing a little bit about a lot of thing.
The honest answer is that I stop caring if I lose curiosity. The rationalized answer is that expertise requires maintenance, and a low likelihood of using some expertise doesn't justify that maintenance. For example, I am unlikely to ever do advanced financial planning, and I can re-learn / lookup the formulas for doing calculations, or maybe even re-derive them if I really need to. On demand learning!
Practicality puts bounds on how much to rabbit hole.
A theoretician in the purest sense is removed from practical constraints and timelines. He can, in principle, keep pursuing a subject until the day he dies.
A practitioner is aiming for a practical result within a time frame. Because he has to deliver, he cannot afford to focus on developing a deep or exhaustive grasp of any particular thing. His focus isn't knowledge, after all, but the practical result. He will lean more on what he already knows, however limited, rather than pursuing new knowledge. He is less concerned with verifying the truth of claims himself and more concerned with trusting claims tactically by knowing whom to trust and when.
So, in the capacity of practitioner, you must learn prudence, which is the virtue of knowing what should be done in a given situation. It is the basis for the moral life, as morality concerns itself with right action and right decision making.
It's all about history repeating; or better yet understanding when it's something new and often forcing that.
They say 10,000 hours to become an expert, but that's brute forced learning. When you actually learn how to learn, what universities USED TO teach and have since stopped teaching, you can do it much quicker. People who know how to learn can become an expert in under 1000 hours.
>In 2025, with everything in tech changing by the minute, I’m realizing I need to set boundaries about how deep I go on any particular topic. But I’m unsure how. Particularly if I don’t want to get left behind as things continue to evolve.
that's the wrong way to approach it; or perhaps definition of depth? Depth to me is about a subject that cant be understood until certain other learning milestones have been learnt. Which is perhaps a depth, but also something you can force as something new. A new pattern that will as above be part of the learning.
It's fine to go deep, so long as you're seeing a new pattern you cant predict. The limit isnt about depth, it's about seeing something new.
I learn about something when I need to know in order to do something I'm trying to do, or when I'm curious. The second one is kind of self-limiting - when I don't have time or energy, I'm less curious.
I don't feel that I "ought" to know. There's too much. I can't. So I learn what I need, and what I want.
Left behind? You have no choice. When you're learning A, you're not learning B through Z, except that there are a lot more than 26 options. You can't learn it all. There's simply not enough time.
The real question is, of the limited amount of time you have for learning, what's the most important/valuable thing for you to be learning now?
once i have determined the leading exponent in any field and understanding his views, i ask whether i know enough to determine whether the information is useful to my purpose. if so, i continue to go deeper; if not, i know enough.
Or project-based? If you are a writer, for example, it's usually project based.
Otherwise, if you really have a hard time setting boundaries, then you might be the type to orient yourself around the states of your social circles. They definitely have boundaries when they stop listening or caring.
If you can't say enough is enough yourself, let someone you trust, or in whose competence you trust, do it for you.
I would say something like "when does it stop being useful" but the 'real' infinite game is all about curiosity and there's almost no players, just uninterested and destructive shareholders, so I'm gonna go with "do you have a thread that connects it all or not?" If you don't, and it only leads to more and more excursions, fix that point of depth where some subject still interfaces with the other stuff and stop there.
I stop when I find a solution to the problem. Most of the time the learning happens along the way, not necessarily in the solution itself but all the things you try and iterate on your journey to the solution.
Everything changes in tech by the minute ... but also nothing changes. For web applications it has been HTML, CSS and JS for nearly 30 years. XMLHttpRequest/AJAX came out 25+ years ago. There have been many improvements along the way, like applying design patterns instead of cgi-bin directories with scripts that had a +x modifier on them in the file system. But the base technologies have not changed all that much. We still submit HTML form's with input fields to a back-end server that handles that data. We're still rendering HTML and using CSS to style it. Gone are custom UI toolkits like Flash or Java Applets. Maybe WASM is something to look into but it feels like its not mainstream to me.
If you don't want to get left behind, learn the basic building blocks at a deep level, they don't change much.
> 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.
That's funny, I often love learning for the sake of.. experimenting, building things. I just recognize that I cannot do it all and prioritize immediate needs first.
> That's funny, I often love learning for the sake of.. experimenting, building things. I just recognize that I cannot do it all and prioritize immediate needs first.
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.
So what happens when you can't find a solution to your problem and hit the edges of current research even specialists cannot buckle?
I say, "you're going to need to pay a team of PhDs to work on this to maybe get a solution, eventually, or change your approach. Here's why: [evidence]"
I've never worked with or for anyone who wanted to hire the team of PhDs.
this is often a sign that the design/solution you've chosen is an unfruitful path.
know when to cut your losses and try something different.
I go for "I can understand experts, but not add much to the conversation" as a benchmark for knowing enough to participate in discussions at work. Then I use that "I can solve my immediate problem" method going forward.
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 do a lot of repairs on electronics. I stop when I understand enough of the theory of operation to get things fixed. I've worked on everything from industrial control like 480 volt 3 phase SCR packs to Cesium beam atomic clocks.
If it was interesting, I'll dive in to learn more in case I encounter something similar in the future.
I never aspired to be a generalist, but I have come to realize my process has made me into one.
If I had to generalize how I work, I'd say it comes down to:
1. Identify the highest value thing I can work on that is feasible
2. Learn what I need to finish the work. Invest as little time/effort as possible into topics that have not proven to be timeless. Lindy's Law is your guide here.
3. when the solution is good enough, go back to 1.
Being a generalist doesn't mean you aren't an expert in anything. There are topics that I've identified as being so timeless and high value that I've more time and effort into them than others (making me a relative expert, I guess).
For me, it is more about targeting the goals at hand and learning just what I need than setting out to master the tools I like. Over time you will become an expert in the tools you trust.
You never know 'enough'. You just have broad interests and see how all things are more interlinked than any one specific branch of knowledge captures. So you naturally wander through a host of subjects rather than exclusively deepdive into a single specialization.
This. Often you'll also put something down for a while only to pick it up again years later, dusting off your old know-how.
Learning is a never-ending process in which progress is not stable and regression also happens. In that sense it is sisyphean.
I don't understand the question. One does not simply decide to stop falling down the rabbit hole, you keep going until it stops or you get taken down a different path. Never in my life have I made an active decision to stop learning about any one thing. You learn whatever skill is required to deal with the problem at hand and go on keep learning until you need a new skill or just get distracted.
But also you're making an extremely bad mistake in your thinking here. Being a generalist does not preclude being a master. In fact, I've found that in today's market you must have specializations. Right now I'm selling myself as an electronics engineer and embedded C programmer. But my deepest expertice is C#, where I consider myself to be a fairly high level expert. My current job is writing react native with some EE on the side.
You're trying to actively spread yourself even thinner which is a huge error. Knowing almost nothing about everything is not useful today, we just use AI for that. You need some real, solid skills to work from. You also need to be able to be a specialist and do specialist work because you are not likely to find a good generalist role. There aren't many such roles and they're getting harder to find.
But all in all my answer is no. There is no point where you should stop learning any one thing. Follow your passions and what's interesting. Finding a subject you're interested in and spending a ton of time learning about it isn't a bad thing. That's how you figure out what you like and how you build real skills. You should follow particular subjects into mastery because a generalist without any specialization is not actually very useful unless you're a world class engineer.
It's clichéd, but genuinely follow whatever subjects make you happy and find a way to make that work for you.
Grounding with a real scenario: You're doing your taxes. At what point do you hand off to a tax expert?
OP's asking a tough question.
At some point, it's impractical to try to be great at everything.
I never hand my taxes off to a tax expert.
If I run into a problem where I can't interpret the tax code myself, I'll schedule an hour appointment with a tax expert to get the answer to that specific question. If their answer sounds too good to be true, I'll schedule some appointments with other experts and take the most pessimistic answer. Ultimately, it's my responsibility that my taxes are correct, so I need to understand how they work.
I switched off of using tax software and do my taxes by hand, including rental income and stock sales. I'd estimate my tax return is 20-30 pages at this point.
If I ran my own company, I'd hand my taxes off to a tax expert at the point where filling out all of the forms represented such a significant investment in time that it detracted from my ability to run the company, but they would have to be significantly more complicated than anything the average person encounters. I would also hand them off to a separate firm if they reached the point where I needed credentials for the tax return to be valid - such as to assess the value of inventory.
It really doesn't take that much effort to learn how to do your own taxes, and the VITA program provides good free training in exchange for volunteering, which provides essential practice time anyway.
>where I can't interpret the tax code myself
That still leaves you making the crucial decision of when to roll in the expert with a layman's knowledge base & judgement.
Conceptually "I'll know when I don't know" is a very weak approach, especially on things like tax where the gotchas can be arbitrary & non-intuitive.
It's actually pretty simple. "Where I can't interpret the tax code myself" means "where my attempt to interpret the tax code leaves me with two or more possible interpretations."
The tax forms are very comprehensive. I go through each line of the 1040, following the instructions. Wherever the 1040 references some other form, I find that form, go through every line and follow the relevant instructions there. This approach has even gotten me through obscure edge cases like a company over-contributing to an HSA.
The tax code isn't magic and isn't full of gotchas. The rules may be arbitrary, but they're easy to follow and the IRS won't punish you as long as you're making a reasonable effort and report all of your income. There's an IRS help line you can call. People only really run into trouble when they try to take absurd deductions or claim that whatever tech investment strategy they've invested in doesn't count as income.
If you're scared of filing your own taxes, I really recommend volunteering for a local VITA program for a year.
> If you're scared of filing your own taxes
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
As a generalist myself, I have decided not to require myself to become an expert in some tax issues, and so as a corollary decided not to complicate my finances with things that could invoke those issues.
I hand off to a tax expert when things are too complicated for a 1040EZ. Basically I hand off to an expert when the problem grows beyond my capabilities, same as any other kind of problem.
I'm not saying be great at everything, that's literally not possible. What I'm saying is that specialization is not antithetical to generalization. A good generalist should have areas of expertise because we can't cover everything. You don't need to be a world class expert, but you do need to find a niche for yourself and IMO the best way to do that is to simply follow what you find interesting.
> "too complicated...beyond my capabilities"
To OP's question, how did you decide that going further down the tax education wasn't for you? Was it really capabilities?
I propose that what you're really saying is that you're
a. not as intellectually curious about tax matters
b. or not concerned about the opportunity cost of your delegate being wrong
which makes it an easier choice to delegate.
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.
I often find myself feeling like an imposter when describing (I know enough of) the different skills I possess i.e Product Design, UX Design and Frontend Engineering. In my opinion the person solely doing one thing will probably know more than you in any of the above. But when it comes to a problem and solving the problem it becomes easier (saying I know enough) after researching and learning about it from different perspectives. The scope is narrower here than talking about an entire discipline. I don't know if it made sense tho
My approach is to understand the topic one level deeper than is needed to satisfy my immediate needs. It’s not always enough but it usually exposes any obvious traps you’d run into with only a surface level understanding, or at least lets you know if the thing really is too complex to not understand deeply and still succeed.
> My approach is to understand the topic one level deeper than is needed to satisfy my immediate needs.
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.
"one level deeper" is a great way to look at it!
You aren't really a generalist if all you do is solve the problem without understanding anything, and this approach will usually bite you or your replacement down the line. Just consider solving "I need a message queue", "I need to add Elasticsearch", or gods forbid, "We need a frontend JS framework". I've been at companies where this has happened, and it's a dumpster fire weeks afterward.
In my case being a generalist is less about knowing a lot about everything, and more about knowing how to work things out, and how to bridge the gap between specialised fields.
I do end up knowing a little bit about lots of things, but in terms of "knowing enough", I only need to go into a scenario with enough knowledge to get some traction on the issue I'm working on. Once I've established a bridgehead, the rest follows naturally.
You don't become a generalist intentionally, you become one by wanting to do something that requires learning a bunch of things. So, I've never consciously thought "I know enough", I've just learned enough to do what I needed to.
Kevin Kelly says that 7 'why's are enough. As in, if you ask 'why?' 7 times, that's about as deep as you'll need to ever go.
I've heard that if you read the top 3 books/articles in the subject, that's pretty much enough too.
Pareto principle works too. Aim to learn the 20% of concepts that will give you 80% of the material
The Feynman technique is also great. You try to teach the material back to someone. Chatbots are great for this one if you can manage the prompt well enough.
Decide in advance how much time the topic deserves. No cluse as to how to do this well though, sorry.
Ask yourself: 'will knowing more about this change my decisions?'
In fast-changing fields, it’s more useful to set a rhythm for refreshing your knowledge (quarterly or annually) than to go endlessly deep once.
When I run out of need and interest.
Some topics I end up needing to know a lot about despite lack of interest (looking at you UEFI), and so I learn until I can solve all the problems I’m having. Others I quickly pass up my needs and then continue with interest for a while (networking, routing, etc).
I've found that LLMs help me find the boundary.
First I ask a bunch of questions in a chaotic manner. I explore the topic, check references, etc.
At some point the dots start to naturally connect. Then I start paraphrasing what I learned and the LLM either confirms it or clarifies where my understanding falls short.
At some point I feel naturally satisfied with the level of understanding that I have—it's likely because there's no „one more page of Google search results” trap there.
One thing to watch out is the „GOAT trap”—for instance, the default ChatGPT tends to reply with sth like: „You are the GOAT and your understanding and insight are unmatched. Let’s just clarify a few minor points”, followed by a destruction of my line of thinking, but worded in such a way that you're happy for the upcoming trip :). So you need a system prompt like „be very blunt”.
I learn what I need in order to achieve my task or solve a problem at hand. So that is the "i know enough" point. And that goes for everything, even my main focus do day to day work. It is good to be aware of some tech/capabilities but learning it only for the sake of learning it is a waste of time as if anything that you do not use, you forget. For example, you can learn 70% of features of a new language you are picking up and that will get you through 99% of your time. There is absolutely no need to learn the remaining 30% of the features that you'll never use.
So in short, learn what you need, but be aware of the options in case you might have a use case for some of them in the future in which case you will know where to look and what to learn.
> when do you say "I know enough" about any particular topic?
Never. That's the trick. There is no good answer to this question. Only the one which works for you.
You need some to come up with some other mechanisms to trigger your move-onto next stuff (or stay-on subject depending on natural tendencies).
Overall my strategy is keeping my core competencies sharp. Don't be early adopter, but keep an eye on them to pick up when things more or less prooved their workability.
The things outside of my core I dig as much as I'm interested or as much as task requires. This gives freedom to pursue whatever seems to be interesting.
--
> In 2025, with everything in tech changing by the minute,
Based on what do you build that? Based on news?
It's a FOMO. Are there objective reasons for feeding that feeling?
As others have said, generality of knowledge and skills is the effect, not the cause; the cause is diversity of interests and restlessness.
Can I use this now/today for something immediate? Do I otherwise think it's cool enough to play with taking time away from other activities?
That's most of it... I tend to read tech articles, documentation, etc pretty voraciously. I'm okay-ish at remembering names, or at least enough to remember what to look for if I need something and read about a good fit a few years ago. So I tend to continue to take in what I can, staying somewhat shallow outside of what's in front of me, or otherwise has my interest.
Right now, my secondary interests are around rust and adapting legacy tech (BBS Doors, Telnet, etc), so if I look into something more, that's where I'm more inclined to do it. I'm also a bit lazy.
I'll dig fairly deep in terms of what's in front of me. I'm actively working on a green C# backend so I've brought in FastEndpoints (new to me, but similar to other tech I've used) while also relying heavily on Dapper and MS-SQL Server and Grate for migrations. The use of C# and SQL Server are outside my control, as is deploying to Windows. That said, having some awareness of the ecosystem over the years lets me be able to bring in newer options that fit well over time.
By contrast, if I were working in a JS target (Node, Cloudflare, etc) I'd probably be leaning heavily into Hono+Zod+OpenAPI libraries. Again, relatively current in that space.
In the end, I just try to have awareness of what is shaping up in the communities and trying not to dive into anything I can't make use of now.
In my experience you become a good generalist by learning deeply about many things. My real skill is learning the essence of a compoex topic quickly. It also becomes easier over time to learn deeply about a new subject.
I’m not setting boundaries - and I think you will notice when to shift! When noone and no book seems to teach you anything new about a certain topic. When you read the latest book and think, „hmm yes, but i think they omitted a and b and c and in reality this isn’t so nicely separated and way more nuanced“. Then it is definitely time to shift your attention to a different topic. I’m doing this for decades now - and i think lots of others too. You will never learn all about everything. But it’s fun to try :-)
I think it goes in cycles. I used to work with Kafka and so I learned something about it. I haven’t touched kafka for 4 or so years, not sure what has changed but I feel like I want to revisit it. Same for k8s, clickhouse, etc.
Happens the same with the fundamentals (networking, OS, etc). I revisit new aspects of these topics every now and then. I still haven’t worked deeper with llms. Last week I tried for the first time coding with an agent. I take it slowly.
For instance, I never cared about learning react or vercel. I guess it paid off.
It took me decades to find a "learning routine", but it now looks like this:
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.
I don’t think I consciously became a generalist, it just happened based on necessity. I’ve worked on a lot of things that have required me to jump around a lot. I learned enough to get the job done. I always think it would be nice to know more, but there is only so much time on the day, so I don’t sweat it.
Going out of my way to dive deep on something I will never use seems like a waste of time to me. My company sent me to Citrix training years ago. I was going to get certified, but didn’t end up doing it. The class and certification seem designed for someone setting up the entire Citrix infra for their company. In my role, I just made a publish app here and there, which I already knew how to do. After the training, our use of Citrix went down, and I haven’t touched it at all in 10 years. I’m glad I didn’t waste my time deep diving on technology I’d never actually use. If we use it again in the future, I’ll have to re-learn it either way, since it’s been so long.
I go beyond on topics I actually find interesting, or seem like they will be relevant to my job for a longer period of time, where I will see some pay off.
TBH it's very difficult to gauge when to stop pursuing something. Personally, I learn something up until it stops becoming useful and/or it starts becoming more of a burden on my mental overhead. Doesn't mean I'm never going to go back to it, it just means I accomplished what I needed to do with the minimum amount of knowledge. From there on out it is entirely dependent on how much the topic interested me. Most of the time I'll end up going back to a topic anyways since making things isn't just about designing and creating the thing, it's also maintaining it. At that point it's more about whether or not you can pursue a project due to it's knowledge requirements, but I believe that falls out of the bounds of your question.
This is my rule of thumb:
Learn what you need to know first for your task at hand. If your curiosity can't be contained, make a mental note. If that mental note doesn't go anywhere and you keep dwelling on the thought of it, pursue it until your curiosity is satisfied. If done successfully, repeat.
You COULD write it down, but if you're anything like me you'll just end up with a desk filled to the brim with post it notes and never actually going back to 90% of those topics. Which kills a lot of trees. If you're into that sorta thing, don't let me stop you. Making a mental note is much better since if the topic is of interest to you, then you will not forget about it. Therefore, you'll let your curiosity build up until you cannot contain yourself and have to learn more about the topic.
NOTE: Being a generalist usually comes because of a deep sense of curiosity in a wide range of topics. Take your time and enjoy the process of learning things since that will guarantee the longevity of your curiosity without burnout.
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.
When I get bored of the topic. I have ADHD so that factors in to this.
If this is about SWE roles - this is my take.
All you need is decades old CS mostly. Then you apply this to production via software engineering principles. Systems design is the key. Always systems design. If you find something that happens to be novel then you research until the novel thing fits your mental map.
I know that "I know enough" when my predictions are accurate enough.
Not a generalist--don't even know what that is, Jeopardy contestant? I'd call myself a multi-specialist.
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.
Usually, when 'specialists' start asking my help to debug their area of expertise.
Communication and execution. If you can talk about a subject precisely enough to monitor and delegate work upon that subject or execute it yourself then you know enough as a generalist.
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.
IMHO knowing when to accept defeat in a professional setting is one of the most important skills a generalist can learn. As with everything in tech the answer is "it depends" :)
When possible I'll ask to be either continue to be involved or kept in the loop until a solution is found.
By reaching these boundaries at work it provides me avenues of exploration in personal time to understand where my knowledge gaps are - and quite often find new interesting subjects along the journey.
It depends on what purpose I have for learning something. If it's to accomplish a specific task, then "I know enough" when I have learned enough to accomplish that task.
If I'm diving into a topic because I'm interested in it, then "I know enough" when my interest in it wanes or is eclipsed by something else.
But the majority of my generalist knowledge didn't come from either of those things, but from a lifeline habit of recreationally reading about things that are not "my usual kind of thing".
Generally, some amount of production deployments in a tool, language or ecosystem over time. Having an application, any application, being used by X number for Y years will expose you to the frayed edges. Sometimes you dive in on an edge case but that is when you know how deep the ocean is and how shallow your knowledge. That, vague as it is, is the line between generality and specialty in software. When you finally have to peek into specialist issues.
Is there really ever enough?
Try to stay up to date on anything you don't know, but suspect you probably should know to provide value in whatever it is you're doing. You could treat this to everything under the sun, but I try to apply this principal to current .Net topics that make me a valuable .Net consultant.
From time to time.
Then I come back some time later (minutes, days, years etc) and realize I didn't know what I was missing.
The cosmos is vast and beautiful. Humility helps, but may not come easy.
Entirely dependent on the people and projects you’re working on.
If the projects are simple and the people you’re working for or with don’t even know how to do the work themselves, you can be the relative expert with only a shallow knowledge of a subject.
If the people you’re working with are experts or the project is complex, you’re not going to be considered capable at all unless you can demonstrate you have significant experience and understanding on the topic.
It helps to know about a few key details:
Gravity
Halting problem
Travelling salesman & NP-hard
CRUD
Gödel's incompleteness theorem
Kolmogorov complexity
Series by Richard C. Waters
Simple finite groups
Projective geometry and octonions and complex numbers
Soldering electronics
Transistors, resistors, capacitors, coils, and diodes
Linear Algebra
Statistical Calculus (step functions and Ito integration)
Exponential function
Gamma function
Table saws
Screws vs nails
You want a nice little ball of knowledge with a comparatively large surface that you can attach stuff to. And then you also know what kind of expert to get.
Utility, mainly. I know just enough to Provide Value; the concept of 'enough' doesn't really exist for my true interests.
I consider myself a generalist, but, to be honest, I don't remotely think that I "know a lot of everything". In fact, I suffer about the contrary :-)
About the "when do I say 'I know enough'"...well, never. I just follow my curiosity and it's infinite ramifications. I loss/gain interests about very diverse topics in a somewhat short amount of time.
When I get bored? I mean, the learning is a huge motivator to me, but on most topics I reach a point I don't really want to go deeper or I get distracted by something else.
THat's easy. By definition "enough" is context dependent.
If I see that for a given question/problem/project/goal I know _enough_ - then it's enough.
So the best constraint and source of focus is the ultimate goal you have in mind when you start going into some topic.
When you notice that you may be getting too deep into the wrong topic. Solving a problem is not just taking one approach, one relevant topic, one way to solve it. That depends on the problem, the situation and the system it is in, it might worth it to go all the way down for some of them, but you have to evaluate.
> with everything in tech changing by the minute
This is only true if you are studying the wrong thing. Irrelevant implementation details change by the minute, but they are irrelevant expect in the very moment you need that detail, so only learn them by repetitive use. Meanwhile the fundamentals do not change, as a generalist you will be looking to learn those so that when you need details you understand what the implementation is doing. As you get older (more experienced) you will start to see how the the latest implementation is change either for the sake of change, or corruption (that is you can convince someone it is innovative and thus make money even though you are making things objectively worse - see touch screens in cars), soon you with be shaking your first at the stars and yelling to the wind how much better it used to be (while ignoring all progress!)
Tech is not changing by the minute. There have been only minor changes since I was in elementary school in the 1980s. 8 bit to 64 bit CPUS are a minor change since they fundamentally do the same thing. We were doing some interesting GUIs in the 1980s. (I'm not old enough to remember the XEROX systems of the 1970s much less tech before then). Learn the fundamentals and things won't be changing fast.
i don't stop per-se.
i prioritize what is most important at the time.
learning to prioritize is invaluable. i'm still working on it.
> i prioritize what is most important at the time. learning to prioritize is invaluable. i'm still working on it.
You hit on the head.
A lot of responses here missed that effectively this was a question about time management and prioritization. Not drive or curiosity.
Good reminder that it’s a journey for all of us. What’s worked for you? What have you found helpful in your journey to learn?
When I understand enough to determine the up and downsides of an approach / way forward and also a good grasp of the limitations of my knowledge.
When I run into someone in the hall at Defcon and they assume that what we're discussing is my day job.
In my case, my “generalism” is mostly driven by ADHD, it happens when my brain gets bored with one subject. I don't think it's conscious in any way. I tend to go through phases: I’ll get into a topic, then switch to another, then another. After a few months, I circle back to the first subject, picking up where I left off (minus whatever I’ve forgotten). And the cycle repeats.
Just take those ADHD meds ;)
lol, that’s what made me focus and step back long enough to ask the question
when you finish the task which originally drove you to learn about the topic
I stop when the immediate business need is fulfilled.
I see it a lot like tools in your toolbox. You start buy buying the cheapest of whatever it is you need. If you end up either using a particular tool a lot and a nicer/more expensive version of it will make your life better you then upgrade. If you end up breaking the cheaper one you also invest the money into upgrading. You generally find that you are only upgrading a small fraction of your toolbox this way, and save quite a bit of money vs. buying an entire set of expensive professional grade gear.
I see that for skillsets as well. Why waste time on knowing the nitty gritty deep level of something if I will rarely come back to use it again. If I can cargo-cult my way into getting the thing done and moving on I will. If I end up coming back to the thing on a constant basis I will then invest the time into learning the deeper internals/details/tricks etc.
Are you truly a “generalist”? These are the different “roadmaps” for someone who wants to be good at something.
https://github.com/kamranahmedse/developer-roadmap
I have one rule that I have kept for a decade - I don’t touch the clusterfuck of front end development.
My value proposition is simple. Like Joel Spolsky hiring criteria, I make sure I continue to have experience that shows “I am smart and gets things done” and I pick a lane to go deep in - “cloud native green field implementations”. If that lane starts to narrow, I’ll jump on projects at work that get me into another lane. Technology is just a tool. Anything you learn new, Tens of thousands of others will learn the same thing.
Learning technology and not knowing how to communicate with the “business” and how to communicate adding business value will not help you stand out.
I’ve done this for over 30 years.
Thanks for sharing, I’ll take a look!
A. Never
The real Q. is “When do you stop learning?”
A. When you dangerous enough
“I know enough to do the thing,” is fine.
“I know enough about X,” is willful ignorance. But “I have reached the limit of my interest in X for now,” is subtly different and healthy because interests come and go.
But, you can’t keep up and feeling like you ever kept up is an illusion of youth. So my advice:
If you have to pick something to learn (because you do not know useful things to learn) consider things that have been around a while like Linux and JavaScript and C++ and RDBMS etc. because they probably aren’t going to stop being relevant. Good luck.
I have a good sense of when I'm ignorant, and google very fast. If I feel the right mix of ignorance and curiosity, I will procure and devour relevant books. The trick is knowing a little bit about a lot of thing.
The honest answer is that I stop caring if I lose curiosity. The rationalized answer is that expertise requires maintenance, and a low likelihood of using some expertise doesn't justify that maintenance. For example, I am unlikely to ever do advanced financial planning, and I can re-learn / lookup the formulas for doing calculations, or maybe even re-derive them if I really need to. On demand learning!
Two options:
1) I get bored
2) Something with a higher priority comes up
Practicality puts bounds on how much to rabbit hole.
A theoretician in the purest sense is removed from practical constraints and timelines. He can, in principle, keep pursuing a subject until the day he dies.
A practitioner is aiming for a practical result within a time frame. Because he has to deliver, he cannot afford to focus on developing a deep or exhaustive grasp of any particular thing. His focus isn't knowledge, after all, but the practical result. He will lean more on what he already knows, however limited, rather than pursuing new knowledge. He is less concerned with verifying the truth of claims himself and more concerned with trusting claims tactically by knowing whom to trust and when.
So, in the capacity of practitioner, you must learn prudence, which is the virtue of knowing what should be done in a given situation. It is the basis for the moral life, as morality concerns itself with right action and right decision making.
i really like that pov
>The idea is generalists know a lot about everything and when to pass it off to a subject matter expert.
https://www.youtube.com/watch?v=5eW6Eagr9XA
https://en.wikipedia.org/wiki/Four_stages_of_competence
It's all about history repeating; or better yet understanding when it's something new and often forcing that.
They say 10,000 hours to become an expert, but that's brute forced learning. When you actually learn how to learn, what universities USED TO teach and have since stopped teaching, you can do it much quicker. People who know how to learn can become an expert in under 1000 hours.
>In 2025, with everything in tech changing by the minute, I’m realizing I need to set boundaries about how deep I go on any particular topic. But I’m unsure how. Particularly if I don’t want to get left behind as things continue to evolve.
that's the wrong way to approach it; or perhaps definition of depth? Depth to me is about a subject that cant be understood until certain other learning milestones have been learnt. Which is perhaps a depth, but also something you can force as something new. A new pattern that will as above be part of the learning.
It's fine to go deep, so long as you're seeing a new pattern you cant predict. The limit isnt about depth, it's about seeing something new.
I learn about something when I need to know in order to do something I'm trying to do, or when I'm curious. The second one is kind of self-limiting - when I don't have time or energy, I'm less curious.
I don't feel that I "ought" to know. There's too much. I can't. So I learn what I need, and what I want.
Left behind? You have no choice. When you're learning A, you're not learning B through Z, except that there are a lot more than 26 options. You can't learn it all. There's simply not enough time.
The real question is, of the limited amount of time you have for learning, what's the most important/valuable thing for you to be learning now?
once i have determined the leading exponent in any field and understanding his views, i ask whether i know enough to determine whether the information is useful to my purpose. if so, i continue to go deeper; if not, i know enough.
Isn't this dictated by your available free time?
Or project-based? If you are a writer, for example, it's usually project based.
Otherwise, if you really have a hard time setting boundaries, then you might be the type to orient yourself around the states of your social circles. They definitely have boundaries when they stop listening or caring.
If you can't say enough is enough yourself, let someone you trust, or in whose competence you trust, do it for you.
I would say something like "when does it stop being useful" but the 'real' infinite game is all about curiosity and there's almost no players, just uninterested and destructive shareholders, so I'm gonna go with "do you have a thread that connects it all or not?" If you don't, and it only leads to more and more excursions, fix that point of depth where some subject still interfaces with the other stuff and stop there.
> Isn't this dictated by your available free time?
Yes, and at its core I’m asking how to use my free time most efficiently