Ask HN: Do you regret being a generalist? | Hacker News Reader

Ask HN: Do you regret being a generalist?

236 pointsnonasktell224 comments

I'm a fairly young SWE in my early twenties, and I've tried a bit of everything.

Fullstack web dev, a bit of cyber security, a bit of AI, mobile apps, all kind of automation/bots/mass scraping, growth hacking, small games, low level C...

And I'm starting to wonder if I should specialize.

I've always been interested by AI, but since it's such a large/complex field, I never really took the time to dedicate myself to it completely because I'm always interested by 10 things at the same time.

I have absolutely zero doubts about my employability, but I'm afraid to regret it long term if I don't specialize in an interesting field.

Do you regret being a generalist? Have you been one in the past and then changed? In that case what do you prefer? Do you regret it?

View on HN

Pro tip: you're not a generalist. A big chunk of specializing is how you package/market yourself.

I consider myself a "full stack employee". I've done backend, frontend, hosted live events, some sales, marketing, a dash of HR, pretty much everything.

Do I write that on my LinkedIn? Heck no. A year or so ago I looked at all the experience I had, saw I had a through-line story of how I've worked on video projects over the past 7ish years, and decided "I'm the frontend WebRTC guy." I identified the spots of knowledge I needed to read up on to be confident (just a few gaps here and there) interviewed at a job, and within 10 minutes into the interview my future (now current) boss said "You're the perfect fit!". Because I was. I'm the frontend WebRTC guy with some sales/marketing experience, and they needed a frontend WebRTC guy with some sales/marketing experience.

