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