back
101 comments
Sadly true, and it is influencing the tech scene as we know it a lot.

While before, you would be a generalist first, specialist second - now it is demanded you are specialist first, generalist second, especially since programming is perceived as this "super hard thing" to learn that most people figure it impossible to know more than a few things at once. While developers understand it isn't, people recruiting them believe such stuff and are thus propagating the myths when hiring (outside a fistful of quality companies).

And this kind of thinking has influenced the dev scene a lot - I've met hundreds of developers that have no idea what goes on on backend, yet are deep in their frontend career and vice versa. And no, I'm not talking about somebody not knowing the latest framework, but about people declining to learn even some basic stuff like SQL, shell scripting or deployment due to "its not my area" thing.

As someone who spent a good part of their career in mobile, but also wrote a lot of frontends and backends, CMS's, dozens of tools, parsers, languages et al., it is hard to find a role that fits - either they want only the specialisation and then give me a silo of "you only work in this role and that's it" or even if they want a "fullstack developer" which means they are looking for years of experience in specific frontend and backend tooling (TS/Node mostly).

It's becoming quite absurd - on one side, we are paying high salaries to adults that we task with breaking down highly complex processes and building the solutions to problems, but on the other side, we do not believe these people can understand a bit different syntax or tooling.

Absurd.

It is the commodification of skillsets. Companies don't care about training good people anymore. Someone who will require a month to get up to speed on some tool is now a non-starter, to the point that recruiters will often recruit nobody month after month rather than hire someone will simply need a few weeks of training. If you don't tick every little box, you are seen as a risk.

1980s: "Hey, we know you can weld steel but we need you to weald aluminum. We will partner you with one of our guys for a month before you hit the production line. He'll teach you what you need."

2024: "Your resume lacks the following keywords: Aluminum. We are shutting down the production line until we find sufficient trained staff."

I confirm that it's happening in France too. I have been a generalist for 20 years, but I will need to find a new job soon due to the standard layoffs of January. The multi-billion dollars company I worked for obviously needs more money.

I worked on every technology ever, from C++70s to C++23, all languages (from assembly to Rust ant TypeScript), all operating systems, all topics from web sites to embedded programming, but my new resume will be different this time. I MUST say that I'm the best programmer for backends and compiled languages (C++/C#/Java/etc.), and that I also can do everything else if needed. I don't expect HR or recruiters to read the details of my resume anymore, I must describe myself as a 100x developer on the "compiled/backend" topic in the summary, or I may lose jobs.

From what you wrote I feel my fairly milquetoast opinion is now contrarian. I always thought being a generalist is actually harder than being a specialist. In many specialties there's the luxury of being able to encapsulate lower order knowledge that would be table stakes to a generalist and they're still perceived as competent so long as their specialty remains relevant and informed. For a generalist to appear competent they must not only dabble in all things frontend, backend, systems, and data stores but also know how all of these things can possibly connect or overlap.

It always seemed odd to me that someone specializes in a language like Java or Javascript. That, to me, is neither a specialist or a generalist; I'm not actually sure what to call it.

Anecdotally, this perspective is more common amongst early stage companies, non-tech firms, small and low-quality tech firms. It is entirely plausible to spend a career between such shops repeating the same activities over and over again. For example, wordpress developers for SMBs can command hefty fees.

If everyone you ever worked with was an X developer, why would you believe that someone could be an (X,Y,Z,A-C,E-F) engineer?

Likely, this divide motivates a persistent separation of groups - when I last interviewed for such a shop,they were stuck on me having professional experience in C/CPP/Java/Rust/Go/Python/Ruby/Perl/PhP. We ended up spending 30 minutes discussing what my strongest language was which likely told them nothing about my skills and experience nor did it tell me anything about the types of challenges they have.

It also doesn't help the training pipeline silos people like this in colleges with certain prescribed course requirements or closing off certain classes to nonmajors. We already force people to take english/second language/cultural/physical education credits to "round them out" according to the liberal arts philosophy. Might as well modernize this and require people to take some units of programming as well as statistics (although statistics unfortunately suffers from having too much boring/high school rehash/not that useful fundamentals to cover before you can get into the sort of testing you'd do on the job as a data scientist).
It's probably also worth noting that most job ads are not 100% honest with the requirements for the role, and often feel more like a wishlist for the 'ideal' candidate rather than a set of concrete requirements. Heck, I've had at least a few companies and recruiters come back after I said I didn't feel I was right for the role due to not having [particular skill/language listed in the description] and say that it wasn't actually necessary after all.