Before that, I was the Frontend DevOps guy. Before that, I was the Backbone.js guy. And before that, I was the Sharepoint guy (shhhhh don't tell anyone!)

If you're interested in AI, just go poke around and find something in AI. Don't sweat it. We all got plenty of time, and like you said, as long as we can center divs and set up click tracking on a Wordpress site we'll always be able to put food on the table! :)

One of the best pieces of advice somebody gave me, was along the lines: "if you are not interested on it, don't even think about touching it, not even with the light of a laser pointer, keep away from it, play it stupid" That was short after I started playing with sendmail configuration, and I started to be named "the expert" of sendmail... BIG mistake... So, yeah... just do not tell anybody your skills, if you do not want to use them.

There is an element of truth to this, especially if you don't have leverage. I've been there, too. Actually, there are two risks:

- People (co-workers AND management) may cynically use you for the tasks that are menial, messy and boring and doesn't lead anywhere. You become the tech equivalent of a janitor or secretary.

- People who see only one side of you think that that side is your only skill, not something you're able to in addition to your primary skillset.

In both cases, if you decide to assume the role of a generalist but want to avoid these risks, you have to spend some effort to position yourself.

These are the steps I would recommend:

1. When describing yourself, do emphasize the generalism. I tend to claim that I can do almost anything as long as it is technical, but I do some things quite slowly. In particular you need to communicate this with your manager.

2. Make sure you demonstrate the skills in the sides you have that you want to spend more time on. This means to volunteer for tasks of this type, and make sure to overperform on these tasks and market the result to decision-makers. This is perhaps the most crucial part, as it includes demonstrating an ability to show initiative and work independently.

3. Let people know that your time is valuable and costly. With managers you need to demonstrate that you can produce more value for them if they don't let you get stuck into something trivial.

4. With lazy/abusive co-workers, you may have to simply let them know that you're not the assistant they can hand over the boring part to. This may be more difficult than with the managers, especially if you're not good at marking your limits in a firm but polite manner.

However as long as management want you to work where you provide more value, you can simply tell your co-workers something like "I'd love to help you with <insert menial task they prefent not to be able to do>, AGAIN, but I'm afraid I don't have much free time until Thursday from 7am-8am two weeks from now....". Or you can simply say "I'd love to help you with <same as above>, but I've been ordered to focuson <insert more interesting task>, maybe you can explain your need to my manager and have him approve this". One approach is to make it inconvenient for them, the other is to force them to admit some deficiency to management before you help them.

This advice should also translate to your resume/LinkedIn. If you list a piece of technology on your resume you should know that it’s fair game for people to ask question about it during interviews and for your resume to match on those keywords.

I see so many resumes with massive lists of technology exposure. I assume the intention is to demonstrate the breadth of experience. But if you don’t want to work in that language or framework you used 10 years ago, take it off. Only list the stuff that is relevant and that you’re willing to work with.

The technical summary on my resume is just that, a summary, not a comprehensive list. It’s 1/3 of the tech I’ve actually used throughout my career because I’m not interested in a job doing Flash or Visual Basic and I don’t want to receive anymore recruiting inquires about Magento development because I used it briefly a decade ago.

We passed on someone because the resume listed SQL, but that person couldn't answer a basic query question. This person was finishing their degree in a few months and we figured first real interview and wanted an easy question to build confidence before the interview started. The job itself wouldn't use SQL so not having it wouldn't been any negative, but claiming it and not being able to talk about it means you are a liar.

I had someone interviewing for a us a couple of years ago. It wasn't a tech role but we were very clear that if he would want, we'll transition him gradually in the next year or so+ all the support he'd need. I go through his CV and I see 2 years of experience in Java. Oh nice, but very unlikely to be truth. So I ask if he really has two years of experience. He didn't. We ended up giving him a job,but he had zero interest in transitioning into a tech position.

Great advice; I did some Scala like ten years ago and put it on my CV and linkedin. Then the recruiters kept sending me offers for a Scala job.

But... I don't know Scala anymore, I don't LIKE scala, and I don't WANT to do scala.

So it's a bit of a trade-off; on the one end, you want your CV and linkedin profile to reflect how amazing you are, how many things you know, etc. But on the other, you want it to be an invitation for people to approach and hire you for something YOU want to be doing.

I've updated my linkedin to reflect what I'm fairly good at - web front-end - because that's job guarantee, and what I want to be doing - Go - for whoever wants to take a punt on it. And I'll keep tweaking it towards what I WANT to do. I'm sure I'll keep mentioning what I've worked with in the descriptors of different jobs and projects, but I will de-emphasize the list of technologies in the summary section.

That is a bit different take on.

When you are working in a company - if you don't want to have new responsibilities you don't touch it.

You touch WiFi router - well now it is your responsibility if WiFi stops working. You touched sendmail - well as you wrote quotes "expert".

But to be specialist on something it still requires quite in depth knowledge than "you were last one to touch it".

At one company I was the expert in Crystal Reports. Right now, nobody knows I even know what Crystal Reports is.

I have noticed that when interviewing, the more specialized technical people often look down on full stack engineers, whereas managers are more excited about it.

I consider myself full stack, but in my last role I presented myself as a frontend engineer, with some backend experience. Eventually this role just kinda expanded into both frontend and backend.

Now that I do contract work, I present myself as whatever they need, with my current contract, I was hired to do frontend, but just started looking at the backend when running into some problems or questions about the data. There's always a point where they ask you "oh, you can work on the backend too?".

Specialized technical people often look down on supposed fullstack engineers because specialized technical people value mastery over familiarity -- something a lot of FS engineers really try to be exaggeratingly proud of. While familiarity with your stack is great for cross-cutting concerns, mastery is what truly builds great software, not to mention in a timely manner.

Managers are excited about FS engineers simply because if they scoop up good ones, those who really know what they're doing -- masters of several areas of their stack -- they can rotate them effectively at a fraction of a cost, if not for free.

> While familiarity with your stack is great for cross-cutting concerns, mastery is what truly builds great software, not to mention in a timely manner.

I fully disagree with that. Great software isn't just about what stack you have mastered, great software is build by people who can do whatever it takes to build great software, and that's not necessarily just about your stack.

That's funny, because as a generalist I tend to look down on single-purpose developers. Way too often they don't know anything about the rest of the system they're interfacing with and produce locally optimal but globally inferior solutions. My main gripes include frontend developers that don't understand HTTP and backend developers that don't understand SQL.

And besides, where does your notion of "full stack" begin? Is it backend application code? Operating system libraries? Kernel code? Hardware drivers? I'd argue "full stack developer" is a misnomer anyway, since no developer can (or would want to) write both kernel drivers and html/css frontends.

> since no developer can (or would want to) write both kernel drivers and html/css frontends.

You do realize this comment is going to pull the exceptions out of the woodwork?

I wrote all of the software for the first version of the Teledyne Lumenera Ethernet cameras. Everything from assembly codes in the bootloader to CSS in the on-camera web pages. Heck, I even had to review and debug the PCB design before I could start.

I don't think this is a particularly uncommon experience. Embedded development usually has very small teams, and very often the hardware has HTTP API's.

P.S. I'm available for work. Information in profile.

Heh, oops. Should have seen that coming.

Yeah, it's probably my personal bias showing. I'm fine with most parts of the stack (like you, down to PCB design), but UI/GUI/WUI work is an area that I try very hard to avoid.

I'd rather avoid UI work too. But if it's part of an otherwise very interesting project, count me in.

I dunno...that's actually my job. :) I work (mostly) doing embedded software (drivers/os/apps) but also help with some of the supporting back end web services and yeah, some of the front end code as well. It's handy for the company since I can work on whatever's most needful from week-to-week as well as take features from device to backend to production. Why would I want to? Well, I get to learn (more) new things and the scenery changes more often. It's not a bad gig if you can pull it off.

The problem in both cases is being an asshole who doesn't respect the value of other people's skills.

The main thing "wrong" with a specialist is that not every org needs a full time specialist, so specialists are more likely to need to work as consultants.

I agree with the notion that "full stack" means different things for everyone but there's a difference between a specialist and someone who only knows html/css. I've normalized relational dbs, made REST and GraphQL APIs but I specialize in making the frontend applications (web/ios/android/etc). I can wear all the hats on my side projects but they're not gonna pay me double for working the whole stack

this so much. Can't count the number of times I've been ignored after warning others about things that will happen down the line cause I don't just throw the pig over the wall to the testers and ops guys and consider the job done. I'm usually able to see problems that will pop up later down the line since I've done the code writing, and the testing, and setup the CI/CD process, all the security hardening and STIGs, and after they ignore me I tend to be the one helping them fix it.

When I interview for jobs they always ask very specialized questions. Everyone wants a generalist but refuse to interview them or pay them like one.

The idea that you can't be great at very different things isn't confined to software engineering. I think it's because most people can only master one thing so they can't imagine other people working differently

To be perfectly fair though even “mastering” backend is quite close to impossible.

You’ve probably heard of the 10,000 hour rule, it’s a hard and fast rule to say that it takes roughly 10,000 hours of doing something to fully master it.

Maybe not true in all cases; but consider the suite of tools you have to be practicing every day to do even a single role: VCS/DVCS, shell, OS fundamentals, build-systems, networking, DNS… now we have distributed computing concepts such as kubernetes and various DSLs, then there’s your programming language(s), their standard libraries, their extended contrib libraries.

Completely non-exhaustive list and we’re already closing in on 5 years working full time for each of those.

The sheer hubris of assuming you can throw together a few frameworks and understand 1 or 2 paradigms and then claim you know “the whole stack” is immature and exhausting; similar to the sysadmins of yore who could read QuickStarts and claim to know how to maintain software fully.

Delivering business value is definitely what we’re trying to do, but when it comes down to it: engineering is understanding; and nobody can claim to understand everything, not with a straight face.

Full Stack is either: the most senior you can be or the most surface level you can be.

If the former: we can’t afford you and I’m not sure how you managed to keep all your skills up to date.

If the latter then specialists will need to clean up after you anyway.

Fist, the 10,000 hour rule is false common knowledge [1,2].

Second, splitting a general role ("backend engineering") in arbitrary atomic skills doesn't make sense because there's no end to it. Backend engineering -> OS fundamentals -> Driver programming -> Hardware design -> Boolean logic -> Set theory -> and so on...

Third, all engineering roles have cross-cutting concerns. You do need some network knowledge to be a "backend guy"... but also to be a sysadmin, devops, etc.. It's not like all these roles exist in a vacuum and you're starting from 0 if you switch between them.

Finally, most people that think of themselves as experts in some role, language or framework end up in the "1 year of experience repeated 10 times" trap. True experts are also somewhat generalists too, because you can't built a tall knowledge without growing the base too (pun intended).

[1] https://www.bbc.com/future/article/20121114-gladwells-10000-...

[2] https://nesslabs.com/10000-hour-rule

10,000 hours, whether true or not, is a ballpark and even if it's patently untrue: it will always require some non-trivial amount of time to get good or master a particular subject.

Not all subjects are equal, granted.

having overlap in knowledge between roles is also somewhat granted; being a complete master in backend gives a person a lot of knowledge towards being a sysadmin (maybe even 60-70% of the way to being a master in that direction!);

But, you've failed to convince me that any single human on earth can do "everything"; even if a person could literally master all technologies in use (not counting your strawman of driver programming) then there would still be a discipline mismatch.

I'm not sure I understood the point you tried to make

Nevertheless, I have a solid understanding on all the things you mentioned and if you need help give me a holler because my rates are fair and I'm open to opportunities

> most people can only master one thing

Can they? My experience of people is that most of them can't master anything.

I think the differentiating factor, for me, if I were in a hiring position, would be that full-stack engineers are curious, flexible, and both eager and very able to learn.

Specialists, I have less experience with working with them though so take these generalizations with a big and hopefully non-insulting grain of salt. On the one hand they will be experts in their field, know whatever they work on inside-out, and can squeeze every last grain of performance out of it - good DBA's are worth their weight in gold, they can solve a company's performance problems and save them millions depending on the scale.

On the other you have a group of people that sorta know one language, like Java, and will just coast along on it for their careers; their CVs will look impressive, their skills will be indistinguishable from someone who has one year of experience. I've literally seen code that was a copy / paste of the first google search result of "java sql query", buried ten indentation levels deep, in a critical core codebase.

The reason why technical people look down on full stack engineers is because they are usually just web developers. Web development is one of the easiest and over saturated areas of software development. That is not to say web development is easy, it's just "easiest."

It's hard for a full stack engineer to see or admit to this because of bias, it's much easier for someone outside of web development to see it, or a more well rounded engineer to realize it.

Full stack isn't even the correct term for these engineers. They usually aren't truly full stack. They just "front end" and "back end", of the web development stack. AN actual "Full" stack encompasses far more. OS development, embedded development, compiler development, database development, graphics programming, are all really hard things that are missing from someone who typically refers to themselves as "full stack".

> The reason why technical people look down on full stack engineers is because they are usually just web developers.

To give some context here, yes, when people refer to full stack developers, they're usually referring to developers who are focused on web development, but that would also include API development, or even mobile development.

I don't think anyone thinks of full stack developers, as developers who know embedded development or compiler development, so I don't know anyone who looks down on them for not knowing these things.

> It's hard for a full stack engineer to see or admit to this because of bias, it's much easier for someone outside of web development to see it, or a more well rounded engineer to realize it.

Now obviously, the way that you put it, it's extremely difficult to say why you're wrong, because you've started by adding a bias to people who would defend it. So maybe, when you want to have a discussion about it, don't start by stating something that makes it extremely difficult to argue against it without being seen as having a bias.

>I don't think anyone thinks of full stack developers, as developers who know embedded development or compiler development, so I don't know anyone who looks down on them for not knowing these things.

Yes, I'm referring to technical people who are specialists outside of "web development".

>Now obviously, the way that you put it, it's extremely difficult to say why you're wrong, because you've started by adding a bias to people who would defend it. So maybe, when you want to have a discussion about it, don't start by stating something that makes it extremely difficult to argue against it without being seen as having a bias.

Why would i want to be told I'm wrong? People offer arguments in the belief that they are bullet proof so it's natural to say things that are harder to argue against.

If you're a full stack engineer this excludes you from answering because you may be biased. I can empathize with how you feel. I guess there's two things you can consider here. Consider that you are biased and that the statement is correct. Consider that I, the person who posed the statement, is biased and wait for a programmer outside of web development who has experience working with "full stack web engineers" to respond with his own opinion.

You would be biased not to consider the possibility that I am right, so strive to be unbiased.

I actually dislike the term "full stack engineers". "Full stack applicaton developers" is slightly better, at least it's limited to a single output (the app). I would not trust them with the design of an airplane, nuclear plant or military submarine, all of which are engineering tasks.

30 years ago, every app developer was "full stack", and the concept didn't even exist. As apps moved to the web during the dot-com era, the added complexity made some companies split their teams of entry level developers into front-end, back-end and database. Still, at that time, this "stack" was simple enough at the time that a good dev could learn the basics front-end, back-and and basic db work within a few years. So, a few years after dotcom, the "full stack dev" became popular, but really what they were delivering was the same as the app devs of the early 90s.

But even within software, engineering is so much more than just making web apps or RESTful microservices behind the web apps, and the field is still grown rapidly. There is data engineering, machine learning engineering, infrastructure ("devops") engineering, operating system engineering, driver engineering, network engineering, real time system engineering, algorithm/library engineering, and I probably left most of the sub-fields out.

So my main issue with "full stack engineers" is that I've met a few with (in reality) a fairly limited skillset who are quite overconfident about other aspects of software and the infra around software, who assume that the principles they follow when buildings web apps apply to all domains of software, and show a significant amount of hubris [edit] but still often failing spectacularly when trying to use their particular skillset in a somewhat different domain.

I realize that this impresson of mine is based on a few bad apples. But I think there is something in this "full stack" concept that can contribute to some devs underestimating the the kinds of work that are normally not considered part of this stack.

In my last fulltime role, we were called “product engineers”, which I actually really liked. It highlighted that our focus was on building a product, and not necessarily on frontend or backend. Because there was so much more involved, we all also helped out with deployments, or looking through log files, or talking to the business about issues.

> Now that I do contract work, I present myself as whatever they need

I realized that I should have done so for a contract work that I wasn't hired for. They told me that they were looking for someone specialized. I knew exactly that they needed a generalist, mostly because they were an early stage startup. They never hired for the “specialized” position they contacted me for, because that position shortly became obsolete.

Echo this sentiment completely. I'm the only one in my team covering both hardware designs, software development, and sales. I'm not nearly as expert in any of these areas as my colleagues, but my manager can throw pretty much anything my way and I can run with it, and as a result generally do the best in quarterly reviews. From a managers perspective, if they can hire someone who can do 3 jobs for the price of one, then that's the best return on investment. However, an expert in an area will see through that. They know a job split 3 ways is a job 1/3rd done. I can get something working to a proof-of-concept level, but not to a scalable, problem-free one (unless given more time to work on something singularly).

Best bet is to play to the crowd from my experience. Management class: tell them how much you've done. Engineering class: tell them how well you've done something.

Kubernetes Devops guy checking in - this is the way!

Also think about it from the company side:

Would you rather hire someone that solves your "exact" problem, or the one-man Army that -could- do everything? Which matters to you?

I'd rather hire someone who is effective and passionate about solving problems in a particular space. If I hire a full stack web developer, and then they burn out because I had only frontend tickets for them for half a year, that's not so nice.

I don't mind rebranding your LinkedIn to make it look like you're the Kubernetes DevOps guy, as long as that means you're totally fine with working the DevOps for my Kubernetes clusters for the foreseeable future.

In an ideal world we could shove around generalist developers to whatever is necessary at the moment, but the reality is each developer is a human with hopes and dreams and ambitions and not every role will fit those.

As a generalist, you've not only got my goat, you just took it to town and got it drunk.

This sort of over reasoning is part of what bugs me about this industry.

Many devs change jobs at the drop of a hat, turnover is already high. Yet here you are, worried about job retention, trying to second guess what a dev knows about their own happiness.

I know you mean well, both for the org, and the person, but what makes you think you know, better than the dev, what will stress them out or not?

You aren't them, so just ask, and as long as it is clear they have thought of it, and want to move ahead, you should 100% drop the matter.

Frankly (as if I could be more frank, heh), likely there will be something entirely unrelated which will bug the dev. And all your concerns will be for naught.

Except, of course, you are throwing people's resumes in the trash bin, thus reducing your talent pool, due to unfounded concerns.

Over reasoning? Because I ask a developer what they want to work on during an interview? Guess what, turnover is high when your developers are unhappy with the work they're doing. I've had developers do work that they didn't like to do, and they quit, so now I make sure they're gonna be happy where I want them.

I'm not second guessing anything, in fact my comment says the exact opposite. If a developer reworks their LinkedIn to highlight some expertise they're interested in working on, then I fully trust them on that and will gladly hire them.

I'm not sure where your whole angle of not trusting developers to know their own happiness comes from. But let me be clear, if you're a generalist with relevant experience I will definitely ask you to come over for an interview. I'm not throwing valuable resumes in the trash. But during the interview I will be frank about what the job entails, and I'll gauge your response to figure out if you'll be content. Whether I'm effective or not I don't know, but I'm going to have to at least try to get the right person at the right position.

edit: BTW I'm not just saying this as a CTO at a small startup, I'm also saying this as a generalist with highly valuable frontend skills and I pray to god I don't have to get into another frontend job (either directly, or by being lured into it after applying as a generalist).

Well, rereading your original comment again, I see the second paragraph could be taken in the way you mean in your reply.

I think paragraph 1 and 3, sandwiched around 2, created an effect of negation.

So thanks for the clarification, and thanks for returning my goat.

My pleasure brother. Hope no one will be throwing either of our resumes in the trash.

> Would you rather hire someone that solves your "exact" problem, or the one-man Army that -could- do everything?

I tend to contract to the guy who can solve my exact problem. Because if the problem can be solved I don't want to pay for headcount permanently. I tend to hire long-term the guy who can solve multiple problems, but less speedily.

Which, of course, is different if you mean "hire someone who solves a class of recurring problems I have with a specialized skillset" from "solve the exact problem"

I'm a generalist and I've had a bunch of DevOps jobs where I had to come in to fix what the complete mess the kubernetes devops specialist left behind.

I think the question is more who a generalist markets to. Some people have multiple resume's depending on what they apply for, they come in through one angle and then build some trust and take over more. Or it's a startup that needs help, but doesn't really know what they need help with.

The fundamental mistake is that people think that just because someone is specialized on a topic he's also good at it.

I happen to think that "DevOps" is one of those fields that really require some kind of generalist to do well, from the hardware (and virtual hardware) level and a fairly deep understanding of networking to how to build and optimize the kinds of apps and services that will run in the infra.

Many get the title "DevOps" who are basically Ops people with a new toolkit. One of the problems with the DevOps stack, though, as working in the infra-as-code needs a dev mentality to be done right. Many traditional ops people will "program" the infra-as-code using pretty bad quality code. (often using way too much cut&paste for stuff that could be generalized.)

On the other hand, when devs switch to "devops" they often fail to have the attention to detail and sense of responsibility found with many traditional ops people.

So finding good candidates for DevOps roles is really hard, and often those positions are staffed with people who are not really suited for the paradigm.

Absolutely true, but those are two different things.

I -AM- a generalist and it's also a requirment for being actually any good in devops, but I position myself as Freelance Sr. Engineer with Kubernetes / DevOps / Golang Focus, because thats what I like doing and also what I am good at.

There is a whole longtail of skills that are required to do any of this, also quite a few that are not even tech related, like proper communication or empathy.

But yeah, if you require assitance, I am definitly the kubernetes-dude that you can call and it should be as simple as that.

> Would you rather hire someone that solves your "exact" problem, or the one-man Army that -could- do everything? Which matters to you?

Well . . . people always assume they have the answers, so they've designed an exact position to do what they think they need.

But if they need it and can't fulfill the need themselves, they probably don't know what they need.

The company, composed of vain people, is more likely to hire someone that solves their "exact" not-really-problem.

In my opinion it's okay to not be able to pinpoint the exact problem, thats what I tried to imply by using the quotations.

This is why I position myself as Consultant and Engineer, because you will know you have a problem with your cluster, and I should know how to solve it.

When you are at the point, where your question is: "I need someone to fix my internal ingress-controller because traefik binds all services to the public one", you might simply need to open an issue with the developers of traefik.

Yet if your problem is: "we would like to completly separate internal traffic from external traffic inside our own datacenter", you are looking for the kubernetes devops guy with the neccesairy experience.

We Share a similar Point and we hide it in a similar way.

I also hide my Excel skills extremely well, they are to be deployed only on emergencies.

Nowhere in my CV does it say that I know PHP, so when I fixed a bug in an old PHP app my boss was quite impressed at how fast I got it fixed until I explained that I knew PHP, but I kept it secret because I didn't like working with it. He laughed and said next time he'd try to find someone else to work on the app.

Don't use "full stack engineer", these days for recruiters and HR it means "knows Node.js and React", which is sad and frustrating.

My Ask HN post about it: https://news.ycombinator.com/item?id=32317514

But I like React and Node.js. It works fine for me.

I never said they're bad. I'm saying that not very long ago, full stack means from system security, administration, being proficient with databases, backend and frontend development, and at least a couple languages under the belt.

These days it just means frontend and backend, in the same language, often the same framework.

The same term that was used to identify senior generalist engineers with extensive experience in the field, these days is used for any junior JS dev with a couple years of experience under their belt. Not their fault, it's the recruiters fault for appropriating the incorrect label instead of creating a new one.

npm i nextjs … or whatever. Basically.

Centering a div == specialist /s

Excellent advice!

Heck no I regret nothing.

I can program anything, bring me your dead and I will raise it.

Specializing, that's called a job. Work is work and they have a stack you gotta use, better or worse.

No one can take the hacker out of the hacker though.

My resume in terms of languages basically goes back in time, where I'm "expert" of what I use every day, but what I haven't used for a while I just put "good".

How do you sell yourself as a specialist to a company with a stack? Simple, "I don't know X but I'm keen to learn. I'm sure I can scale up to it". If they pass on you, it wasn't meant to be. As a job, your job is to return higher value than your cost. If you do that within a team, you're a net positive. Whether it's by teaching what you know as an expert, of coming up and scaling up to help wherever you can.

Either way, there are very few stacks that are permanent enough that you could be an expert in the matter for decades. Things simply move too fast.

So get behind any shiny new stack that you fancy and become a subject expert, it might pay the bills in 5 years. If not, you probably learnt transferable skills. At the end of the day, no matter the language, stack, team, we're just all trying to get the computer to do X.

> ... If not, you probably learnt transferable skills.

Actually, I like to think that I focus primarily on the "transferable skills" part, with languages being secondary. Many patterns, algorithms and data structures are quite general from language to language, while they can be quite specific to a problem domain.

Once you know 10-20 languages, learning another is usually tivial, even though learning most libraries, style guides, etc requries some more effort. Properly learning the ideas are harder, but also more rewarding.

Many devs will use structures like HashMaps based on heuristics or cookbook approach. But when you're able to see the similarities and differences between HashMaps within microservices in k8s, hash joins in a RDBMS or broadcast cash joins in Spark, and you understand the strengths, weaknesses and compromizes of each, you have a type of understanding that almost certainly will be useful in whatever langauge is popular 20-30 years from now.

The counterpoint to this is the C developer who promises they can scale up to C++ and then takes a disproportionate amount of review time to be taught not to use malloc/free/new/delete/etc.

This is why I say I can do any language but C/C++. It’s a skill I’m sure I could build, but it’s not going to be pretty at first.

Educate me, pkease: why no new or delete? Does C++ now discourage heap allocation or is the common practice to use smart pointers, etc.?

Constructing into a unique_ptr[1] will mean you don't have to risk forgetting to delete it or risk managing something you don't own. You'll also sometimes get compiler spew that you'll learn is telling you you're trying to do something nonsensical e.g. use its copy ctor. In contrast, if you try to copy a raw pointer that is intended to be unique then you get a copy of a pointer and a Heisenbug.

Also a lot can be done with things that are on the heap but act as local variables.

[1] You probably don't actually need a shared_ptr and if you do then it won't stop you from creating memory leaks.

Yep. In new code you should use smart pointers for allocation as much as you can.

This. This is exactly how I feel. Instead of waiting for work, I can find work and get dangerous quickly anywhere. Try me.

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyse a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

You're quoting someone — you should use quote marks and add an attribution.

We are not at school.

Should is a banned word

Why is that? Is it against english grammar or something?

The world is full of ‘should’s but most of them are just constructs.

- Robert Heinlein

Thank you for that. Please ignore me and vote parent up.

https://www.goodreads.com/quotes/12051-a-human-being-should-...

All that and now I have to learn k8s! Grrrrrr!

A popular quote among those who believe they're on its good side, but also specialization is the basis of our entire society and economy. All of software is a specialty. The most successful people are neither 100% specialist nor 100% generalist. "T-shaped" is the common term - at least slightly competent across many skill areas, very deep in a few. A team or larger organization made up of people with complementary skills (and temperaments) will consistently outperform one where everyone came out of the same cookie cutter.

BTW that's not the worst way Heinlein misled half of my nerd generation, but that's a topic for a different day and certainly a better venue.

Thank you for making me laugh on my more than crappy day :)

