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)
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.
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.
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.
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.
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.
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 🙂
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
Thank you for these book recommendations!
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.
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.
I'm glad I'm not the only one with this experience of JavaScript :)
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?
Glad you enjoyed it! Please do :)
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!
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 :)
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!
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!