DEV Community

Cover image for A generalist is born when a specialist becomes bored
Daniel Irvine 🏳️‍🌈
Daniel Irvine 🏳️‍🌈

Posted on

A generalist is born when a specialist becomes bored

Header photo by RhondaK Native Florida Folk Artist on Unsplash

I’m a full-stack developer, which means I’m a generalist. I believe that generalism in software development is a good thing. But many developers, engineering managers and even CTOs think that generalists are a risk and that what software teams really need are specialists.

Because apparently, generalists can’t be very good at what they do. After all, software systems are far too complex these days for any one person to ‘know’ their system inside-out. Right? And how could a generalist keep up the same pace as specialists when everything changes so fast? Surely they can’t hope to remain relevant? Surely a generalist can’t be any better than a mid-level developer in any of the things they know. Right?

This fallacious logic is exactly why some people prefer specialists over generalists. It results in teams hiring front-end and back-end developers rather than just plain ol’ developers. Because—apparently—only specialists really know what they’re doing.

But here’s the thing:

A generalist was a specialist at some point. A generalist is born when a specialist becomes bored.

The generalist’s first language

In their first job, the generalist is not a generalist. How can they be? They are a novice. However, they do have something that sets them apart from their peers: an appetite to be an expert.

They get to work learning language idioms and patterns. They learn about the language’s performance characteristics, how to communicate with external systems, and explore its library ecosystem. They read all of the books they can find, because they realise that learning didn’t stop when they left college.

In my case it was C#. I was eager to become an expert so I had a whole desk full of books. I was extremely proud of my bookshelf! I read as many open source projects as I could, and even contributed to one or two along the way. I spent a good seven years as a C# developer, and yes—I would like to think I became something of an expert.

But the same learning mindset that drove me to be an expert C# developer also drove me to be something else.

At some point, every expert gets bored. They’ve learned as much as they can about the language and its frameworks. So to feed their appetite, they need to find something new.

With the .NET ecosystem, as a developer with multiple years of experience, if you want to learn new things then you’re basically waiting for Microsoft to release the new version of Visual Studio to see what they’ve tinkered with this time around. Occasionally there are bittersweet moments when Microsoft obsolete some perfectly fine but slightly outdated framework and replace it with something slightly more modern and slightly less robust.

This ‘keeping your knowledge up-to-date’ cycle gets a bit dull when all you know is one language.

So the would-be generalist moves on to something different.

The generalist’s second language

For me it was Ruby. And just wow… how refreshing was Ruby?! No longer at the mercy of Visual Studio! No longer forced to write full function signatures with return types and parameters types! My poor fingers would finally get a break! Dynamic typing… how wonderful! Everything is an expression… amazing! Metaprogramming… incredible! The shackles were off!

I remember this moment as being liberating. While I was appreciative that C# had given me a solid grounding in object-oriented design, I could now also appreciate that it was an unnecessarily complex language. And so I learned to love simplicity.

TDD and the learning cycle

I’ll tell you my secret weapon for learning new languages: TDD. If you know TDD and a few katas, you can learn just about any language using the same pattern of learning. Just program a few katas and you’ll be off to a flying start. It’s really this simple.

For me, my third language was Clojure, which as languages go is essentially perfect. The Clojure community has the same kind of business-thinking that the .NET community has, balanced with the same desire for simplicity that the Ruby community has.

The fives stages of grief

For my fourth language, to my horror I ended up working with JavaScript. I wasn’t particularly fond of JavaScript. A messy language, which I had to climb down to after scaling the wondrous heights of Clojure and ClojureScript.

With JavaScript, I went through the five stages of grief.

First comes denial. “This will only be for a short while, then I can go back to real languages.”

The second stage is anger. “React…?! Facebook?! What gave these pesky developers the right to walk all over four decades of GUI development best practice?!”

Then, bargaining. “Hmmm, I can write my JavaScript with plain functions, just as if it was Clojure…”

Then came depression. “My career is over. I’m leaving to set up a beach hut restaurant.”

Finally, acceptance. “Okay, so I was wrong. JavaScript is totally fine. Time to update my LinkedIn profile - I’m a JavaScript dev!”

The insight of past experience

One of the joys of being a generalist is you stop caring too much about ‘one true way’.