> plan an invasion

Why would one need this ? [hahahaha]

I actually, for real, have a slide deck about starting an empire. I did it as a joke for my friends, it's formatted and phrased as a startup pitch deck, but an invasion is required for one of the milestones. So you never know!

> Take over a small country

Should be on every todo list.

> Why would one need this?

You'll see! :) (seriously though, even if you are not planning any invasions in the foreseeable future, you need to think like an attacker to successfully defend against attackers).

If you're not invading because you can't, you're not good: you're just useless.

You need to be able to invade and not do it to be good.

What if you know you /can/ learn how to do that but make a conscious choice not to take on that ability? Then what if you know you can but rank that ability as being too far down the list in terms of its benefit to you, your family, your neighbors and the human race to supplant time spent learning X or doing Y. For whatever you feel are a good values of X & Y?

This more "not invading AND you can't" rather than "because." Seems like a reasonable thing to me.

"I decline to shoot anyone with a gun and I can't." That seems like a position taken by some large number of pretty reasonable people in a many contexts that seem, at the very least, justifiable.

Fair enough :)

The day you decide to play Crusader Kings 3 or a grand strategy game.

It requires some lateral thinking to figure out how can your dynasty conquer the entire British island, subduing the Scots, the Norwegian, the Saxons while being at war with France and you're just a lowly Irish duke with a crippled heir.

On the flip side, that’s a 50-year old quote and maybe times have changed?

What do you think of HN's cstross take in his novel _Saturn's Children_ ?

> Please excuse my lack of depth; I'm a generalist, not a specialist.

> Why bother learning all that biochemistry stuff --- or how to design a building, or conn a boat, or balance accounts, or solve equations, or comfort the dying --- when you can get other people to do all that for you in exchange for a blow job?

(to me, it seems to be more a blow job specialist's view than that of an actual generalist, but ...)

Have humans really changed in the last 2000 years? You can still find books today published back during Roman times complaining about kids these days and how they mispronounce latin.

We have changed in some important ways in the last 20 years, and are yet the same in other ways as our nearest primates today and therefore probably our ancestors 2 million years ago.

When we all have smartphones with access to WolframAlpha, do we need to know how to solve equations ourselves, or is it sufficient to just know how to phrase the problem so the software can answer it? Even excluding vegetarians and vegans, who even has access to hogs to butcher them — and given food delivery options, how many need to bother even if they can?

Why 2000?

Mispronounced in Latin: "emm an' emm years"

https://australian.museum/learn/science/human-evolution/homo...

I’d add:

  - write an effective contract and be able to tell if one that someone hands you is reasonable
  - be able to explain to people you feel some responsibility towards how to install and operate a VPN
  - have a grip on basic statistics and economics
  - cook a tasty meal from grains, legumes, vegetables and/or fungi

Vegeterian?

Not necessarily. Just to be able to.

Fair enough, nowadays you're probably better off writing a non-rhyming poem as opposed to a sonnet (at least if you're trying to be trendy). However I think a lot of the other skills are attainable and even worthwhile.

I don’t know know if anything has changed but sometimes it feels like most people today can’t do a single one of those things. Maybe it was always an unrealistic expectation, though.

Maybe the specifics have changed but I'd argue the general sentiment remains valid. And at least half of those specifics still apply.

It's more relevant than ever.

You can replace some parts of it, but the core message is timeless.

"A human being should be mediocre at everything"

Great advice there.

"Jack of all trades, master of none, is oftentimes better than master of one."

An average human to have an average life must know how to cook food, do arithmetic, read a book, write a letter, use a computer, learn a trade. Even living a primitive life, a human to survive needs to know and do more than any other animal. This is why we have our own enormous and very energy-intensive brains and not a shared hive mind. Being average is what we excel at as a species.

love that: specialization is for insects.

Generalists may always have a job in software, but specialists often have the interesting jobs. Everyone starts out as a generalist. Like you, I am always interested in vastly more things than I have time to properly grok.

Whether or not to be a generalist is a question of ambition and also where you are in your career. Life outcomes for generalists cluster around the median, outcomes for specialists have much higher variance. The idea of "t-shaped skills"[0] is valid and often excellent generic advice for optimizing career outcomes but it is not the right advice for everyone. I made a very intentional decision to ignore my polymath instincts and focus on just a few strategic areas when I was ~30 and it made a very noticeable difference in terms of the opportunities available to me.

It is difficult to know what you want to specialize in without generalizing first. True mastery of a domain typically requires considerable amounts of personal interest and focus, so it needs to be something you enjoy or you are unlikely to be competitive against those who do enjoy it.

