The End of the Full Stack Developer
Around 2009 I started calling myself a full-stack developer. In practice I was probably more of a ¾ stack developer, since I didn’t really like the front-end part and I have the visual design sensibilities of a command-line devotee. But at that time, if pressed, I could build a full web app and deploy it to a server. Since I’ve always thought of myself as a generalist, I liked the idea that I could turn being a jack-of-all-trades into a sort of speciality.
The term full-stack derives from the bundles of software used to build and serve web applications, first identified with the LAMP stack (Linux, Apache, MySQL, PHP). Although I can’t find a definitive reference for its origin, the term “stack” is certainly used because you could picture these components as layers, one on top of the other. Expertise in all of the layers sufficient to build and deploy a web app made one “full-stack”. In reality, most self-proclaimed full-stack developers are people with strong expertise in one or two layers and enough to get by in the others.
Now, 15 years later, it’s hard to remember that it was ever so simple. Back then people were starting to experiment with server configuration tools like Puppet and Chef, and bigger companies had home-grown deployment systems. But the CI/CD pipelines and infrastructure-as-code technologies that are now common were a pipe dream (pun intended). That was near the beginning of the cloud era for most orgs, but it was still common in small- to medium-size companies to copy code to servers and start it manually.
My thinking has evolved on this, however. I now believe that it’s no longer really possible to be a full-stack developer, even though there are dozens of organizations promising to train people to become one and hundreds of job ads seeking to hire one. The original idea, of being able to do everything necessary to deploy a web application, is an illusion. Nobody is a generalist, you can only be more or less specialized.
Many will object that this view depends on the size of the organization. If you’re the only dev at a start-up, you have to do everything, right? That was once true (I’ve been that solo developer), but the way people survive at start-ups now is by either ignoring some aspect of modern engineering or by relying on tools that are built into your cloud platform (essentially buying rather than building). For example, the site you’re reading was deployed from CloudFlare. I didn’t have to build a deployment pipeline, I just pointed the platform at a GitHub repo. I didn’t have to worry about web server configs or certificates or even provisioning virtual machines.
There are still people who can write code at every level of the stack, build deployment pipelines, manage cloud infrastructure, and design systems. I know some of them, but they are rare and most would admit that they can’t really keep up with everything in every area. Specialization is the norm now, and the specialities get more narrow every year. There are front-end and back-end specialists, but also DevOps and data engineers and UX specialists and ML ops and security engineers and performance engineers, etc. My focus for years has been toward data engineering, and I still learn about new things every week.
The 2024 view of this might be: “the AIs will eventually do all of these jobs anyway.” Maybe, I would respond, but the near-term version is that AI agents will be assistants in the development process (“interns” seems to be a term growing in favor). Using them well will require a new skill, maybe even a new speciality. There’s already an emergent field of AI engineering, which requires knowledge of prompting techniques, semantic search, and agent construction. People who can program GPUs are in high demand. I’d argue that even skill with libraries like PyTorch and TensorFlow should be in the toolkit of not only data scientists but also many engineers building applications.
In truth there is no stack anymore, more of an ecosystem in which the components contribute to different degrees depending on the type of application. Sure, there are still web and mobile apps that serve up data or let you buy stuff. There are still browsers, web servers, application servers, databases, and operating systems. But if you look behind the scenes of even basic applications, you’ll see orchestration platforms, analytics pipelines, observability frameworks, and security monitoring. You’ll see load balancers, application gateways, event streaming, and task queues. This is not only at FAANG or Magnificent Seven companies, it’s the reality of any technology-driven business.