Well, at least that's often the case for permanent roles. For contractor ones it's likely a lot more about finding the person who can fix their problem immediately, and hence the requirements would be more accurate.

In Switzerland it's very common that if a hedge fund / financial company wants to hire a specific person from abroad(so he would need a permit) then they post a job ad that basically uniquely identifies that person's skillset, post it on glassdoor or jobs.ch or other, and then either get no response or filter people who think this is an actual opening.

They then go to the immigration authority and say "Look, we cannot fill this position on the local market, we need to look abroad" and then miraculously just the right candidate shows up.

Not sure how frequent it is in other countries, but if you see a ridiculous/incoherent job ad from a smaller company, it might be for a job that's already filled.

I agree in general but don't fully trust recruiters who say you should go ahead anyway - it will depend on your previous experience with that recruiter.
My old boss was looking to hire some more people for entry level positions. He had me review his write up before he posted it. For some background, at this time I had been at the job for over 10 years. I started at the bottom and worked my way up to the top and then out of that team. I did nearly every job at some point and worked all the shifts to know the different jobs on those different shifts. I wrote 90% of the docs, I defined a significant number of the processes, I wrote all the tools, wrote all the training, interviewed countless people for jobs on the team at all levels, and personally trained dozens of them (across the country and globe). I was also told I had carte blanche to speak for the VP and the team, and could basically do whatever I wanted. I was very qualified to be on the team by pretty much any measure. In many ways I defined what the team was and how it worked at that point in time.

Reading the job description, I had no idea what it was asking for or talking about, felt under qualified for the job, and wouldn’t have applied. I didn’t think I knew anything it was asking for. I told my boss this and he ran with it anyway. I’d encourage anyone to read the job posting for any open positions on your team to see how disconnected from reality they are.

You’d think that experience would make me take other postings less seriously, as the level of BS was off the charts, but I still have trouble applying for anything where I can’t check off almost every box.

This is an interesting problem.

Our company is outputting specific role responsibilities based on process mapping and resource sizing. And we are looking into using AI to write job descriptions. But is it ultimately going to be a recruiting problem if we show the exact breakdown of a role on a job description? How does that differ from role to role?

I've had a lot of trouble with hiring lately due to being a generalist. I've spent 10 years as a developer but not more than 2-3 at a time in a specific "stack." This has hurt me more times than I can remember.

However, I've built amazing things for amazing companies when I do get jobs. I've architected and built end-to-end products by myself and within teams. A few projects I've worked on: a web scraping product, data labeling software for machine learning, commercial eyetracking software, a custom learning management system, machine learning models from scratch, high volume image processing, etc. In each of these projects too I did end-to-end work. Development, deployment, infrastructure, ops.

Each one of these products though was with a different stack. JS, C#, Clojure, C++, Java, Python, the list goes on.

Common feedback I've received is that I'm not experienced enough to deliver in a role. Anecdotally, engineers that I talk to where I'm located have spent their entire careers using only JS, building Next.js sites or whatever the current hotness is. Not that there's anything wrong with that, but it does seem like the landscape has shifted to the specialists.

I don't have trouble, but companies are very leery of hiring someone who is VERY wide and only somewhat deep. Being I'm a director-level hire, many companies assume I have only led teams that do this work and I'm trying to take credit for their depth in specialized areas, not realizing that I absolutely can and do operate across that wide swath of expertise.

I try to use the successes I have cultivated at multiple organizations in the past with this experience as evidence, but even after hire, most organizations take ~6 months to realize I'm not too good to be true; it's part of why I end up getting promoted a few times in relatively rapid succession at each gig.

I find that working at smaller companies (~125), they idealize those who can wear many hats, whereas companies that are large enterprises do not and are much less likely to hire someone who can do it all, favoring--instead--those who are very deep and narrow. I have carved out a successful niche in the digital marketing space with the experience and success I've had and I will likely continue to do so, helping those same large enterprises who would likely pass me over for a FTE role, but happy to hire me via a consulting firm to solve the very same problems while paying much more for the pleasure.

This is true for all hiring of experienced people.

If a company is after an experienced person then they want someone who can come up to speed with their codebase quickly. This means they do not want to spend time training someone in the languages and preferably the frameworks used.

Yes for a permanent position they will also try to get people who can do other things and in a year or two's time the person will probably not be doing the same job.