An alternative, if a single specialization feels too limiting, is skill stacking i.e. specializing in two or three skills. This has more potential but requires more work. There may be only a few people in the world that can operate at the intersection of those specializations -- it can be very rewarding depending on what those specializations are. Complementary specializations can be synergistic.

Don't discount specialization happening accidentally by virtue of how your career evolves. I have a useful deep specialization that I never intended which is strictly an artifact of a truly random path dependency, not personal interest. Nonetheless, it is immensely valuable to me now because it complements other specializations I have so I maintain it.

Don't worry about it. If something is worth going deep in, you won't need anyone to tell you.

[0] https://en.wikipedia.org/wiki/T-shaped_skills

I disagree with your premise. As a generalist, I have held some pretty interesting jobs over the past almost 20 years. What you know isn't what matters. How you decide to leverage your knowledge is where you make a difference.

As a generalist, I found the ability to zoom out to the bigger picture and connect dots to be invaluable. More then anything else, learning to communicate is paramount.

That doesn't detract from what a specialist with deep technical expertise does. I know some who are great communicators as well. It's just that discussions happen on a different plane.

Can fixing random companies' problems can be interesting? -- a specialist

Well, I do think it is more challenging to reach the highest individual contributor pay grades as a generalist. On the other hand, being the one person in the org that understands how all the pieces play together and can debug all up and down the stack brings a lot of value and is eventually recognized. I now work in robotics, and being able to chase bugs through mechanical, sensor behavior, electrical, firmware, drivers, software, across ethernet, CAN bus, config files, calibration extrinsics, closed loop controllers... etc.... being that kind of bug hunter is valued and has worked out well for me. I feel zero age discrimination in my role, despite needing 7 bits to hold my age.

Lucky you! I started having problems after I overflowed 5 bits, the upgrade to 6 bits hasn't been much help.

Not at all. I made a career of being a generalist, then freelancing, then I learned I have ADHD.

Makes sense to me now. Working on the same technology for more than a few months and I get terribly bored. So I keep learning new stuff and staying entertained and motivated. The more I learn, the more I am valuable to my clients.

Most companies don't need a hammer. They have all sorts of problems and need someone to fix them. One day it's the Ruby backend, the other it's the database server. How quickly can you learn, adapt and create value? And for that rare and very specific problem, you call the world-class specialist for two billable weeks. The remaining 50 weeks of the year, they need you and your expertise.

Don't forget that software engineering keeps becoming wider, more complicated and accelerating. You have to keep apace with it, or you'll find you're a fantastic expert at a JS library that nobody has been using for the past 5 years, which is archaeologic in software terms. It's exhausting, but if you stop staying abreast of technology, catching up becomes increasingly difficult.

I can provide perspective from both sides of the table, to add to the wonderful comments already posted.

The first few years in my career were a will-do-anything attitude. So yes, like the OP, I did a bunch of different things. A few years in, I harbored similar thoughts of feeling inadequate. A jack-of-all-trades-but-master-of-none. Especially, since I was at Google and was surrounded by the best of the best and experts/specialists in anything you could name.

My next stint was at an early stage startup (<10 employees). This is when I started to realize that this "weakness" may actually be a strength. You could point me to a wide array of things and I could run with it. I could take the principles from one stack/language/system and use them in another.

Now, as a founder, my favorite hires are generalists. Engineers who have a wide breadth of experience, a do-whatever-it-takes mindset, and ideally, a sprinkling of product/business sense. They are the first-principles thinkers. They can handle ambiguity and change without batting an eye. They will figure when/where you need a specialist.

Be proud of being a generalist.

It gives me hope. I am on same position as OP. However, I have decided to sell my soul to Graphics. I mean literally and figuratively. I see there are only few people who can do graphics compared to other field. It is quite a niche to work in graphics!

Are you currently hiring? I've just hit 30 as a generalist and the job markets are a mess... Would be happy to connect in case you need a hand with any projects.

Nope.

Mid thirties and being a generalist means that not only am I employable, my breadth of experience allows me to bring together things from places others would be unaware of.

I occasionally wish i was more of a specialist, but usually chalk it up to the sort of all pervading impostor syndrome that goes on in software development circles.

If someone wants to put me in a position based on my current skills where I end up becoming an expert and they pay for that time, then it will happen. Otherwise I'll just keep learning enough to be useful in dozens of smaller ways. From the browser's JS engine event handling at the bottom of Flux/Redux to how Kubernetes works and how to do useful stuff with it, to 3D printer firmware and how my drill press works.

I don't regret it at all. I have a generic CS education and it allowed me to work on a very broad range of topics in every kind of company. I have an average level of knowledge in every OS, framework, and programming language and it helps a lot when it comes to getting hired everywhere, quickly get some knowledge in a new project, and helping my "specialized" coworkers when they are stuck.

But I'm also not stuck in this generic mindset. I'm good at C++ because I like it more, that's my freedom and my choice. And after one or two years in a company, I kind of become a specialist myself on what I'm working on.

The secret is to always learn new stuff. I have 20 years of experience and I'm still reading books to learn (C++20, Rust, etc.) I've seen way too many coworkers who were stuck for the past ten years in a boring job or a dead technology and could not get out of it, it's very sad. When we meet for lunch, I always have funny stories to tell about "my new company." Yes, my previous coworkers have stable jobs but the salary is not good, they have no raise, and if their company closes for good, they will have a very hard time adapting and finding a new job (because it's most likely they only worked for one company their whole life). They always come back to me for advice on what to learn, what to do, and how to find a new job. Last but not least, their knowledge is tied to their own company and is not transferable.

What seems to be fragile is actually a power: I can quickly learn AND adapt, and I can switch companies without being unemployed if the management becomes crazy or if a company is stalling and/or on the verge of closing due to lack of money.

For me, being a specialist is interesting because you know one subject deeply, but it can become soul crushing, you'll have a hard time switching jobs, and you seldom learn new stuff. The best example I've seen all these years is C++: when you work for a company, you use THE specific C++ of the company and most of the time the "tech leads" refuse to change and, again, you're stuck in that specific version which does not teach you anything.

Looking around me (BigCorp), the people that managers value the most are the generalists. Teams are built around these key persons, and extra care is taken to make them comfortable.

The reason? You can throw any problem at these people, and they will solve it without asking for a dedicated DNS guy, an extra front-ender or an LDAP guy. They can foresee obstacles and point out pitfalls around any technology. Not because they're experts in that specific tech field, but because they can generalise. If they say it's hard, management knows it's really hard. If they say it's stupid, management knows it's really stupid.

I never regretted anything. There were days when I felt the appeal of the prospect of knowing one single thing/tech really, really well, but for starters I met a bunch of those guys and they're really hard to work with. As soon as something happens outside their comfort zone ("I've never seen this before – what's a proxy?") they need help. Plus it's a risky approach – what if that tech becomes obsolete? There are a lot of old cobol developers out there that are more or less unemployable (at least as cobol developers).

Well put.

And it’s ok to have broad knowledge. Remember the “T”. Go deep on what interests you that way and keep your mind open.

Generalists do well in other career streams like product management, sales consulting, where broad range of knowledge needed so don’t fret. You are at the start of your career so make the most of the time to explore, try, learn, and yes maybe fail a few times, and you will more than likely find your niche(or it will find you).

Best wishes for a long and interesting career!

Yes and no. No, because I think being a generalist has allowed me to offer value and insights that set me apart from others. I like knowing a bit about everything and I think my willingness to learn and explore has worked out really well.

On the flipside, before I moved to my current company, I did struggle with promotions at times because I wasn’t seen as a specialist in any one area. The overall value that I saw in being a generalist and that others used to their advantage wasn’t rewarded the same way as it was for peers who were focused on just one thing.

So I don’t regret it and I do think there is real value in being a generalist. But be prepared to have to work harder to show that value to others.

This has been my experience as well. I have a lot of context on a lot of different things and projects I have been (or still am) involved in. I've been allocated by managers to partner teams to help, I've jumped on a lot of different projects (all super interesting) and that allowed me to build a very diverse portfolio of skills (and more importantly, improve on my ability to "get up to speed" with completely new codebases and projects, which is something a lot of people don't have).

My manager knows that if there's some new project brewing or some specific thing that needs someone to look at, he'll likely ask me to take a look. I enjoy being that "jolly" player in the team when it comes to this stuff, however there are a lot of downsides to it. I've doubted myself a lot (and still do) with impostor syndrome when I see my coworkers do super amazing very technically detailed stuff that I just simply cannot understand. See them whip out extremely specific nuggets of knowledge and very technical reports on stuff that flies waaaay over my head. They are absolute geniuses whereas I feel like I'm just here to "fill a gap" and not much more (I know that's not REALLY it but... the voice at the back of my head tells me otherwise). I've had times in my career where I asked myself "what did I do the last few months?" and the answer was "I have no idea" because I'd be flipflopping around writing a few line changes here and there, not having a codebase that I'd specifically "own" myself, etc. It can be emotionally tough at times.

Still, I enjoy it.

Rarely, but yes. Some people simply can't grasp that if you say "Yes, I've done this for 5 years and I've done that for 5 years" that you will indeed be able to fulfill both roles, even if you're maybe not able to give answers that are 100% correct in the details and up to absolute latest standard, but can easily get back into it. (Not fundamentals, just actually "yes, I worked with X, but 3 major versions ago")

This is generally not a problem and many people are actually happy to get someone who has not just seen 15 years of one thing.

The T-shaped thing is a bit of a meme, but I do believe you shouldn't be a complete generalist and not be quite good at some things, so I guess the depth of your one or few specializations is up for debate.

But in summary I don't regret it. I don't want to call it "easily bored" but I can really not imagine myself as still doing the exact same thing as 2001, when I started working, even with the technologies that were around at the time. Sure, even there things change (looking at you, Java and PHP) but still. The only thing I don't recommend is hopping from language to language every 2-3 years, that's simply not enough time to go deep enough.

I used to be a typical full-stack SWE but I specialized in AI about 8 years ago, even getting a PhD. I would be making significantly less being a generalist. That's not just true for AI, but the same for fields like security, systems engineering, databases, and so on. The highest paid technical positions are typically looking for specialists. An exception are early-stage startups. Those often need generalists, but that's a slightly different tradeoff since you're paid in equity, not cash. You don't care about promotions in an early-stage startup.

If you love AI, go for it, but from purely a career perspective it's probably not something I'd recommend. The market seems so oversaturated these days since everyone and their mom is interested in AI because of the hype. By the time you're done "specializing" the market will look very different. Again, not a problem if you're truly passionate about it, but don't do it just for career opportunities.

YES! :-(

I'm in my 60's. Have worked as a contractor in effectively every field of IT and taught post-grad SE courses at university. I still program in C, Javascript and Python. Can design, build and configure data centers. Know most variants of Unix and its progeny, etc, etc.

Yet ... I'm finding it very hard to get contract work post COVID. Recruiters are looking for 3-5 years experience with specific products. I demonstrably can learn fast and most of IT is old wine in new bottles with fancy labels. But that doesn't meet expectations.

If you seek intrinsic motivators, then being a generalist satisfies curiosity and yearning for knowledge. If you seek optimum employability and high salaries then being a specialist is the key. BUT a lucrative specialization now, will probably be of little value in 5-10 years time.

I can't tell, but I suspect this is more likely a problem of ageism rather than generalism here.

But maybe beyond a certain age you need to specialise simply in order to compete for positions.

Most employers are going to choose a younger more pliable (or cheaper) hire over someone who knows the same stuff but due to lived experience is less tolerant to bullshit.

Ageism could be a factor, but no recruiter will ever say it point blank. As for becoming BS intolerant, I see that with my cohort who are still working in IT.

Looking back at my work experience, becoming a generalist happened by being serially a specialist.

It's also possible that it's because parent is looking for contract work, not fulltime W2 work.

sorry to hear that. do you think ageism have something to do with it or no? (generalist in my early 40's here similar skillset sprinkled with cloud stuff)

I'm in my late 30s and no. I enjoy working with early stage companies and starting my own companies, and being a generalist is essentially necessary in those situations. If you do this as a specialist, you'll end up wearing many hats anyway just out of resource constraints.

Being a generalist also, IMO, makes you a more effective manager for crossfunctional teams, and gives you empathetic understanding on how the sausage gets made across the board, instead of just in a single domain.

But as others have stated, you can be both a skills/technology generalist while also framing yourself as a specialist. As I alluded to with my personal history, I consider and frame myself to be a startup specialist due to my broader base of skills.

Currently 35, started CS degree at 17.

I've thought about some of this recently, and while I don't regret being able to jump through the tech stack, or even do a sales call or set up a marketing funnel, there are definitely a few issues that come to mind.

1) If you jump tech stacks you're going to have to spend time getting to know the layout of the neighbourhood. Avoiding jumping across ecosystems will save you time in the long run.

2) You may never truly reach your full potential of really knowing a language if you're constantly jumping back and fourth between many.

3) Some employers will try to pigeonhole you and not take into account your broad array of knowledge (resulting in a lower offer). This may just mean that they're not the right people for you though.

4) Technology is constantly evolving, so you will become out-of-date with technologies you no longer use or use infrequently.

