"Should I be a specialist or generalist?" Is a question it think we ask ourselves a lot as software developers. It’s an argument that often ended with a person having to ‘pick one’. But, I don’t think it has to be that way, and my answer is “both, constantly!”
Specialisation is Tempting
If I’m going to be frank, I think one of the appeals of specialisation is that you can kinda “be finished” learning and just be a good (eg C#, Java, etc) developer after 5 years and do that for the rest of you rlife. While I see the appeal of chilling out like that, it does make for a very toxic team member. I have met too many senior software engineers who are clearly finished learning, and are resistant to change, probably out of pure laziness. This makes it hard for the team to try new things, play with process, experiment with new technologies or generally stay competitive.
It’s also bad for them. It dies them down, prevents promotion, and blunts their main tool for their job — their brain.
The reality is learning never stops happening, and shouldn’t.
Jack (or Jane) of All Trades, Master of None
A common fear with being a “generalist” is that you become OK at a lot of things, but great at nothing. A common solution to this is to specialise in something, and become a T-shaped developer, whereby you know one language/stack/tech really well, and a little about other things. This shows you can learn other things, but also can go deep on a certain area.
However, what this diagram doesn’t really represent is time. A ‘T’ shape is more of a person now, but not in the past or future.
The Paint Stroke Developer
My final analogy is one I heard on The Soft Skills Engineering Podcast, of which I’m a massive fan and patreon of. I like the analogy because it takes into account time, and how your career will force you adapt and change as time goes on.
As time goes on, you explore different areas in varying depth. Free Vector Design by Vecteezy
The analogy is this: the soaked paintbrush moves across the canvas, and little amounts of excess paint drip downwards. The drips is the “depth” of your T-Shape from above. The horizontal forms your breadth of knowledge over time.
There are multiple drips downwards, because over time as a developer, you’ll look into different things, as technology changes, you change jobs, or something new comes out.
Comparing this to my own life, my drips would be things like C, iOS and Objective-C, Python, Java, PHP, C++, Embedded C, iOS again, Ruby on Rails, Ember JS, Elixir, Swift, AWS, and so on.
My breadth of knowledge also becomes a bit fatter as time goes on too, as I learn about topics and see commonalities between languages. You’re able to reuse skills from one area in another, and generally you start to be more aware of what is possible with programming languages and tools. Ultimately, your unknown unknowns decrease as time goes on, and your ability to pick up new tools increases, as you’re more able to spot what is familiar, what is contrasting and what is new.
So I encourage this thinking about your journey. T-shaped, over and over again. You can change your specialisation, or let it fade as you pick up a new one. I think the best habit you can get into is learning all the time, even if it’s in the same general area. Go deep, but find ways to add to your general view of the tech world, so when you come to something new, it doesn’t completely startle you.
Best of luck.
Top comments (8)
I had never heard about the paint stroke analogy and I love it! It represents really well how someone may go deeper into one subject than others, and doing that's perfectly fine, afterall one of advantages of this paint stroke approach is to get to know what you really like/dislike and why.
Interesting article. I would also like to emphasize that we tend to restrict ourselves just to learning new Languages and Frameworks. I think learning new sectors of computer science is also worth exploring.GPGPU programming, Image processing and Machine learning are the ones I studied and managed to finish a paid project on it. I cannot explain how satisfying and helpfull it is.
Yup! Very true. I don't really mind too much what you dive deep in as you go on, just that the act of doing so puts you in a good mindset and practice for when you need to dive deep to solve a big issue :)
Interesting read Sam.
I thought of another analogy as a result of this post. My knowledge more or less could be represented by a series drops of very thin watercolor paints.
As long as I keep dripping, those splotches grow. They grow not only in size(breadth of knowledge) but also in color intensity(depth of knowledge) in the areas you are dripping.
If I stop dripping, the color starts to fade(skill atrophy) until it is a mere stain on the canvas.
As a javascript programmer who wants to learn go, I want to confess that it is difficult. Javascript is very crazy lately, changes and evolves, monopolizes my attention. Of course, I'm a rookie, I've been working with him for a year. I guess with time things will be clearer and I'll be able to move on to the next.
The analogy of the "T" I liked!
I also think JS is moving pretty fast these days, so deep diving into new frameworks (vue, angular 2, react, etc...js etc) has the same effect! It's the act of diving deep and coming back up, again and again that will make you a better engineer!
Wow,I'm so glad to hear that i've done it already
Nice job!