For a contractor you mist know the languages immediately, they need the person to cover a gap in their knowledge or resourses immediately. You won't be expected to know their codebase but would be expected to answer a question on the language or common library in the first few days to help a coworker debug an issue. In many cases you will not be there long enough to learn their codebase.

If you are a contractor then you learn on your own time - the company will not pay you to learn new things, well at least until you have shown you are above average in doing things then they might allow this as they know they will get a payback.

Basically you can't tell during a hiring process how good someone is (you can find out if they are bad) and so the company will look at how well you have done after some time and make a view as to wether it is worth spending resources to get you to do something different.

Unfortunately many companies have this attitude to permeant employees and don't give enough time for training etc.

> If a company is after an experienced person then they want someone who can come up to speed with their codebase quickly. This means they do not want to spend time training someone in the languages and preferably the frameworks used.

I think there's more to it than this - companies want new hires to approximately align on culture things. If I'm a Go shop I don't want someone to endlessly whine about how Rust or Elixir or whatever is better and vice versa

One thing that is not generally considered is that while it's quick to switch language, it's not true for ecosystems.

Yes, you can be productive in python syntax quickly, but I've seen enought people failing at building a sane python project I know that other things take more time: libs, tooling, workflow, typical error, debugging, deployment strats, etc.

So you do want at least one specialist in the team to drive the generalists.

OpenAI famously used to hire strong generalists over specialists (save for research positions). They don't do that so much anymore but I'm convinced it was instrumental in building such a good team there, strong generalists can generally fit to a new problem space much quicker than specialist, which probably helped them ramp up their tech quickly. As a generalist, it was refreshing to see this, you could just be who you were rather than going undercover.
It's a sound strategy as I expect "specialists" have a tendency to get caught up in minutia that aren't pertinent to the problem at hand.

I would imagine that these "generalists" in software/development had some other "specialty" though; perhaps degrees in various sciences/engineerings, quant, linguistics, music, or really anything that demonstrates that the person is up to some analytic rigor and capable of following through on a difficult series of tasks.

I consider myself a generalist (not just professionally, but also in my other diverse interests).

I have a Life Science background (PhD and post-doc), and now work as a dev writing data vis toolkits in JS/TS.

I thought people would be clamouring for a scientist who is also a developer, but it turns out they really are not! They want one thing, or the other.

I think people very often don't know what they want, and at least for data science there is this weird thinking that exists that you are either a data scientist or a developer. When in reality the good data scientists also have good dev skills.
People do want scientists who are also devs, but mostly in healthcare related software businesses and data engineering for AI/ML. If you're applying to general "dev" jobs the background won't mean much.
p.s. if you do want a life scientist who is also a dev, let me know! https://www.jake-reich.co.uk/cv
I think this may be a sign you are ready for a higher executive or director position but like many of us simply enjoy doing the work still. I faced a similar existential crisis as a generalist that ultimately led me to realizing I am an innovation strategist before a designer, engineer, or solutions architect. When a generalist crosses many silos with specialized knowledge and expertise in each the smart move in my opinion is to lean into it with a better defined role. Business consultant, solutions architect, innovation strategist, CTO and so on…
The way I see it, is that being able to demonstrate specialist-level skills in something is a good signal no matter the problem you need to solve. It means you can learn. As a specialist you have already shown ability to master a skill, so if a project needs another skill, you will be able to pick it up.

And quite often that's how you solve client problems as a contractor. You figure out what the actual problem is (in business terms), the cost/benefits of various solutions and then learn whatever you need to solve the problem. Only then you get to write code.

The funny thing is that you may be a ninja Rust developer, but sometimes all the client needs is a cron job to move data from a spreadsheet to a server. Or even worse, you may need to modify VBA scripts in an ancient Excel file!

Early in my career, with the bravado of youth, I sold myself as a hacker/computer whiz. Now I sell myself as someone who solves interesting problems.

I did game development, then embedded development, more game development, back to embedded, then robotics, then machine vision, then deep learning, then virtual reality, then back to game development (with machine learning), then embedded software in healthcare, then game development again, then vr & computer vision, and back to game development (back-end). And there's probably a few segues into other areas in there I have forgotten to mention.

I maintain multiple online profiles, that sell me as a specialist in a specific area. From blogs to single page websites. And why do I do this? Because when you go to a steak restaurant, you shouldn't expect their pizza selection to be great.

In Feynman's words "specialization is for insects." And I agree, but when selling yourself, specialization closes the deal. Specialize to win the bid, generalize when you've won their trust.