On the flip side:

* You can gain respect of your team and become a "go-to person" for helping them solve their array of issues. This can help give you leverage within a company (e.g. deciding to work part time)

* Having a broad skillset is perfect for starting a company if you are entrepreneurially minded.

* You'll gain mad problem solving skills.

If I were to offer one bit of advice:

Pick one tech stack and be a generalist within that tech stack - and don't let job listings dictate what you will spend your life working on / learning. Choose your work strategically.

Same age range although I started programming in my late 20’s. I have been letting job listings dictate what I learn. I should stop but don’t know what to focus on.

Anyways, your comment resonated with me and I appreciate it.

The more different things anyone does over time, the more you become a generalist.

It reminds me of a quote where an expert is someone who knows more and more about less and less. That seems true for specialists and generalists.

Generalists can connect dots between unrelated that specialists might not.

Generalists can build and connect many layers.

The chasing of shiny objects slows down once you start seeing how little is actually new.

Serving the solving of problems that make a positive impact for users is important to know what generalists can do that’s very unique. This helps inform what you might want to go deep in vs broad.

For me it was the realization that most software tends to answer one question in many ways: Where is everything at? It became the connector to people and what they were after.

Also during the pandemic, it seemed generalists were able to learn how to learn and contribute some very unique solutions.

The subsequent change in society will require not just specialists who focus on one thing or way.

Generalists roll with the change at both as big picture and in details.

You need both and I don’t think the specialist is better than the generalist, or vice versa.

No. Being a generalist is awesome. I get to follow wherever my interests lead and I'm interested in a lot of things. I don't know what I would do with myself if I had to focus on one narrow piece of it for years on end.

What I do regret is not being better at marketing and sales. It has been difficult to find work at times because I don't fit neatly into an employable box.

No, it makes me more valuable to startups.

I’m a 0 to 10 engineer, 10 to 50 is rough, 50 to 90 is boring and 90 to 100 is like watching paint dry for me. If you want to be valuable for the startups that need 0 to 50, you need to wear some different hats.

You also need to know yourself. Figure out what you love in this and do that, you’ll never be burned out or bored. When I’m in the right place, I can happily code all night, do 2 Months of work in a day. When I hate my job, I struggle to create anything, it all feels like work.

> When I’m in the right place, I can happily code all night, do 2 Months of work in a day.

I know what you mean, but I'd be cautious making such statements. The other way to read this is that when you're in the right place you do one day of work in a day, and when you're in the wrong place, you do 1/40 of a day's work in a day...

Meh. I think the people who hire at early stage startups understand this statement perfectly, and my work and references speak for themselves.

i am very cautious making statements about "a day's work" because i've seen a lot of devs that seem to be doing two days of work every day, the whole time.

but they did not think enough, so a vast ammount of their "work" was waste anyway and discussing it also wasted other ppls time.

I think this is an important point. Generalists are more valuable at smaller companies where everyone has to perform multiple roles. I'm not sure where that stops being true though. I've been in a few startups now and at the 50-100 person mark, I think specialisation starts to become more important.

I don't know if I'm a generalist or more someone who's simply curious and not intimidated to get stuck into stuff I have zero knowledge of.

I seem to have acquired a fairly diverse set of technical skills compared to most devs which has it's advantages, but at the same time I know at times it can make it hard to explain to employers what I do and how I can be useful to them. Sometimes this leads to me being underutilised, and in my opinion under appreciated. It can also make interviews difficult because employers like you to talk about relevant experience where my experience is all over the place.

I personally think my skill set is awesome though. I tend to be the perfect candidate for smaller companies where technical specialisation isn't feasible. Need someone to do some some UI/UX design, frontend development, backend development, devops, AI, SEO, QA? I can help. I've worked with almost every major language at some point in my career and while I'm not great at every language, I'm familiar enough that I can get whatever needs doing done.

I do try to keep my frontend development skills current enough that I can call myself a frontend dev when needed. Generally for contracting or when applying for positions in larger companies this is my best route. When I'm in the door sometimes I can branch out a little, but it depends on the company. I do worry I might fall behind at some point due to my lack of focus, but honestly I think people who specialise too much fall into that trap more often. If the technology you specialise in becomes redundant, then so do you. Having a broad set of skills gives you a technical safety net because there is always something else you can fall back on, even if that comes at the cost of fitting less perfectly into any specific role.

So no, I don't regret it and I think it's actually an advantage if you can sell it correctly. Learn as much as you can in my opinion. There are definitely companies out there which really want great generalists who can just get stuff done.

I too am a generalist and have been for 30 years. I love it all but the one thing I wouldn't do is react UI coding. It just looks awful to work on. I loved Vue2 but Vue3 is starting to look like react.

Professionally kind of – as some other posters mentioned, it's harder to reach higher pay grades. Some of my peers work very little and earn pretty well with their specializations (though some others ended up with so much responsibility that they work a lot and can't spend much time with other topics).

Personally it's great, I can quickly build models to improve complex decisions, e.g., by defining things as an optimization problem, building small simulations etc. And I can dive into many topics because I've worked on the basic components of many things.

Also I can quickly prototype whole solutions end-to-end. This helps understand what's missing and how to build a roadmap.

Right now I work as a product manager, though it would be great to find something where I could actually use my problem solving skills more and create more value by modelling complex systems.

Being a generalist certainly makes cocktail parties more interesting. Being a little good at everything makes you more employable as well, you don't get locked into 1 niche. The T-shaped person is the ideal. You should be great at 1 thing and decent at many other things, but always keep the T-shape. Keep an identity to center your varied experiences around. It will keep the main thing and the auxiliary things interesting in tandem.

Specialists are much more interesting to talk to than generalists because I find that usually "generalist" means "someone who knows everything at a surface level", whereas specialists tend to have deep domain knowledge.

Why is T-shaped ideal? I’ve heard this before but it seems arbitrary. What about “W” or “U” or pick your favorite letter?

It takes a long time to get truly skilled in something. What we call an expert is really what a reasonably intelligent person can be expected to learn about a single topic within a lifetime. The gains in one area compound on themself. Given that these gains compound, you can't learn 2 things half as well. So the T-shape represents the constraint that you only have a shot at becoming an expert at 1 thing. Spend 80% of your time on that and 20% on the rest.

The Pareto principle (80/20 rule) also implies that you only need to read a handful of books on a single subject to know more about it than most people. The knowledge gains become marginal unless you focus most of your time on it. So the things that you find interesting that aren't your main thing, just "learn the ropes" and move on back to your area of expertise. That's the most efficient traversal of the Sum of Human Knowledge: Familiarize yourself with the lay of the land, then focus most of your energy on some place that hasn't been mapped yet.

This is a complex topic!

> you only need to read a handful of books on a single subject to know more about it than most people.

It's easier than that! Just reading (in full) the Wikipedia article about something you probably makes you more knowledgeable than 90% of the general population. Reading a whole book about it -- maybe 99%.

No, from the perspective that it has allowed me to take on interesting projects that were otherwise impossible. In my case, by linking tools from different fields (spectroscopy, computer vision, chemistry, medicine, human systems hacking, ...) and getting something viable together. Once we demonstrate viability and need, we then build a team of specialists to flesh out the details.

Yes, in that that you have to sell yourself carefully. "I solve any problem" is not generally reassuring, because it is always an approximation, and because a specialist might see the pitfalls of a particular approach earlier. Given time you will become a specialist in whatever tool, but that needs to be built into projects or your professional development budget.

No. The demands for specialized roles shift from epoch to epoch, but being smart on negotiation, strategy, sales, marketing, and communication will never go away.

In my experience, the generalist end up running things, and the specialists end up forever ICs or on narrow specialized projects.

The one area generalist tend to fall down is ending up as the fix-it person. Moving from one fire to the next, building up a lot of system specific knowledge that isn't transferable. Don't end up the fix-it person.

Find the highest value capability and build it simply. Then do that again. The simply part is super important if you're always interested in 10 things at once. And always trying to code yourself out of a job.

If you want to do AI, just do a couple side projects with it.

Up until college I thought I would make a great astronaut, but only for the drama of it. Got an English degree. Learned web design. Got a music composition degree. Got my first job in web design because I didn't have the stomach to grind it out for a composition job. Self taught (via the web and the library) on software development, agile, patterns, graphic design, web standards, XML, XHTML, CSS, XPath, XSL, accessibility, JavaScript, PHP, Perl, Java, Mac, Linux (Gentoo! emerge FTW!), WordPress, MySQL (it's "My Ess Cue Ell", btw), screencasting (remember that? Thanks, Camtasia), more architecture, Ruby on Rails (hallelujah, best decision I ever made), PostgreSQL, temporary small business owner, Node.js, cloud, Christopher Alexander, Solution Architecture, Product Management, way too many business and organizational books, Elixir/Phoenix, Common Lisp, and what's next? I still write and play music for fun. I write what feels like endless amounts of communication and essays for work (thank you, Department of Rhetoric). I'm a thought jumper. Always have been. Blessing and a curse, as they say.

Do I envy those who were able to specialize and find fortune, keep their sanity, and look good doing it? Absolutely there are days that I do. But regret being a generalist? Honestly, I think I would go crazy if I tried to force myself to be anything other than.

