I greatly enjoyed Graham Lee’s series of posts about specialisation versus generalisation in software engineering¹, quite possibly because it’s me.

My background is a little different from Lee’s, though, so I thought it was worth sharing.

I have a two tier experience². With a few minor blips, Unix has been a constant technology underpinning since my first year at university. I started using Linux around the time 1.0 was released. I got a Mac when — or possibly before — OS X was ready for mainstream use because it was Unix with a nice UI. At work I’ve seen the change from big Solaris and HP-UX machines, to Linux, to containerised applications (which are normally based on minimal Linux distributions). Sure, the different Unix variants are not exactly the same, but most of them have something bash-like and ls does the same thing everywhere, even if the more esoteric options vary.

I should say that this is largely a preference. I don’t like Windows but that’s not an objective criticism. I do joke about it from time to time³ and I do admit the limits on my knowledge, but I don’t refuse to work with it!

Sadly, being a long-time Unix user is not a career.

I started my career at a “pure” consulting company. Each client I worked with wanted to do something different and I ended up using varied technology stacks. This was great from a “generalist” point of view. I flitted from Uniface to PL/SQL to Perl to Oracle Applications⁴, but beyond abstract concepts like “problem solving” I didn’t get anything like a transferable skill. The obvious path would have been management but that wasn’t where I wanted to go. I saw friends and colleagues specialising, and earning considerably more money for the privilege.

I appreciate that I’m likely leaving money on the table, but I stumbled on a solution that works for me: being part of the field engineering team of software vendors.

Being in the field team means that I work directly with customers and they end up wanting to do all kinds of things. In a year I can work with dozens of use cases, satisfying my need for novelty. At an end-user, I’d be looking at a small number of use cases the whole time.

At the same time, there is also a degree of specialisation. By working with the same product all the time, I can become The Expert in it and some adjacent technologies. For example, I’m pretty good with Kubernetes and Java these days. I need to write code and sketch out software architectures. My knowledge has to be deep enough to demonstrate credibility but I don’t have to build production code. Additionally, I can bring domain expertise. I wouldn’t sell myself purely on my banking knowledge, but it’s a nice value add.

This may not be the solution for you. There may even be better options for me that I’ve not found yet! But I thought it was worth documenting my experience, since most of the articles I’ve seen are for more traditional “software engineering” or management roles. Other positions are out there if you know where to look.