Now that I’ve been working with JavaScript for several years, I can truly say that the past experience I’ve had with C#, Ruby and Clojure has made me a better JavaScript developer. I can see why the language is the way it is. I do not miss ‘real’ objects. I do not need classes. Prototypal inheritance is cute, and it certainly doesn’t give me “the rage”.

I’m not eager to replace all my JavaScript code with TypeScript, because the benefit isn’t clear. I’m doing just fine without type definitions.

I’m at ease with all of JavaScript’s kinks. They don’t bother me.

I honestly don’t care too much about the difference between double equals and triple equals, because I know my tests will catch me if I get it wrong.

I do not need a linter to tell me to use semi-colons or not, because I’m happy with either choice. I don’t need a linter to tell me to always return a value from my functions, because I’d rather not have to write extra code if I can avoid it. Ruby and Clojure got me very comfortable with unseen return values.

JavaScript devs can get hyped up about the latest fads whereas I just shrug my shoulders. Most often I see new libraries as unnecessary complexity.

When something new comes along, I ask myself “Will this new tool|technique|library|framework help me write higher quality code, faster?” If the answer is no, and very often it is no, then I won’t get excited.

Can generalists remain experts?

Let’s say for the sake of argument that it takes 5 years to become an expert with a language. Then someone with 15 years’ experience will have had time to master 3 languages.

You might say their knowledge of the first two languages will be severely outdated. If they’ve stopped using them professionally they can’t possibly know what they are doing.

That might be true if they completely stopped using that language or keeping abreast of news. But that’s not my experience of generalists. They have their ear to the ground and remain in the loop, and they also tend to be the kinds of people to take a few hours here and there to experiment with the latest and greatest features.

What’s more, if you’ve got 5 years experience in a language, then catching up on the latest framework can mean spending as little as a day to build a toy application. It won’t take a year. Languages and frameworks change only incrementally.

Generalists pick a better tool for the job

The privilege of being a generalist is that you get to pick the better tool for the job. (I won’t say best tool for the job because who really knows what’s best?)

If the only tool you know is React, then you’re going to get a React solution, even if ‘at scale web applications’ is not your problem.

Being a generalist does not require superhuman abilities

On my latest project, I’ve had the opportunity to really get to grips with Docker and Nginx. I wouldn’t say I’m an expert, but what I can say is that out of everyone on my team, I’m the one who has been the most eager to jump in and learn it.

My experience as a generalist tells me that as scary, difficult and complicated these tools may seem, I know that it’s possible to master them.

I can see that for some of my teammates learning these tools seems seriously difficult. It will take a huge amount of energy, and they might fail.

There’s no difference in ability between me and my teammates. They are all bright and hard-working. The difference is that I tend to have very little fear of picking up new technologies.

What have you got to lose?

Picking between specialism and generalism is a false dichotomy. If you feel like specializing, then do it. Just don’t forget that beyond specialism lies generalism.

Happy coding!
🙏🏻

Top comments (25)

Collapse
 
somedood profile image
Basti Ortiz

Now this is a remarkable article. I wholeheartedly agree with what you said. Great read!

As in the title, it is indeed fallacious to believe that "specialists are always better than generalists". My main takeaway from this is that a generalist surpasses a specialist when they can (eagerly) apply the knowledge of the many different paradigms, thinking processes, and mindsets from other technologies in a constructive manner when tackling problems for another technology. That, to me, is the kind of outside-the-box thinking that is always worth striving for.

Collapse
 
kitgary profile image
Gary Lau

I partially agree with your points.

"A generalist was a specialist at some point."
It's true but when you choose to become a generalist, you spend a lot of time on different technologies, you will never dive deep as a specialist. This may not be a problem for easier domain like mobile or frontend development but for cutting edge skills like deep learning, compiler, etc, you have to put much more time to master them, so become a specialist would be a better choice.

Collapse
 
d_ir profile image
Daniel Irvine 🏳️‍🌈

Being a generalist doesn’t bar you
from being a specialist.

Compilers are something I know (a little) about. Here are two examples of prominent generalists who work in the field of compilers.

Anders Hejlsberg designed/architected Turbo Pascal, Delphi, C# and TypeScript.

Rich Hickey was a .NET specialist before he created Clojure.

We’d normally view them as specialists but wouldn’t you also consider them generalists?

You might never get the chance to hire Hejlsberg or Hickey into your team, but there are many, many developers out there who have the same problem-solving mindset.