You specialized in web development. You're a specialist.

You also mostly specialized in software.

> Do you regret being a generalist?

No. Not at all. I just know one programming language pretty well and I just do one kind specific that is weirdly broad. Full Stack web application with a scraping/automation backend. It is like Fullstack Web + Data Engineering (or, DE with a hat)

I call myself general-purpose Python developer. I can fit anywhere but I don't want to do programming full time at the moment.

I am working in a developer relations (DevRel) role for a Data As A Service company for the past couple of months, I have honestly never been happier. Being a generalist programmer helps, and being a generalist sideproject-hacker-type works even better for this role.

> Have you been one in the past and then changed?

Thinking through, I guess, I changed my position from being a generalist to a marketing role.

But I am happy. I want to be in this position indefinitely. Being a freelance generalist programmer for more than 5 years, I think being generalist doesn't hurt, but finding your place in a stable position is difficult. Everyone needs a freelance generalist not a in-house generalist.

> In that case what do you prefer?

Generalist Programming + Marketing. 50/50.

Communicating to people (both technical and non-technical) about a technical product seems to be my life's calling.

> Do you regret it?

Absolutely not. Best thing that is ever happened to me.

Yes and no. The pros: it is a lot of fun. You get to know a lot of people, because you are involved in many topics. Also you have a deep understanding of things other cannot start to comprehend even what they are missing. The best is, when you are seasoned (I'm in my middle 40s) you do not have anxiety about finding a new job. I've done HW (from chip design to module design), analog and digital, and SW (from assembler up to Lisp), front-end, back-end, database admin (Oracle), networking (Cisco certified) you name it... If I want to find a job, I do it, like fast. The cons: some interesting jobs require you being absolute expert. For example, I applied recently for a senior ASIC digital design position. Even when I can write Verilog and VHDL, I am by no stretch of the imagination a senior expert. I worked with that for 3 years or so... so I did not get the job. OTOH: I think I would get bored being an expert, looking only one tree the whole time, instead of the woods. I will be able to give a final yes/no answer when I retire... until now, is 50/50.

I'm also in my early 20s. I'm personally aiming for being very good at a few things with a lot of very high level background knowledge. Basically an extreme T-shape.

1) I believe that not having a clear competency will make it harder for people to place you. Your experience is a lot more legible if you're the "React guy", "C guy", "AI guy", etc.

2) Trying a bit of everything is very different from being good at everything. Is "a bit of x" useful? From what I've seen, no. It's not a unique differentiator, it's easily replicable and it doesn't provide much value. Being good at a few different things seems like a different ballgame though.

3) If you are a very broad generalist it will close a lot of doors for particular work. If you are highly specialized it will close a lot of doors for particular work as well. AI/ML for instance, seems like the kind of field that will be closed to you unless you specialize in it. On the other hand, building full products is something that seems more inaccessible to specialists.

I used to call myself a full-stack engineer. This worked a decade ago since I was earlier in my career and worked at places where implementing feature end-to-end from design, frontend to backend was standard practice. However there was a turning point a few years ago when I started to have real problems finding companies that still want to hire generalists. I'm not sure if that's just my bad luck or places like that just dried up.

In theory all companies like adaptable people. In practice I find most job descriptions prefer specialists nowadays. Coding interviews and job posting requirements are also very targeted to a specific skillset. Looking back it'd be a better choice to pick a specialization for up-to 4 years and retrain myself every now and then to paradigm/framework/language-du-jour rather than being proficient in everything and a master of none. As a specialist I'm more marketable, have a better workday/quality of life and fit better into teams that need a particular skillset.

I don't think an area such as AI can be called a specialist area. There is simply too much breadth once you start getting into the nitty gritty of building an AI product. If your goal is to be a well versed product builder in AI, then you need to master software engineering, building deep learning models, training on large clusters, deploying on the edge - man it's a lot.

A data scientist or a deep learning engineer - yes that's somewhat of a specialist role. It again depends on what you want to accomplish. If your goal is to research deeply in one area such as NLP then yes that's a specialist role.

OR,

If your focus is purely on infra, like building and enhancing Pytorch or Tensorflow, yes that's specialist knowledge in fine tuning a loss function etc or building a new loss function altogether.

As far as I am concerned, yes I do sometimes wish that I had stuck to one breadth area such as AI or mobile app development or AR/VR instead of somewhat dabbling across all these areas. No regrets though.

I actually regret being a specialist.

For the past couple years, I focused on my Python and Django skills but now I can't find any decent work for these technologies since every Python work now moved to AI and Machine Learning.

I wish I had continued building PHP and Wordpress stuff as well as dig into new fields like machine learning. I also started in tech as a penetration tester but forgot about everything I learned while focusing on Django development.

Being a specialist is also boring and makes you stupid. You're like an ostrich with its head buried in the sand. When I started digging into new technologies, I realized how much I didn't know and how far the world has moved on.

Lately, I've been remedying this situation by learning new programming languages, reading more books, and attempting projects to test my new skills.

Never specializing ever again.

I think your employment issue is somewhere else. It is not true that all python development switched domains. E.g. you cannot replace your web back-end with AI. And there are many companies which use python for other domains. It is one of the most popular programming languages.

Web development has moved on to Javascript with a few Ruby on Rails stuff popping up from time to time. React is where the money's at these days.

I don't see Python being used for web much. Neither do I see generic programming being done with it because most companies have moved to Golang for that.

Python is popular for sure but specializing in it was a big mistake on my part. Pretty much every company will have a few internal projects in Python and that's why many of them list Python in their job description. It's also easy to pickup which means that almost everyone will know a little Python.

If I had generalized, my Python skills wouldn't be as good as they are today but my wallet wouldn't be as empty either. Just my 2 cents.

You should be motivated by what you want to do, not by some sense that the industry opportunities lie this way or that.

Software development is so incredibly hard that you must be motivated in order to do it well.

The best way to be motivated is to be working on stuff you enjoy.

Not at all! Every time I think I might’ve doubted it I’m blessed to be able to continue generalizing out of whatever specialized corner my career seems to head towards, and to continue to be effective doing meaningful work.

Context: I'm a consultant, in that I work for a company that does product and technology development for others (Cambridge Consultants, in the UK). I'm a generalist embedded software engineer by background, although I studied electronics. These days I mostly lead technical teams that include SW, FPGA, Electronics and Mechanics.

Not having a specialism is occasionally annoying. It makes my 'career path' less clear, I don't have anything particular to write down as my USP to clients.

In practice though these have been minor. My value has usually been that I understood all aspects of the system including cross domain. This meant that there were bugs that I could diagnose and fix easily that other people had no idea about (using an oscilloscope to diagnose software bugs is a useful skill).

As I became more senior and started running teams it became even more valuable because I understood what all the different disciplines were talking about and dealing with. It's a great advantage to architecting, planning and prioritising (some of this has been learning as we go along - I now know a fair amount about injection moulding despite being a SW engineer because I keep asking the mechies questions).

As other people have said, often it's about framing your skillset. Previously I have highlighted a relevant aspect of my experience as a specialism when talking to clients. These days I say "I am an expert in leading multi-disciplinary teams for product development".

I'm usually jealous of a specialist for about 6 months to a year. Eventually I learn enough about what they do to lose interest and become jealous of a new specialist.

Same here. I’ll learn just enough about something to have a general overview of how it works (which may or may not be in some depth) and lose interest.

Interesting ... so have you stayed a generalist or picked a field to specialize in?

No generic answer to this but one way to think about it is over the long term would you value more depth (expert in something) or breadth (freedom to explore everything)?

If you value depth, specialize. In an industry (e.g security, healthcare, finance, etc.) or field (AI, distributed systems, scaling, etc.) You'll get intellectual satisfaction, emotional satisfaction if you intrinsically care about the space (e.g healthcare), and financial upside since people value specialization.

If you value breadth and wandering, generalize. You'll still get intellectual satisfaction from knowing a variety of things, emotional satisfaction from working on things you care w/o any industry constraints, and financial upside since generalists are valuable to startups and even though their failure rate is high, being in the right company at the right time could give you the same financial upside you'd get from say being at a large company in a specialized field.

I personally chose to speciailize because I value depth and find diving deep into a field more meaningful. I know many generalists with the same amount of experience who are doing equally well and I would hire them and value them in the same way if I built a company again.

Every two or three years I find myself with the need of carefully planning my next steps, so that my generalist pattern does not disrupt the advancement of my career according to the criteria of my environment, this is very tough at particular moments because sometimes you have less time available to work on your broad base and on the development of specific skills that are needed for some of its corners, but I still don't regret it.

I view myself as a generalist and have looked for jobs accordingly but I've found that specialists tend to be skeptical that anybody can be a generalist or that somebody who has done low level C for a few years since college could be capable of branching out into something else. I also have lots of interests other than writing code and those interests have been more intense in recent years because those things always ebb and flow for me. When it comes to jobs, as long as its remote, the pay's reasonable and there's no unreasonable working conditions or anything particularly objectionable about what the code is used for, I'm fine with doing just about anything (I do prefer working on some things over others, of course).

Regardless of the difficulties you face being a generalist, I couldn't imagine ever being a specialist. Doing the same thing over and over again is boring and feels like a waste of potential. But the modern world is built around specialists who are supposed to outsource their thinking on everything outside of their specific specialty to somebody else who specializes in that area or summarizes the opinions of the people they consider experts in the area.

I’ve worked with the most brilliant guy who was tremendously autistic (lives at home with parents at 30) He was a specialist. He couldn’t understand the big things but boy could he do the small things.

This very much held him back and he even said ‘treat me like a robot as I can’t put together complexities’

So, generally speaking, we are generalists. Your job my force you down a specialism and I have seen many many miserable (well paid) SAP HR consultants

My favorite part about being a generalist is that I get to work with incredibly talented specialists and we tend to complement each other very well.

In some ways I find that I _do_ specialize - just not along a specific field. I tend to specialize to the project. 8-10 years ago, I was building a video rendering project. I got to build the engine prototype (in an early version of node.js!), the UI (early version of react!), the data formats, the databases, the video / audio processing systems, and so on. And when we proved it all worked, we brought on specialists to help improve the UIs and optimize the rendering engine.

At the end of that run, I knew more than I would ever want to know about video file management, video rendering, generating video formats, etc. And once that startup sold, I was able to move on and let all that knowledge sort of fade.

I'm presently "specializing" in a project where we scrape POI data from around the world and combine it in useful ways for locals and travelers. So now I'm working with geo data, reasonably large data sets, merging data from thousands of sources, and I get to dabble in / and learn about ML, while the specialists do the more detailed, more difficult ML work.

That said, I've found it's good to be better than average at some things to keep busy. For me, besides general coding, I'm decent at API-based software architecture, Ops, and planning / maintaining / optimizing Relational Databases.

As for the work - Most projects need both. Someone else on this post mentioned that there can be higher pay for specialists. That's probably true. I've seen it. But generalists can have more stability as industry trends adjust.

Why not both? You've got a long career in front of you. I started out a straight software dev, stumbled into being a "DevOps" expert before the term existed, ran a team for while, and am now sliding into "architecture."

