Should I Be a Specialist or Generalist? Both!

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.