Customers, like patients, usually identify a pain point they have, and they want a specialist to take away that specific pain, be it software or medical. You sell the specialization, you keep that customer coming back with the ability to solve all of their problems.

I liken software development, and especially contract software development to follow the first principle of improv (also something I've done): You never so "no", you always follow with "yes, and..."

This article might be life changing for me. This is exactly what I needed to hear and couldn’t put my finger on myself. He seems Dutch (.nl domain), and this is definitely a thing in NL. I wonder if it is from a Dutch perspective, because it is a bit of a caveat as I feel that the US seems to have tech companies that value generalists a bit more.
The point about trust hit home for me. I have always felt like a jack of all trades. I can solve any problem you throw at me. At least get it to an MVP phase then move on to something else (unless I lose interest in it).

Like the author, this was okay early in my career. But once “front-end development” became a thing, I quickly realized that:

a) I was good at it b) Not many JS developers had a sense for UX

So the rebranding did help with getting more job opportunities. This meant I could be picky about who I said yes to. You don’t really have that choice when you only have one option.

As the author mentions Fractional CTOs, I'll chip in with my experience in that. I'm currently a Fractional CTO, which is a great way to say that you are specializing in being a generalist ;)

You need to know enough about all aspects of running a software team that builds products. Not many people are such generalists and when companies need that skillset, they pay a premium for it.

It's a way to do really interesting work and if that's not available, it's easy to pick up some senior engineering stints in between.

Yes, it seems like advertising as a specialist while being a generalist is a winning strategy. This is only true as long as there is no personal rapport though, as soon as some personal trust relationship is built it matters much less, almost not at all.

It's actually quite weird. I got tasked with things I explicitly didn't have experience with from people who knew me several times.

I think even a career change can be engineered more easily like that, within the context of client or employment relationship, and the opportunity comes up.

Whether it's fair or not, I believe that people of a certain age that are still "generalists" in their own estimations give off vibes to management or senior engineers that they aren't disciplined enough to "specialize". I can't stress enough that this is just my observation and personal experience, and not a judgment necessarily... but it really was the case for me and I bet that's the case for a lot of people in this situation.

For what it's worth, I grinded and went back to a state school for industrial engineering and wouldn't you know, my management/architect prospects improved immensely, even as a super senior just now in his 400-level coursework. Obviously not everyone has the resources or opportunity to do such a thing, but if you do, for the love of God consider it deeply.

I can remember you having a "Plato workshop" and I actually found that interesting and funny.

Generally I am against the idea that every one should be a specialist. I caught myself that I even in my head wofo=rust, because you market it in such a way. Even though I know this is not the case.

Funny story I started as Process Technologist in my previous job (studied chemical engineering), transitioned to a Developer and went to a kind of proxy-sysadmin role at the same company.

You talk about generalizing within the same domain (programming), what about if you have additional skills. Something I struggle with, as I managed a Waste Water Treatment Plant, designed Dairy factory lines and now I am Software Engineer. It is all Engineering but oh boy is it difficult to market yourself as both. So perhaps I should narrow it down on my own website as well.

I've got the opposite problem - How do you hire generalists?

It also might not help that I'm looking for generalists in web development, which seems to be saturated with folks who are only comfortable inside a particular framework or API. As a small company sifting through these candidates is depressing.

To be fair I feel like I'm probably not providing exciting enough "roles" to attract useful candidates, and I don't have a lot of time and resources to throw at hiring. But I feel like I'm doing literally the same thing as this author on the opposite side of the table - trying to craft concrete "roles" but actually just wanting generalists. Although I realise I'm probably an outlier since I'm not a recruiter and wont be thinking like them.

Seems like people have been wrestling with this topic throughout history :-)

https://english.stackexchange.com/a/508907

"1618 Jack-of-all-trades

1631 Tom of all Trades

1639 John-of-all-trades

1721 Jack of all trades, and it would seem, Good at none

1732 Jack of all Trades is of no Trade

1741 Jack of all trades, and in truth, master of none

1785 a Jack of all trades, but master of none

1930 a Jack of all trades and a master of one

2007 Jack of all trades, master of none, though ofttimes better than master of one

The extra-long version of the expression may be considerably older than the 2007 earliest established occurrence might suggest—perhaps even a decade or two older. But it isn't the original form of the expression; and in comparison with the forms that arose during the 1700s, it is quite young."

If I am hiring someone on contract, I don’t want them learning the technology on the job. I want them to be a subject matter expert and not a “jack of all trades and a master of none”.