Maybe what I’m trying to say is that if you’re a novice developer trying to choose between generalising or specialising, then don’t worry - because it’s a false dichotomy. Just do whichever you feel is best for you at the moment. There will be always be more time later to shift gear.

Collapse
 
andrioid profile image
Andri

Excellent article! I've been in the business since I was 18 years old (now closing on 40) and I am proud to call myself a generalist.

As you say, by no means did I start as a generalist. I picked a speciality and did that exclusively for a while. Then I found something else interesting and did that for a while (years).

I always cringe when I hear "Jack of all trades. Master of none".

Specialists are often referred to as "T profile" where the "T" signifies where the Y axis indicates experience and the X axis different types of speciality. If that's true, I probably identify with an "M profile".

But who's to say what is specialised, and what's generalised. Technology as a field is huge and even "full stack engineers" don't know all backend/frontend/database/app stacks. At some point they found something in the layers that worked for them.

Right now I'd say I'm specialised in terms of "React, Go, SQL databases & Linux". In that particular stack, I might be "full stack". But that all depends on where I'm working at the time.

So, to sum up. I don't think it's white or black, or even bad or good. A good team needs to fill different roles. Some are laser-focused on one thing and others are more broad.

Collapse
 
d_ir profile image
Daniel Irvine 🏳️‍🌈

Thank you for this. I really like the description of an "M profile", it's a great way to put it. I also agree with your conclusion. A lot of it is contextual. Right now my team needs me to be the Rails backend dev because no one else has that skill. So although I think of myself as a generalist, I'm needed on this team for my Ruby knowledge.

Collapse
 
andrioid profile image
Andri

I do the same. A month ago I was doing TypeScript and React because that’s what the company needed resources on.

Right now the need is backend services and then I do Go.

Doesn’t matter much to me. As long as I can deliver value 🙂

Collapse
 
bpx3 profile image
bpx3 • Edited

Wonderful article, thank you
I'd love to quote a paragraph from the book 'Thinking fast and slow', by Daniel kahneman:

The experts performed worse than they would have if they had simply assigned equal probabilities to each of the three potential outcomes. In other words, people who spend their time, and earn their living, studying a particular topic produce poorer predictions than dart-throwing monkeys who would have distributed their choices evenly over the options. Even in the region they knew best, experts were not significantly better than nonspecialists.

Another book that goes in depth about the subject is: Range: Why Generalists Triumph in a Specialized World

Check it out

Collapse
 
d_ir profile image
Daniel Irvine 🏳️‍🌈

Thank you for these book recommendations!

Collapse
 
fuzzysteve profile image
Steve Anderson / Steve Ronuken

Ideally you want:
Wide and shallow, with some surprising depths.

And those depths allow for going sideways at problems, because there are few 'new' problems. If you can solve it in one language, that experience will apply, perhaps to a lesser degree, to a different one.

Collapse
 
jbeetz profile image
J Beetz

Thank You!

I've had the pleasure to be a generalist as well.I can completely identify with a lot of your comments especially around JavaScript.

Having a greater variety of tools to work with, simply makes you a better problem solver

Thinking broadly about a problem, versus specific limitations by using a single approach. Allows me to find a better tool for the job.

Collapse
 
d_ir profile image
Daniel Irvine 🏳️‍🌈

I'm glad I'm not the only one with this experience of JavaScript :)

Collapse
 
djpandab profile image
Stephen Smith

Daniel great read. In other times, the generalist would be called a jack of all trades. This described my job history prior to taking the tech plunge. Being a generalist is not for everyone but some do thrive in that kind of environment. I am an "older" beginner, who having lots of life experience has found that specialism does not necessarily work for me. I enjoy being the generalist and all that it has to offer. If I find a topic that is great interest, then i will specialize in it until it no longer holds my interest. Is it okay if I pass this article along to some of my non-tech friends?

Collapse
 
d_ir profile image
Daniel Irvine 🏳️‍🌈

Glad you enjoyed it! Please do :)

Collapse
 
tehmas profile image
Asad Raheem

For my fourth language, to my horror I ended up working with JavaScript. I wasn’t particularly fond of JavaScript. A messy language, which I had to climb down to after scaling the wondrous heights of Clojure and ClojureScript.

This.

People are doing wonders using JS, no doubt about it. Coming from languages like C# or Python, JS seems to be too messy. I guess this is the actual problem that JS frameworks are trying to solve.

A super awesome article @d_ir . Thanks for sharing your experience!

