The generalist path is about the long game. It is not about gaining your next programming job. You are now in your first, second, third, maybe even fifth year as a professional programmer. The generalist path is about your tenth, twentieth, or even fiftieth year. Who knows what tech will be hip? I don't, and you don't, but you can prepare yourself.

The Generalist's Path

You lay your groundwork at school, boot camp, or independent study. During that time you are aspiring to become a programmer but are not there yet.

I would say that you become a programmer the first time you write valuable code – when someone is willing to pay for the results of your programming skills or your programs are otherwise valuable to someone. For me, that point was a set of shell scripts that powered an email discussion list in the mid-1990s.

You progress as a programmer by doing valuable programming work – writing new valuable code, or maintaining old valuable code. At first, you learn the trade of programming at the same time as you learn your current tools. This takes maybe a full-time equivalent of a year or two – for me, since I was not working full time as a programmer, it took me maybe five.

You cannot be a proficient programmer without being intimate with at least one set of tools. At this point in your professional life, you have to specialize (or choose a non-technical track). The smartest thing at this point is, I think, to embrace the goal to become T-shaped: you dig deep in one area of expertise, but you do enough of other things to go beyond Dunning-Kruger in all the other programming specialties.

At some point, you will be professionally capable. You know the tools and all the usual tricks of the trade. Now you have a choice: do you pursue the path of a specialist or a generalist?

A specialist is like the oil drill: they go very very deep in a very very narrow area to be able to find the oil. In their narrow specialty, a specialist is unbeatable. It can be a very lucrative approach, selling your special skills at a high premium as a consultant. Eventually, technology moves on and the narrow specialty becomes less valuable (or outright obsolete).

As a particular specialty becomes more and more obsolete, the demand for your specialist skills diminishes. The same happens to other people in your specialty, and the specialty premium you all could charge diminishes. Specialist employees get laid off and find it difficult to find another job at the accustomed salary level. Specialist consultants and freelancers find they have to give more and more discounts to find gigs.

The generalist start from the same t-shaped professional, one who has dug down on one specialty and studied enough of all others to be dangerous. Where the specialist continues to dig deep along one line, the generalist starts digging more lines down. None of them are deep, but there are many. Over the years and decades, the generalist accumulates so many downward lines of varying lengths that they no longer are T-shaped; they are more what Dave Rooney calls icicle-shaped and Scott Ambler calls a generalizing specialist or a specializing generalist.

Rooney's simile of an icicle shaped person is quite fitting. Each downward line – a single icicle – is developed over time, maybe in one or two jobs of full-time employment, or in many consulting or freelancing gigs. Once the generalist moves on to something else, that particular icicle stops growing and eventually melts away, unattended. Yet, some of the old expertise remains for a long time.

So, Generalist is Just a Full Stack Developer, Right?

A generalist is (usually) not a full stack developer. Let me start with the history as I remember it.

The idea of assembling a software system by stacking components off the shelf and scripting the custom functionality is very old; certainly, it was well understood and practiced in the 1990s. By the turn of the millennium, it was commonplace to assemble web sites by having a MySQL database together with either PHP or Perl scripting an Apache web server on a physical computer running Linux; this became known as the LAMP stack. Being a web developer meant being able to wrestle the LAMP into submission; you also had to know HTML but that was fairly elementary at first.

In the old days, web browsers competed fiercely for market share, each trying to differentiate from others by adding incompatible features and implementing existing features differently. Getting all the various competing web browsers to do what you want (provided it was not something very simple) was akin to a dark art. As the state of the art grew, it became natural for some developers to specialize in that dark art.

Over time, the skill sets diverged so much that the job title web developer came with an obvious follow-up question: are you a front-end (web browser scripting) or a back-end (server side) web developer? Some people do both, typically as solo developers working (or contracting) for small businesses. However, the answer "both" is not very catchy. It is only natural to extend the "stack" to include all the web browser scripting as well, and so such people started being called "full stack".

We can naturally extend the "full stack" to non-web contexts as well. There are full-stack mobile developers (indie app developers being one category). There could be full-stack business intelligence developers, doing everything from extract, transform, load pipelines through data warehouse development to BI visuals by themselves.

What all these have in common is that being "full stack" makes only sense if you are working alone. Maybe you are an indie developer working your solopreneur SaaS. Could be you are a single freelancer taking solo gigs from small businesses. You could even be the technical co-founder of a venture track startup. I am the full stack developer of The Generalist Programmer website, as it is my solo side project.

To be full-stack means having to be a jack of all trades. You do not get the luxury of mastering any part of your job; there is no time. I would advise anyone seeking to be a generalist developer to avoid being full-stack full time. As a side project it is a natural and useful choice, and it allows you to develop more lines down than you could in your regular specialist job. However, as your main gig it prevents you from gaining the necessary depth in what you do right now.

That does not mean that the "full stack developer" job posting you are considering is not worth exploring. Plenty of recruiters use titles that do not accurately describe the role. For one, recruiters are often looking for personalities that they expect to bring new value to the business instead of looking for square pegs to ram into a square hole. My own current full-time job was advertised using a made-up title that was never spoken of again and certainly is not used to describe my current role.

Specialize in the Short Run, Generalize in the Long Run

To be a competent programmer, you have to treat your current job like a specialist. Figure out what your competitive advantage in your current team is; that is, what are you better at than your teammates, and seek to do those parts. Get better and better at what you are doing right now.

To be a generalist, you cannot stay in the same specialty too long. Once you get good enough for your current team's needs, look for a new niche to occupy. If your current employer is looking to adopt new tech, take initiative in exploring the options and proactively learn enough to be dangerous. As you gain experience and seniority, deliberately take on responsibilities you have avoided and learn them. If your current employer does not provide you opportunities, seek them elsewhere, either in side projects or by moving to another employer. In fact, if you have the time and energy, side projects exploring tech not needed at your works are a good idea even when your employer continues to challenge you in good ways.