When I was looking for a job after being Amazoned a few months ago, I saw two types of jobs that I was qualified for - a generalist developer who knew AWS really well and a specialist in a niche of a niche in AWS that I was the subject matter expert in.

I spammed literally hundreds of resumes using the Easy Apply feature where they were looking for generic enterprise CRUD developers and heard crickets.

I applied for two positions where I was a specialist and had two interviews and one offer within three weeks.

I also had two full time offers based on my network FWIW

There is this IBM description of a “ T shaped individual “.

While being specialist in some area in depth you still get horizontal bar where you cover things that are somewhat outside of your specializations. That is theoretically best employee.

"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."

— Robert Heinlein, Time Enough for Love (1973)

I'm a generalist. The most accurate description of my work is "webmaster". I built a website from the ground up and I understand the whole stack from Linux to the words on the page. I maintain nginx configs and care about accessibility. I write dockerfiles and comprehensive articles.

It's weird to be pigeonholed when I love wearing so many hats. It's probably why I found the corporate world so dreadful.

Isn't some of this simply that the practice of software development has become a more mature, bigger space over time?

More companies in the space, with more staff, building more things?

So naturally you don't want 50,000 generalists engineers in your FAANG. You probably have different areas of practice with different specialities, and recruit more specifically for roles in that area.

Are you a tech generalist, or a failed specialist? Are you a Renaissance man, or a dilettante?

It's easy to identify as a generalist. How do you know if you're a good one? How can a hiring manager figure out if you're a good one?

You're being hired to do specific work, unless you're coming through a recent-grad or other entry-level pipeline. You will be evaluated on specific technical competencies, because that's harder to fake. You need to show your ability to master at least one stack, language, framework, system, or technical area.

Your specialized skills demonstrate prior mastery and an ability to do the kind of work they need you for. Your generalist skills will show through in the quality of your work and ability to influence broadly.

So no, nobody's hiring someone who specializes in being a generalist. But, they are promoting them.

Really glad to read this, while it's not strictly 'revolutionary' thought, having it formulated and expressed on paper does boost my own confidence in the way I aproach self-growth, as someone who aspires to be this type of 'generalist' as well.

Thank You for the article!

I've more often passed over people for being overly specialized than the opposite.

For example, I expect anyone that knows a "modern frontend framework" to be able to learn the others. HOWEVER, if someone has ONLY done React I assume (based on many previous experiences) they will be unwilling or unhappy using something else (Angular / Svelte).

If they look like a fit otherwise I'll probably still do a call with them, but I'll be looking to prove they're very openminded and not stuck in their ways.

Anyone that is married to a specific tech/language/etc is sus to me. Note, this is just an example, it is not specifically an attack on react (although it is currently a common framework that people get married to).

The same applies to regular jobs. Most job ads have a bullet list of requirements. There is some flexibility but when I was interested in a Ruby job as a C# developer I had a real hard time and didn’t get any offers although I got close. Same for Haskell but there was only one company hiring for that ever in my city. And that is not taking into account the pay hit. Which is a luxury for the unmortgaged/kidless or both.
I think that the rise of various AI helper tools puts pressure on generalists and maybe even makes it less viable to advertise oneself as generalist than before - with AI helpers everyone can be generalist to some degree.
My observation is that generalists gain more opportunities within organizations over time, but have a harder time changing organizations. Which I guess makes consulting challenging for generalists
I think up to a point being a specialist enables being a generalist. If you deep dive into the workings of programming languages, you gain valuable knowledge you can apply elsewhere (in other languages or even outside of them). I always ask myself how much of ones experience with some technology is transferable knowledge. In programming languages that are conceptually poor, there will be less transferable knowledge, than in programming languages, that introduce many profound concepts. Of course there is also a certain kind of knowledge to lower level languages. But it might not transfer well to higher level languages and their abstractions. Though one might understand how those are implemented, which is also good to know.
The best generalists should probably look into starting their own businesses. With AI tools, it becomes somewhat easy to perform at an average level in many roles.
I like the formula of "I am an expert <ONE programming language> developer with a focus on <ONE specialization> and <ONE business or development model>." Let me try it on for size:

I am an expert Python developer with a focus on Azure-based cloud solutions and enterprise development in highly regulated industries.

Sounds about right, even though I've never worked at a place where all 3 aspects were in full force. It stings a bit to shave off the other hundred or so things I can do, but that's marketing for you!

An eye opener honestly, I have to admit that I constantly thought that generalist path is more attractive, specially for non-tech companies, but I might need to change the approach after reading this.
This resonated a lot!