Being a "generalist" means that you are going to pick up a ton of varied skills. Eventually, you'll find out that one of them is something that no one else has and your current team/project is in desperate need of. Congratulations, you are now the "expert!" If it is something you like (or, in my case, was simply angry didn't exist), double down and keep pursuing it. Now you are the "specialist." If you get bored, step sideways into something else.

There are places where you really do need to stop and specialize- for example, there are parts of AI are in fact hard to get into without lots of specialized experience, but much of that seems to come from Academia which at least has a clear path to gaining the experience and credentials. Even then, there are ways to side-step into it- my current team is a data science team, where I am the voice of software and infrastructure engineering reason. There is a fairly clear path picking up more and more data science or AI tasks if I wanted to, eventually doing that full time instead of what I'm doing now.

I've found a lot of success and happiness by focusing on problems that I'm convinced need solving rather than technologies or categories. Sometimes that means I go months without coding (that does make me a little sad), but it is very fulfilling to see my positive change for the better come to light. It also has driven me to pick up all sorts of skills and technologies that 23-year-old me never would have thought I would, let alone enjoy!

A perspective from the other side: I definitely don't regret specializing rather early on in my career.

Doing a little bit of everything early on is great, and in fact is required to figure what you're good at and what you enjoy, both important factors in choosing what to specialize in.

But going deep into one specific craft to the point where I could confidently assert that I was one of the best in the world at the craft has been an extremely fulfilling experience. Deep expertise is also something that peers will naturally look up to and respect, and can unlock the highest tiers of compensation a lot faster than breadth alone.

I've been forcing myself to branch out ever since deciding to start my own startup, but the focus on gaining deep expertise in a single craft early in my career is what eventually allowed me to contain imposter syndrome and gain the confidence needed to start this new journey.

I actually do. When i was younger and junior in software i scoffed at people i know that specialized in getting really good at one perticular software.

Today i look at them with envy when they are experts in one particular thing, like Microsoft AD or Sql-server or sharepoint.

It pays very very well something i never understood how and why companies would pay that much for specialized knowledge.

In my 15 years of experience the true happiness comes from the ability to choose what you want to do and avoid things you don't. So if you in the place there you can specialize early in your carrier and know what you want to do - go for it.

But in my case I never had this chance in my first ~5-10 years in the IT. I lived in 3rd world country with like 3 IT company in the town. So I had to be generalist.

Right now while I'm still capable of doing more or less everything, I have my 'standards' of jobs I'm willing to do. For example I don't do frontend, not because I can't, but because I prefer to not do it. So basically right now I have a set of things I enjoy and I try to make sure I work on them. Probably I would be in a much better position if I could specialize in more complex fields (in terms of career opportunities), but at least I have enough experience to have some options I like.

For me, becoming a generalist has been driven by broad curiosity across many schools of thought – not limited to just software nor even technology. I can't even imagine a world where I would have been content specializing.

One upside that hasn't been mentioned, is that not not specializing leaves more room for serendipity. I could not have followed many opportunities that have popped had I not been willing to start again as a novice.

The only, but big, downside has been that I had to quit my post-grad studies and the academia. Just the thought of pursuing a single avenue for a minimum of four years is unbearable.

Related to the above, I've also had to come to terms that I won't be one of the best in the world at anything (easily) measurable. It hasn't been easy to accept, but at the same time I've also begun to appreciate collaboration much more than competition. I believe it's also a healthier approach to life in general.

My modus operandi is to observe everything going on around me and slowly acquire an encyclopedic knowledge of my environment. That's the one thing I'm really good at, and how I market myself is by telling stories about how I've jumped in to an unfamiliar field, learned about it, and made an impact.

I'm similar to you; equally enjoy reading about and trying all sorts of things. I moved into engineering leadership (my job title has the word "Architect" in it, but don't hold it against me) to allow me to use my general above-average understanding of a lot of things to help guide how and what my company builds and runs software.

If that sounds good to you, keep generalising. But you'll need to dedicate a few years to a few different areas to start becoming the sort of deep generalist companies are interested in. I variously did web dev, enterprise application integration, AppSec, and microservices-based backend build and design, and after I did them and moved on to the next thing I kept up with the reading on each past topic as best I could.

I don’t. And generalist is a flexible term. For my career it means frontend, or backend, team lead, or IC. There have been a few points where I thought “I don’t ever want to write browser code again” and “all I want to do is UI”. I’ve built shopping carts, government tax websites, worked in automotive, and now I build tools to manage robots. I suspect if I had been narrow in my field I wouldn’t have had the opportunities that I’ve enjoyed.

I sometimes think a narrower, deep specialization might have yielded a bigger paycheck, but overall I think I’m happier being able to explore broader fields and concepts.

As a final note I’ll say that you’ve got plenty of time to generalize and then decide to specialize. Bring in your early twenties is far more time than it feels like right now.

To me, being a generalist means having the ability to pivot from one specialty to another, as the market changes. I made a few early "bets" in my career: Linux (foundational), C++ (foundational), OpenGL (specialist). Obviously, the choice to specialize in OpenGL didn't stand the test of time, but I had a solid foundation of Linux / C++ to build upon. When I started working for a company that combined C++ and OpenGL with GPS/mapping software, I was able to pivot into GPS and mapping, which carried me through the rest of my career.

If I instead doubled down and tried to become the world's foremost expert in a (now mostly) dead technology, my career probably would have turned out differently.

Somewhat opposing view here. I'm not a generalist and haven't spent much time trying to be one, outside of some freelance work where I just said "sure, I can definitely build that" to whatever the ask was.

Specialisation lets you spend time looking into computer science research instead of into solving today's business or tech stack problem. I don't know how to handle dependencies in npm or the details of what changes across python releases. I have read a lot of papers and spend a lot of time experimenting.

I remember being concerned around one of the job moves that I was becoming very specialised and may struggle to find work outside of my area. That's definitely a hazard but I figure I'll deal with that by retiring.

Isn't being a generalist what you should do on the way to becoming a domain expert?

My generation (definitely older given the replies :~) ) was sold straight onto the specialization dope. I think that smack is what's screwed the planet.

I recognized the (very, top schools) hard sell for bunkum at a very tender age. The flip side is that you don't actually become a expert much before middle age. That's also how it should be, but my second and third decades of my career were very lonely. If I would beg any sympathy for my generation's reprehensible stewardship, this might be it if I could ask without being self serving. As stands, over to you lot. Look back hard at the events in history just now being declassified. For the first time in the information era newly released history is not only relevant but crucial, because the generation born fifty and sixty years ago still living, and able to talk with you, was isolated almost entirely if not hermetically, from the rest of mankind and are, albeit well concealed by superficial wealth, personal or circumstantial to society, shitting ourselves when not freaking out angrily.

Personally I think the freaking out behaviour has been copied by the headless right rather than is actually endemic, but understanding social mimicry in traumatic stress is just another example of how much you have to figure out and filter out, similarly to plotting a course to high professional status just as any independent thinking, and the state of many professions today is that attaining independent thought is a de facto domain expert qualification.

Traumatic mimicry could be easily applied to the reinventing the DBMS from discovery of ACID (early MySQL, 00's; MongoDB, 10's) , the Russian Dolls rewriting of Windows display layers, and potentially almost any project recently enabled by putatively inexpensive compute.

Of course I'm hinting that philosophy and other non technology understanding can make being a generalist both much easier and more pleasurable, but this is a personal journey, find your reasoning where you can but remember that you're a generalist.

I'm the opposite (in a way). I started my career as a front-end dev about 10-12 years ago, over the years the tech landscape in front-end has changed so much and I was so busy keeping up with it that I never prioritised learning backend or other technologies.

If I had a chance to start all over again, I would have definitely looked to be more of a generalist as I feel it gives you more flexibility, perspective/context, and (ofc) improves your skill set.

I definitely regret that now (in my early/mid 30s). But hey, never too late, I've started learning backend and microservices and while I know a lot more now than a few years ago, I'm craving for some experience of taking things to production.

Being a generalist is a meta specialization of sorts. Some people are good at assembly of pieces - almost every CTO/Architect I have admired would be considered a generalist. Such person can obtain enough knowledge to have input and be productive and doing it across concerns is pretty epic skill.

Preferably engineers I like working with are T shaped. So they are generalists to a degree they can fill in but they have their own domain where their expertise is gathered. Its way easier for me to say "its just like the ... X" and if people have some rough understanding of X we can move on. If they don't we gonna have a week of explaining/understanding whats X.

Being a generalist is a lower risk strategy than being a specialist from a portfolio management perspective, i.e. investing how you spend your time.

If you specialize in something and it stops being relevant you might have little marketable skills to contribute. This would be like putting all the eggs in the same basket.

If you are a generalist you are protected from such a scenario since you put the eggs in several baskets.

But as a generalist you might be missing specialist opportunities so, of course, it's a bit of a tradeoff.

In this sense, it can be rational to be a generalist. However, every person's experience is unique so it's hard to say that one thing is better than the other without further context.

