The Myth of the Full Stack Developer

Perhaps you have heard this statement before - a full-stack developer is a myth. If you are one, it might even invoke some kind of reaction within you. But before you react and all that coffee we drink as full-stack developers manifests itself into reactive energy, let’s take a couple of minutes understand what a myth actually is, and how the above is, indeed, a statement of fact.

Etymologically, the word myth in English comes from the Greek word mythos, which means “report” or “tale” or “true narrative”, referring not only to the means by which it was transmitted but also to its being rooted in Truth. Of course, as time unfolds and we stumble upon the profanity that modernity brings with it, we have come to associate the word myth with something that is false, or something that is not true. But that is not what it means. In fact, a modern dictionary gives 2 meanings for the word myth:

1. A traditional story, especially one concerning the early history of a people or explaining some natural or social phenomenon, and typically involving supernatural beings or events.
2. A widely held but false belief or idea.

So the modern definition can be classified as nothing more than a deformation of what the actual word means (notwithstanding the difference between the Greek words Mythos and Logos, but that’s another form of binary philosophy / theosophy we won’t explore); it, in fact, appears to be a negation of the truth that the original Greek word actually purported. And as mythos is how knowledge was transmitted (and still is the most effective way of transmitting it), for those who understand the religious efficacy of mythos, one might even co-relate it with the use of the word Isnad (إِسْنَاد) in Arabic or Upanishad (उपनिषद्) in Sanskrit. But that is a topic for another day.

It should already be quite obvious that by calling a full-stack developer a myth, we are in fact affirming that such developers or engineers exist. So why do people still make this statement?

Binary alert - there are 2 kinds of companies (and by definition the people that work there) dealing with technology these days (there are more, but it’s simpler to explain our conundrum with just two):

1. Those that formed or inherited their IT teams or departments and their IT Leadership from Managed Service Providers (MSPs) - I don’t need to name these MSPs, but you know who they are. These companies are the ones that still want to be delivery centric without being cognizant of what they deliver. Their software teams are managed by delivery managers, and their income was based (only in the case of the MSP) on the number of people they could bill to their clients on an hourly or daily basis. These companies were notorious (and still are, but we are not talking about MSPs for the sake of this article) for ‘creating’ a separate job role for each and every capability that a software engineer needs to ship anything that delivers real customer value. In other words, this is a largely quantitative approach to quality software engineering. And so we have a back-end developer, a front-end developer, an Operations Engineer, a DevOps Engineer, a Database Administrator, a Database Engineer… you get the gist. And so, in these companies, the myth (for once we can entertain the modern definition) of the full-stack developer is perpetuated.
2. Those that formed their IT teams or departments from the ground up. These companies understand that software engineering is not a separate function, but a way of working. They embrace the idea of full-stack engineers, and they understand that the only way to deliver real customer value with quality and on-time is to have engineers who can work on the entire stack, and not just a part of it.

You’ll find that the first kind of companies are the ones that are still struggling to deliver value to their customers and they have excessively large Software departments (they’re also usually large enterprises with little inertia).

The second kind of companies are the ones that are able to deliver value to their customers, and they have small, nimble, and highly effective Software departments (they’re usually startups or small to medium-sized enterprises).

So we might say that this a statement made in error by those who are victimised by the baggage of MSPs and their ways of working.

But not all large enterprises have to be like this.

We’ll leave the discussion around I-shaped, T-shaped and E-shaped developers for another day, too.