Collapse
 
chrisachard profile image
Chris Achard

Never thought about it that way, but it's a great point. I think a lot of people follow a similar path: picking up languages or technology along the way until you look back and "surprise!" you're a generalist :)

“React…?! Facebook?! What gave these pesky developers the right to walk all over four decades of GUI development best practice?!”

Ha! I teach people React, and that's a completely accurate depiction of what a bunch of people feel at least once while learning it :) It's so universal!

In my case, I'll also add that I became a generalist because I didn't want to give up the "old" stuff that I knew so well. I like all the new stuff a lot - but all the stuff I already know works so well - might as well keep up with that too!

Collapse
 
ravii profile image
Ravi 🐧

Appreciate this article's over a year old now, but I found this when browsing and I feel it's ever-pertinent. I've been feeling more convinced that generalism is a philosophy I want to strive for in the way I work, and in the mindset I have as a developer. It feels like an 'unpopular' perception at the moment, though, where the discourse seems to focus increasingly more on deeper specialisations. I'm glad I found this piece as I think you've crystallised a lot of thoughts that I was struggling to articulate to myself. Thanks you for sharing this!

Collapse
 
lepinekong profile image
lepinekong • Edited

It's better to rebrand you as multi-specialist, being a generalist is very dangerous even for the greatest ones ;)

Generalist vs Specialist

Collapse
 
keymannerdawid profile image
Dawid Kimana

Quite true. I also started (and am still on) the MS train - VB6, then C#, and I can say it's that more important to learn as much as you can in tech, if you have the energy/passion for it. I have at some point used concepts learnt in Nodejs on C#, creating a http server, and provided an out-of-the-box solution to the problem at hand to the amazement of the team. Learning different languages/paradigms gives your mind a broader playing ground when formulating a solution

Collapse
 
igorescobar_38 profile image
Igor Escobar

Loved the article! I can related a lot with your story! What I usually say is: at the same moment you define yourself you are at the same time limiting yourself. I like to be open to whatever and this just keeps expanding my mind more and more!

Collapse
 
jonathanburnhill profile image
Jonathan Burnhill

Thanks for this, my life experience has told me it's better to be a generalist!

I left school and became a builders labourer and touched on many things, after I spent 3 years been a roofer which was good but repetitive.

Later I got a opportunity to move to another country, there wasn't much work as a roofer but if I started thinking of all other trades there was plenty!

Stop thinking like a roofer there is carpentry work, then there is plastering, plumbing and then I got to think about concrete and swimming pools and all the infrastructure that goes into it!

Later I moved to France and met a British builder who had brothers all specialised in their trades and very very good but like he said he can do all their jobs just they can do it that little bit better!

Because of my experience it was me hiding him on swimming pool work and sharing information back and forth was great for growing my mind, the little tricks I learned from here are invaluable.

I'm rambling the point is a jack of all trades and master of none has always been more useful to him.

I can do most things that to into a house and picking the right tool for the right job has helped me look at programming projects with a real sensible head!!

Me a specialist? Na I can work on a house, swimming pool, fix various power tools, can have a look at your car, small repairs in white goods and now getting into programming and still a clear view of everything I need to still learn.

My point again is been able to do a lot leads to more opportunities and a more open mind which leads to better knowledge sharing!!

I'll shut up now!!

😂😂

Collapse
 
daedtech profile image
Erik Dietrich

Not to zoom right into a tree instead of the forest, but I'm really curious about something.

"But many developers, engineering managers and even CTOs think that generalists are a risk and that what software teams really need are specialists."

It's been a long time since I've applied for programming jobs or looked at their job descriptions, but I know that many of them these days call for "full stack" whatever. And, from what I recall, most job descriptions used to have an entire alphabet soup full of "required" and "nice-to-have" languages, frameworks, databases, etc.

I spent a number of years as an IT management consultant, so, actually talking to managers and CTOs about their org charts, job descriptions, etc. And the most en vogue thing in the mid-2010s was "T-shaped people" or "generalizing specialists" who maybe had one deep area of knowledge but then could adapt to and be plugged into any team or situation.

So I guess my question is, has there been a sea change in the last 3-4 years? Are hiring managers and leaders now saying, "I want devs that know C# and absolutely nothing else?" Like, is that some kind of software management fad, now, to look for people that have only one programming language/framework on their resume?

If so, that seems absurdly short-sighted.