You trade the knowledge of how the things work (and consequently gain an ability to diagnose and fix things what all other specialized guys couldn't solve) for a solod pay cut. There are minuscule chance to have a 10x pay upgrade once a year.

In my experience the T-shaped approach that others have mentioned is a good one for the long term. Become an expert in one thing you enjoy but keep being usefully employable in most areas.

I'm naturally a generalist, I enjoy every and all parts of creating network/computer/OS/userspace systems, their performance, operation and security. But I've also specialized in some areas. As I get older (about double your age) I have held very high level generalist roles, but those start to become few and far between up the corporate ladder. In my more specialized role, very senior opportunities are more common since not so many people seem to specialize.

I see lots of happy generalists here. How do you find a job though? I've rarely seen a job ad looking for generalists. All job posts look for something engineer. When you're not something engineer, how do you find a suitable job?

The same as everyone else really...

The trick is though to tailor your CV for the position you're applying for.

I'll research everything I can about the company and the people interviewing me, I'll look up common interview questions for the technology they use and spend WAY more time on any coding exercises than what they suggest making sure that it's well structured, tested and easy to extend in the follow up in-person interview.

If it's a tech I haven't used much of, I'll be honest about it and they'll generally be impressed that I know as much as I do even though I'm new to the tech.

My advice is if you specialize, make sure you specialize in a technology that is used in a wide variety of industries. I went specialized in a very narrow industry that was retracting and on its downslope. I decided to coast that hill to the bottom thinking by the time I got there I’d be done and ready to retire. Low and behold, there was a steeper drop off at the end of the hill and the industry is basically dead 7 years sooner than I expected.

You don’t want to put yourself in the position as the last telegraph operator when you need another 7 years left to fill your nest egg.

No. The only thing I regret along my career path is being officially diagnosed with a mental illness during a hospitalization, which led me to missing work without notice, which caused me to become abruptly unemployed (and, eventually, unemployable). And despite the fact that my career ended abruptly and without warning, I regret nothing else. There is no downside to learning new things, even if they don't have immediate application to your life. Even if they never do. Learning is worthwhile for its own sake (at least in my opinion).

I am curious about this. Are you a software engineer? Is it your condition that has prevented you from finding employment, or the stigma? Or a gap in your resume?

I used to be a DevOps. My difficulty in finding employment results from a combination of my illness's symptoms and the (now ever increasing) gap in my resume.

Fullstack 20+ years of xp here :

There's a great deal of fun to be able to understand a system from top to bottom. It helps design robust and elegant solutions.

Yet, i do sometimes regret not having gone super deep in a field. However to me that would have meant do a Phd in that field and start a career as a researcher. If you stay at the "assembler" level (aka not inventing anything, just putting stuff together), then you'll have plenty of time to become good in multiple fields during your career.

I’m a generalist and have no regrets, as I’m too ADHD to specialize and do one specific thing to the point of mastery.

On the upside, I credit my current role (head of marketing) to the fact that I kinda sorta understand every aspect of what my team works on, including my developer, designer, and content team.

On the downside, I’m pretty sure I’d have an easier time and make more money if I just did one thing better than everyone else.

I comfort myself by believing the thing I specialize in is having a wider breadth of knowledge and experience than most.

What you should probably looking for is a T shape knowledge in topics; know some of the things really well (leg of the T) and know a lot of things somewhat (head of the T). It's head or leg can be narrower or wider (knowing less things, but more deeply, or knowing more things less deeply), but it should probably be a T-shape.

When I send my CV for a specific company, I delete unrelevant parts for the role and add my experience related to the field of the company, so basically every company get a unique CV of mine.

Mid-30s and no regrets so far after roughly 12 years of experience. I've done mobile development (Symbian, yes that Symbian, iOS and Android) backend (nodejs, erlang, PHP, python) data engineering and probably a host of other things that don't spring to mind immediately. That being said, I've mostly been working in startups (the longest being the current stint of nearly 8 years now from early employee to IPO) and generalists are generally really well appreciated in those settings.

Yes and no,I have done frontends, backends, cloud, devops, ux, project/program/product management, sales , product development,I helped one startup to grow from 0 to 100 and another startup from 0 to acquisition and made good money, but from a job perspective the only option to progress in my career is to start something of my own, I can't find a company who needs a person like me, so generalist is a good path if you want to start your own but specialisation is better for job growth

> Do you regret being a generalist?

Not for a moment and I'm closing in on 40. It's fun and you can absolutely take some time to play with AI and dedicate as much attention as you want to it and no more.

I was curious about this area as well and took a dive for a bit. I've learned things I already applied to infra autoscaling and some support apps for medical clinics. It's been enough for me at that point, but there's also nothing stopping me playing with it further in the future.

Think about the breadth of your experience with perspective of where you want to land. You sound like a person that likes learning and applying SW tech. That is great for a generalist role or a maybe a CTO of a varied SW tech stack. Is that trajectory where you want to land? If you want to be in a role where you need to be responsible for multi-disciplinary stacks, you don't sound like a generalist. For SW, you do. I hope your experiences line you up for the role you want.

As a company founder, that's exactly the profiles I'm hunting when starting a new business. However, based on my previous experiences, the company won't hire this kind of profiles when the business scales, and you could get bored sooner vs later. Your company can even ask you to specialized yourself. I feel like your profile is perfect for early-stage, but you will be an eternal "unsatisfied" employee when the company grows

I'm almost in the same situation as you, also being an AI-curious SWE in his early twenties.

No regrets so far. Building stuff is more fun when you're able to handle every step. Despite that, I will most likely specialize in the future. I've found that back-end development is the most rewarding choice for me. That will be a few years down the road, as I'm in college and focusing on breadth seems like a better strategy.

No regrets here at all.

The best work I've done in my career has been at the intersection of two or three different areas that I've explored.

I see new skills and technologies as having a network effect with each other. I hoard them. Then every now and then I'll spot an opportunity to combine eg GitHub Actions and Playwright and Tesseract.js to do something really cool that I couldn't have done without prior experience in all three.

I don't regret it at all, but finding high paying roles can be a little more difficult. Its a tradeoff though, because after a few years at a role its often seen how valuable you actually are so in bad economic times you may be the last to get cut.

I also think generalists get pushed into management at a higher frequency. Not something I am personally interested in, but I get asked yearly at least at every role I have been at.

I’ve noticed some of the best experts in their field started out as generalists (e.g., Edward Witten).

My theory is that exploring a wide range of interests and areas allows you to come up with novel ideas that a strict specialist would not think of. I believe there was some research at one point on how Nobel prize winners in science have a significantly greater variety of hobbies than the average person.

Professionally speaking, if you're not an academic researcher, I think "specializing" is mostly synonymous with pigeonholing yourself into a worse job market.

Also, this might be more controversial but I don't believe in "interesting fields". In the industry, the interesting part comes from the ambition / novelty / stakes / impact of what is being undertaken.

I"m actually in much the same situation (young SWE, generalist, interested in AI), and I find it's really beneficial especially in a startup space. My resume can seem all over the place, but I find that startups tend to prefer someone who has demonstrated the ability to learn quickly and deeply.

I've been looking for others to talk about it with, so I'd be happy to discuss further.

Hell no!

I can raise a cluster of servers, create CI & CD pipelines, write ansible, configure the databases, write stored procs, write all the apis & the front end.

I don't need 5 other people to help me do any of that.

However, when working on a team, I can help whenever I'm needed and relieve bottle necks in the team I lead, and let the specialists do the more advanced things I can't do.

The work tradeoff is usually framed as specialists are somewhat better paid, but it's harder to find jobs, and you're often restricted to fewer employers and specific locations. The other part is the specialty might find itself irrelevant, whereas if you can code your way out of a box in a top-5 language, lots of companies will be interested in you.

I'm mid thirties, went from full stack dev to DevOps to sre. No real regrets on not specializing in a field, however I do wish I had spent more time contributing to some specific open source project that's heavily used. I think generalist knowledge + in depth knowledge of some widely used codebase would be a bit more lucrative.

I guess there are arguments for both sides, but to me DevOps is specialized. "Full Stack" is more general development.

Being a generalist is awesome and I don’t regret it at all. That being said, you can pick a few things to specialize in too. You have to figure out what you enjoy doing to decide what would be good to specialize in and then it may take a year or two to learn what you need to get roles in that niche.

I'm a generalist that also knows business and UX. It does cut me off from some jobs, and I am fine with that, I would probably get bored by those jobs anyway. Follow your interests where they may take you. The IT industry is vast and needs all sorts of people, might as well go with what makes you happy.

I don't

Easier to find jobs, and you're less likely to feel underpaid.

If you're standing at the very top of a niche theres nothing for you besides looking down on everyone else. Its a lot of responsibility. You might get a few good gigs here and there but it doesn't really yield too much long time imo

generalist 4everrrrr

I pretend to be a polymath and sometimes pass myself off as a failed inventor. I have worked as an artist, extraction metallurgist, software developer, electronics designer/manufacturer and now have done a course in machine learning. I struggle to complete projects but never give up.

A generalist technologist has a lot of uses. I successfuløy employ myself as a generalist technologist and let Subject matter expert or coders take over when we go deeper into these territories.

Follow your passion for technology it almost cannot go wrong if you learn by being passionate and work in tech.

Become a DevSecOps engineer. Your skills set are in demand because you understand all three important areas

I don't, not yet at least. Frameworks come and go. Specializing is commitment that things don't change, or at least that they change organically enough that your skills can be reapplied.

I'm a software developer, I make computer programs, not "Use $framework in $language".

Step 1. Be a generalist

Step 2. Find job requiring specialization

Step 3. Write resume to make it look like you're a specialist

Step 4. Profit.

There will periodically be times when the corporate sector doesn’t know what to do with you, and not hire you

but its better to be able to build anything you want

other people need 6-figures of capital just to hire a developer or two

you are the developer capital and just need 3-figures for everything else spent on Fiverr

Being a generalist means you're not very good at anything in particular. Hard to build a career on that. Find a career path that leads somewhere you want to end up, orient your learning, focus, work toward that end.

When you acheive generalist mastery you'll be very skilled. You'll work circles around almost anyone. Happiness will be in your hands. (but some angry apprentices will want to kill you, be careful.)

Having exposure to a wide variety of environments makes you far more valuable. Making gears gave me a whole new perspective on the world of manufacturing. If there's something new to learn, why not go for it?

Nope. It lets me identify the most high risk situations for my employer and work on them in order, so that I get to work on really valuable things, in my way on my schedule.

Why do you have no doubts about your employability? When I was in my early twenties I felt pretty much the same way, but then the rest of my twenties proved different

you call yourself a generalist because you're proud of your accomplishments or because you actually think you have greater breadth than the average X human?

can you weld?

You sound like a curious person. Keep following the curiosity and what you like (authentically). Everything else is second guessing.

Specialization allows you to engage on a deeper level with the subject which in itself can be a very rewarding experience.

Nope.

I'm in my 40s, and have held jobs as a Disneyland stage performer, nonprofit manager, bar manager, US Army officer commanding tanks, doing machine learning development for a hedge fund, ground processing algorithms for spy satellite collections, CI/CD orchestration services for a platform provider serving hundreds of geointelligence developer groups, and have spent most of the past decade working the infrastructure layer for various Air Force software factories, currently being employed by a vendor of Kubernetes cluster management software.

I've got degrees in biology, philosophy, applied mathematics, finance, public policy, computer science, and information security.

I've competed at various levels in cross-country running, track and field, volleyball, basketball, soccer, have through-hiked roughly a quarter of the Pacific Crest Trail, have open-water swam over 5k, and currently lift weights 6 days a week.

This is just me. I absolutely love to learn, to be exposed to things I've never done before, to show rapid improvement in something. As soon as I get too specialized and familiar, I get bored. I'm sure I just threw up a bunch of red flags to HR and engineering manager types concerned that if they hire me, I'll just leave, but the reality is over half the people they hire are going to leave in the next year anyway. Maybe I'm earning a bit less than someone who specialized in some obscure lucrative sub-field of software development that happened to take off in the past decade, but I'm still earning more than 95% of all Americans, more than I ever reasonably expected given my family background, I'm healthy and attractive, have a beautiful wife in a loving, fulfilling marriage, get to live in a time of peace and prosperity in which I can work from home at whatever hours I please, it's sunny and warm nearly every day. I'm as blessed as a person has ever been.

On top of that, I know a ton, have a passing familiarity with nearly any topic, have met and talked to people from every imaginable walk of life. I've got a broad perspective that keeps me out of the pits of despair and solipsism you see people falling into when their impression of the world outside of their tiny little corner of specialization comes entirely from news headlines. Having tried so many things and not being the absolute best at them, seeing the challenges they present and that the people doing them do, in fact, know what they're doing, I don't have the expert scope creep you see from so many engineers who believe everyone else doing anything else is stupid and all problems would be solved if we just put engineers in charge of everything.

Hell no, I don't regret it.

yes and no. I really enjoy what I do and the skillets I have make me very flexible when it comes to solving all kinds of problems. But finding a job that values you as a generalist and pays well and interviews you like a generalist has been near impossible for me.

It’s hard to overstate just how useful having a holistic view of the entire development process is.

What would you lose by specializing? Some skill will always be first on the list.

you'll make more money as a specialist. that being said as a generalist i make a lot of money too. dont over think it. pick whatever keeps you curious because the only wrong choice is to stoo exploring

Tl;dr - Yes.

Reply on news.ycombinator.com