A Career Guide for the Recovering Software Generalist
Since I’m kind of an old man, in college, they taught me C and its shiny new cousin, C++.
This was a CS program, so they didn’t ultimately focus on the language. Instead, they went on to focus on the theory of things: algorithms, data structures, reasoning, and, well, computer science. But they had to teach us just enough language for us to make sense of and apply those concepts.
So C/C++ it was.
My first full time programming job was a dream come true for the software generalist. They had C and C++ both for me to work on.
But they had plenty of other language besides, and not a ton of manpower to spare. So I learned Visual Basic. And also PHP. Oh, and Java. (There were actually a few other things besides, but I think you get the point).
By the time I was about 4 years into the workforce, I’d switched my focus as the world moved toward web apps.
I’d gone from working on Linux kernel programming in C to Java web apps with Spring and Ant. Fast forward several years, and I’d switched it up heavily again.
Java web apps? Pff, that was so 2006.
I went to work for a completely different company, making a completely different product, and became a C#/WPF developer of desktop applications.
I was the consummate software generalist.
The Software Generalist Source of Pride
I was proud of this, too. If you’d asked me what I specialized in, I’d have said something like this.
My specialty is that I’m a generalist. I live and breathe code. Don’t care about your domain or your particulars and I don’t care about your language or stack. I’ll be good anywhere, as long as it’s code.
If you’d pressed me on the specialty point, I might have conceded a little.
Well, I guess my specialty is object oriented programming. Yep, if you need inheritance, encapsulation or polymorphism, I’m your man!
These days, assuming you read this blog with any regularity, you probably know how ruefully I tell this story.
- I’ve written how free agents can stop generalizing and about the idea of niching down.
- I’ve given advice for free agents to specialize.
But today I’d like to double down on this advice by offering it to salaried folks and not just freelancers. You should specialize.
The Generalist’s Career Struggles
Given that I once held the software generalist position in high esteem, I can empathize with you if you do currently. But I’ll give you the same advice that I’d give to that younger version of me.
Stop it.
“Good programmer” isn’t a specialty any more than “creative” is a specialty. It’s a valuable skill (or trait), to be sure. But, without direction, it will just leave you with an unrelated series of discrete pieces of experience that don’t lead to anything. That younger version of me had roughly the same trajectory as a creative person with a resume like this:
- Wrote blog copy for Acme Inc
- Did a UX stint for MegaCorp
- Worked as an assistant in a music studio
- Dabbled in HTML/CSS for Beta LLC
Who is it that hires a person like this? Someone that has trouble staffing a position, that’s who.
“What can I do? What can’t I do!? Look at the diversity of that skill set!”
Most hiring managers are going to take a pass in favor of the person who can do the thing that they currently need, rather than the person who can do whatever.
So let’s look at how to steer yourself away from the software generalist treadmill and to get experience that builds on itself rather than scattering about orthogonally in N dimensions.
Don’t “Specialize” in a Tech Stack
I know what you’re probably thinking.
Or, I should say, I know what you’re probably clinging to, particularly if you take my early career as a counter example. Don’t be like Erik, and don’t go shuffling about from tech stack to tech stack. Just pick one and specialize in that.
No, don’t pick a tech stack and specialize in it. In the first place, “I do whatever in Java” is too generic and it reeks of commodity labor.
But, even more importantly, this expertise/specialty has a definite shelf life. Imagine if you’d specialized in Pascal or Perl or something at one point.
Don’t even know what those are? Yes, exactly the point.
Start with your Domain (or a Domain You Like)
I get questions all the time about how to pick a specialty, so I can appreciate how hard it is.
I think the thing folks struggle with most is concern over picking the wrong thing and a subsequent sentence to a life of drudgery. But don’t let that concern stop you.
You can always tweak or even fundamentally change your specialty later. But you can’t get back the years you spend dithering.
So start simply and consider the domain you work in.
For example, I once worked at a company that made hearing aid software. I left that company to take a job with an app dev body shop, which wasn’t a great move in terms of a specialty. (In fact, app dev body shops tend to lionize the generalist mentality).
Instead of that particular move, perhaps I should have sought out another hearing aid company. Or, I could at least have sought out a medical device company. Or maybe something related to acoustics.
Whatever the specifics, you can go from “software generalist” to “I help companies with software related to acoustics” pretty easily. When you do this, you may actually get the opportunity to bounce around plenty among tech stacks as you keep your focus on the domain. Variety is the spice of life, and all that.
Specialize by Company/Employer Profile
Another specialist avenue you have for getting a career edge (in interviewing, networking, etc) is to specialize in working for a certain type of company.
Instead of “I help companies focused on acoustics,” you say “I help startups” or “I help companies opening new office locations.”
The number of specific company profiles out there might surprise you. Of course you can slice by size (enterprise, mid-sized, etc), but that’s not a serious differentiator. Instead, think of things like targeting non-profits, associations, utility companies, or whatever. This has a fair bit of overlap with domain, but it isn’t the same thing exactly.
Specialize in Methodology/Philosophical Approach
If neither committing yourself to a problem domain nor sticking with a specific type of company appeals to you, you could always look at methodology. In the broadest terms, the first two focus on the “what and the “who,” respectively, while this focuses on the “how.”
I cringe a little to mention something so overplayed, but agile is the most obvious example. You could, effectively say, “I’ll help whoever with whatever, but I’ll only do it for companies that are agile.”
When you go this route, you make yourself more appealing to organizations that select on this basis. And something like “I do agile” is an evergreen concern, where each experience you have builds on the last.
Of course, it doesn’t have to be agile, per se.
Personally, I’ve had a lot of success with the TDD approach, which is also both evergreen and methodological. Pick from all sorts of possible options: DDD, BDD, lean principles, formal methods, specific agile flavors, etc.
Find one that works for you, that you grok, and that you really believe in, and consider specializing in it.
Power Through the Option-Maximizing Impulse
Have I listed all of the ways that you might specialize? Obviously, not.
My aim here was to give you a few easy ones in order to get the creative juices flowing. You’d do well to pick any one of the three simple things I’ve listed. But you’d also do well to mix and match them or to use them as inspiration to pick something else altogether.
But, whatever you pick, understand what you’re fighting back against.
You’re fighting back against the experience tuple and the impulse to blindly make yourself attractive to the widest possible array of employer-suitors out there. Remember, you don’t need 100 or 1,000 jobs — you need one.
A specialty helps you filter out the noise, the bad fits, and the things that won’t interest you so that you can focus on better opportunities. It also makes you a more attractive candidate and qualifies you to earn more. Oh, and if you ever do want to blast out of the salaried world and go off on your own, you’ll be in much better shape.
So don’t look at specializing as something that freelancers and entrepreneurs do exclusively. Look at it as the way to have a career instead of a series of gigs that are less than the sum of their parts.
No Fields Found.
I wish I had read this advice 15 years ago. It makes such perfect sense, but now cresting that 40-mark, I have some recovery to do. Having worked at a couple large companies, I have always gotten the sense they want “full-stack” developers. I then watch, as myself and other hires, get shuffled from project to project based on need, sometimes in a completely different technology then what they are hired for. What are your thoughts on an environment like that for a developer?
I’d say it depends a lot on what else the environment has to offer. Meaning, an environment like that definitely pigeon-holes you into “commodity laborer/generalist” so that you can be a pluggable resource in as many contexts as possible. (An entirely rational approach for them, by the way.) This isn’t great for your prospects outside of the company, except perhaps being generally employable as long as you keep drinking from the new tech firehose. But they might offer you such awesome other benefits that you never want or need to leave. They might offer to shunt you into management and… Read more »
The good news is this is all fixable if you have good skills and a good reputation. I transitioned into education because I wanted to, and the desire to work in the domain + good skills + my willingness to study and prepare was enough to make me attractive to the right organization. What programmers (and all job seekers) need to get better at is telling their story very quickly. Like in 2-3 short sentences. Who are you? What do you want to do (even if it’s something new)? Why do you want to work at my organization? Answering those… Read more »
Very well said — I agree with everything here.