image created by Margaux Peltat for the Chilled Cow YouTube channel
Time for #DEVDiscuss — right here on DEV 😎
Should Developers Specialize or Generalize?
Void⚡ ・ Jan 24 ・ 2 min read
Inspired by @codewithvoid's Top 7 post, tonight’s topic is...should you specialize or generalize as a developer? 🤔
- Have you chosen to specialize or generalize as a developer?
- What are the pros and cons of your approach?
- What are the pros and cons of the other approach?
- Any triumphs, fails, or other stories you'd like to share on this topic?
Top comments (20)
I would say: depends on the stage of your career.
For someone starting (<2 y), I would say “generalise” until you get more experience to be able to have more opportunities. Then, once you get more experienced and have found something you really enjoy in specific and believe would be a good place to become an “expert”.
Still, being able to learn new things and do whatever comes is the way to go, in my opinion. Depends also on the market.
Speaking as a someone who partakes in the hiring of developers: Some "specialist" roles, which are not that specialized, are really hard to hire for, but if we look for generalists, we get hundreds of applications.
I think you can learn 1+ "specialties" while still being open to more generalist roles and pursuits. Specializing can open opportunities, and you're never "only" a specialist, it's more how you play the game of career opportunism.
If you take that above info and think about doing some research and pursuing a certain amount of specialization — know a couple things:
In my opinion, generalizing is the way to go. The tech moves so fast that even if you specialize, there's a fair chance the thing you specialized in will be outdated within a matter of years. Flexibility and picking up new concepts quickly is the name of the game for developers, IMO.
I do think there's some middle ground on this when it comes to specializing in a higher-level way – specializing in Front-end Development, for example, vs React or Angular specifically. Focus on languages or skillsets, not frameworks, tools, or libraries.
Ultimately, though, I think most devs will naturally specialize over the course of their career based on the things they find most interesting and are most adept at. My advice would be: let it happen organically, and don't feel like you have to choose or force a specialization too early in your career!
This is a VERY good point. Imagine being specialized in something like Flash. 😥 Lotsa eggs in one basket.
I think it's honestly inevitable that at some point in a developer's career, they will end up "specialized" in a tech that gets depreciated. I've got a lot of hours logged in React, personally – I don't regret that choice, and it's been really beneficial to my career...and yet, at the same time, I'd be pretty surprised if it's what I'm still doing in 10 years.
With that perspective, I don't think of or market myself as a "React developer" (even though that might be most accurate right now); I use "Front-end developer and UI designer". That feels more accurate to where I want my career to go, and it doesn't limit my options in the current moment.
If I remember my 30+ years development carrier, then I told, time to time I specialize for something, but focus was changed really much, so this give me a general developer knowledge. I started with Basic and goes to direction of Z80 assembly to another path, some time work as graphic designer and later flash developer and lot of other things. Currently my react frontend skill transform to nextjs fullstack. Last month spend of playing with AI - how can I insert into my workflow.
The skill and career journey I've adopted so far is the diamond approach:
As a beginner, it's okay to specialize on one thing before moving to others. But specialization should have its limits.
I started myself in late-2013 as a (HTML and CSS) web developer, learned more about the DOM, and responsive design, before generalizing myself to use more and more web libraries and frameworks.
Getting yourself in either generalization's or specialization's comfort zone is risky, because:
This diamond approach is indeed a repeating pattern. After re-specializing yourself from generalization, you'll need to re-generalize again before specializing on another one.
This is great because one day, you'll become a generalist who also specializing on each fields. Or in other words, a multiple-T-shaped developer, or even a comb-shaped one. You can learn new, emerging things very quickly due to your past, specialized experiences. And you'll be different to those who just either want to stick with one or two languages/frameworks or just want to learn as many things as possible.
I guess we have to become generalists to become good specialists.
We have to understand the landscape very well to understand how and why its assembled this way, what problems it's causing, understand where the whole thing is going, and what problems will become more pressing.
I've generalized a lot, sometimes due to work needing me to shift tasks. Generalizing allows one to form connections between different technologies and I think has helped me to learn even more by giving me a nudge in the new directions.
Why not both? I figure the T-styled person approach is actually viable outside of the HR department.
It's also called 'Generalised Specialist'
I'd say generalize. I know some about a lot of things & I know a ton about very few things. Besides this just being more interesting & fun.... getting over that initial hump of a hello-world case in that technology, finding out the good docs & resources, getting over the intimidation, setting up tooling, etc.... that is 80% of the climb. Knowing what is useful when is so valuable.
Once you know enough to start, it's pretty easy to drill deeper as needed.
But be aware, there is very little prestige in being a jack or jill of all skills. You don't get to be a guru at something, and you rarely get the recognition that the master of X skill will get. Not much bragging rights because you rarely break new ground in that area.
But there is a deep confidence in having extensive experience in learning new things. Throw me at a problem & it WILL get solved no matter what it takes. I'd rather have a toolbox full of basic tools, than only have one very, very fancy hammer.
Its a really depends what you want for you carrer or what you like to do in your job. My example I really like to code with JS, I tried java, python, go but any of these make me happy like JS in my work. So i'm focusing in specialize in JS. I think to be a specialize is more easy beacause you have a definied route to follow. When you are a generalize dev you have so many options, this can be confuse in some point.
What is a "generalist"? Can someone describe it in details?
In my opinion, I believe generalize is the way to go because the tech moves so fast. What we have right now might get outdated really soon and getting a good grasp of the newer technology matters in terms of job market and tech trends.
The best thing is not to plan to do either. Never pigeonhole yourself, just do whatever you find interesting.
I've been a developer in financial services, scientific measuring device manufacturing, phone apps, web dev, and medical device manufacturing, each time I had to learn new technology, but also used technology I already knew.
I guess that makes me a generailst?
It's great being able to learn about new fields. In my current field is where I want to stay.
I don't know what it would be like to be a specialist. Would I have to only work in one field? Or would I only know one type of technology, like, would I be going from React job to React job?
I guess I'm in the middle of my career, so wanting to settle down now makes sense. On the other hand if everything goes belly up, I know I can manoeuvre into most spaces. I'll never get to be a data scientist/machine learning dev, but I think that's about the only place I wouldn't be able to prove my skills transfer to. Maybe front end, too, as my aesthetic skills are not good, although my basic understanding of UX is OK.
If you're hiring a generalist, I suppose that you've got to consider that maybe it'll be a month before they're proficient with your tech stack if they haven't used it before, but if they have then they'll be up and running as fast as any specialist.
From my experience I've started with specializing a popular topic instead of generalizing. As I was told by my close circles as be a Go to person on a topic will help you grow initially.
And same also from the book The Dip - by Seth Godin.
Then as my career progressed, I started going generalizing.
After initial steps on the career development a T Shaped approach would be perfect. Later you can go as Pie Shaped (Specializing in 2) and then Comb Shaped (Specializing many)