I’ve been pondering recently on the term full stack engineer and if full stack engineers really still exist.
I used to know what full stack engineering meant.
I used to call myself one.
For the last 7 years I’ve been a purely back end guy and haven’t really kept up with the UI trends and job market.
It wasn’t until joining X and becoming more active on the platform this year that I started noticing more and more people calling themselves full stack engineers, and I started to wonder if this was still even an achievable title for anyone.
Introduction: The Rise of the Full Stack Engineer
To understand if it’s still possible to be a full stack developer, we need to go back to its roots.
The term Full Stack Engineer was first seen in 2008, widely accredited to Randy Schmidt, Managing Director at Burns & McDonnell.
Schmidt described full stack developers to be someone who could work across multiple layers of development, from the front-end user interface, to back-end and database and complete the full software development process.
Full stack engineers work across the boundaries of front end development, back end development and databases.
The full stack engineering skill set was perfect for small companies and start ups where smaller web applications were the main focus.
Having full stack engineers who could perform all of these roles appealed to hiring managers, and generally it was feasible to know enough of each of the layers, with the limited technology and frameworks that you could achieve this role.
Initially, this would mean that someone as able to use something like ASP.Net and created the UI, the back end code and some stored procs. Full stack engineers, compared to software engineers in general, often had to master a broader range of skills across different layers of development.
Why Full Stack Developers Thrived Initially
The year is 2010.
People are leaving theatres across the world in a daze after watching Inception. The iPad was the latest and greatest tech that would change people’s lives for good and full stack developers were thriving in an environment with limited frameworks, libraries and tools.
Early web applications were less complex.
The code base was generally bundled as one. Take for example Microsoft WebForms. Your whole code base (minus the database) could be deployed as one.
Applications were generally monolithic and deployed as a single unit.
Sometimes two or three units.
The choices of technology were limited.
Enterprise products were generally made of a combination of the following:
Font End / Web Development:
HTML, CSS and JavaScript
Adobe Flash (already on the way out)
CSS Frameworks like Bootstrap of Foundation coming in
Band-End
LAMP Stack
Ruby On Rails
Java and Spring
Databases:
Relational DBs mostly
Emerging noSQL databases, but not very widespread or adopted.
This Tech stack is limited and to some extent can be tamed by good engineers.
Now comes the question.
Does full stack engineering mean that you are able to do front end, back end and database in the languages and frameworks you choose, or all languages and frameworks?
I think it would be harsh to say that you needed to know all languages and frameworks to be classed as a full stack engineer.
So by that definition, given that I knew HTML/CSS/Javascript, ASP.Net MVC / SPA etc, as well as C# back end and Microsoft SQL Server, I classed myself as full stack.
I didn’t know Ruby On Rails, but I was confident that if I needed to transition in to being “Full Stack” on Ruby, I would need to retrain my brain on the language, but not learn a whole new paradigm.
The career path for software developers wanting to become full stack was known and was achievable. Similarly, the career path for software engineers, including full stack engineers, was well-defined and achievable, with significant earnings and a strong emphasis on technical skills and education.
Technological Explosion: The Expanding Tech Stack
By the mid 2010’s, the front-end and web development frameworks were starting to get out of control.
Angular, React, Vue, Svelte, Knockout, Ember, Backbone all became prolific in the tech industry.
Some of these were created earlier than the mid 2010’s, but they became prolific then.
I remember learning Knockout.js (which I still love by the way – an MVVM JS framework!) and thinking I’d be left behind if I didn’t also learn Angular (which later did), let alone the ten other frameworks sky rocketing at that time.
The back-end changed too.
We went from mostly monoliths to micro-services.
Express, Django, Rails, .Net Core.
It was now more common to separate your concerns and have services that handled one thing and one thing well.
With the rise of separating your services, also came the rise of more middleware options with which to connect them.
Kafka, Azure Service Bus, RabbitMq, ActiveMq, TIBCO etc.
of course with all of the new complexity of having more technologies separated by more middleware, the idea of containerization (Docker, Kubernetes) and CI/CD pipelines became a must.
After all, you need to be able to test the integration of all of these components.
The Knowledge Overload Problem
It’s now 2024 and we have a problem.
Everyone wants to be part of the full stack engineers group, but the definition has not changed to match the landscape.
We now have too many technologies, frameworks and DevOps procedures for this to really mean anything.
Sure, someone can still know one UI framework, one back end technology and one database and call themselves a full stack engineer. But what good is that really? What does that define?
To be effective, you need knowledge of multiple front end, back end, middleware and database technologies.
We now have a problem of Depth vs Breadth in knowledge terms.
To have knowledge of enough of these frameworks to fulfil that criteria, you probably have a more shallow set of knowledge than if you specialised in a few.
The Rise of Specialization and the Team-Based Model
Companies in recent years (from what I’ve seen) have been replacing Full Stack with more specialised roles compared to the broader category of software engineers:
Front end, Back end, dev ops, cloud engineer etc.
These individual specialists as a team are effective. They have deep knowledge of their domain and as long as processes and communication are good, are able to build spectacular things.
Deeper expertise tends to mean higher efficiency and better quality control.
The Modern “Full Stack” Engineer: Still Alive or a Myth?
Does the Full Stack Engineer still exist?
Well that depends on your definition.
In my opinion, it’s a murky area. It always has been.
The reality is, when building large scale commercial projects, generalisers (or full stack) will need to work with specialists.
I think Indie Hackers are certainly full stack. I think small companies with smaller code bases can possibly be full stack.
Can you be an industry wide successful full stack engineer? Probably not.
People are emerging now as “T shape engineers” which means a generalised knowledge of a wide variety of areas, but specialising in one. This concept fits within the broader category of software engineers, who often need to balance generalist skills with specialized expertise to advance in their careers.
I think this is a good approach.
Polyglot engineers are happy writing code in multiple languages, but they may all lay in the same domain (back end for instance).
Are Full Stack Engineers Truly Dead?
Well that answer really depends on what your definition what Full Stack Engineers are.
If your definition is:
Knows at least one front end/web development framework
Knows at least one back-end framework
Knows at least one database
Then probably not.
If your definition is: Can apply for any Full Stack Engineers role regardless of the technologies that are required, then I would say yes, the term Full Stack Engineer is dead.
I would suggest that T Shaped Engineer is more fitting and a better target to aim for – A broad knowledge of a lot, with one or two pillar topics of expertise.
As time marches forwards, the role of the Software Engineer will change anyway. Full stack engineers fit within the broader category of software engineers, who are known for their significant earnings and diverse career pathways.
AI will be guided by human engineers to craft solutions.
Maybe Full Stack Engineers can be rekindled with the help of AI?
Who knows.
Conclusion: Embracing the Evolution of the Full Stack Engineering Roles
What’s my point with all of this.
Nothing really.
I just thought it was interesting.
I thought it was an unfair bar for people to set for themselves these days and not necessarily the career path many should take.
Full stack developer is term that was created in a time we no longer live in.
What title do I give myself? Well, a Software Engineering Manager now, but Software Engineer would be my title of choice if I wasn’t a manager.
The important thing for an engineer is that they are adaptable. That they can use problem solving and abstract skills to solve problems in any framework and language. That they can hone the knowledge that they have gained over the years to spot pitfalls and advantages to different platforms and frameworks.
Be adaptable and you will thrive.
Appendix
This is the 25 front end Frameworks that are considered “large in the market” in 2024:
React – Popular JavaScript library for building user interfaces, developed by Facebook.
Vue.js – Progressive framework focused on simplicity and flexibility.
Angular – Full-featured framework by Google for complex, large-scale applications.
Svelte – Compiles components at build time for improved runtime performance.
Next.js – React-based framework with server-side rendering and static generation.
Nuxt.js – Server-side rendering framework for Vue.js.
Ember.js – Robust framework with strong conventions for ambitious applications.
Preact – Lightweight alternative to React, optimized for performance.
Solid.js – Fast, reactive framework with fine-grained reactivity.
Lit – Web components library by Google, focused on minimal overhead.
Backbone.js – Lightweight framework that provides structure with models and collections.
Alpine.js – Minimal framework for handling JavaScript behavior in the DOM.
Stencil – Compiler for generating standards-based web components.
Qwik – Designed for delivering instantly loadable applications.
Marko – Framework with reactive components and fast server-side rendering.
Mithril – JavaScript framework with a small footprint, ideal for SPAs.
Hyperapp – Tiny framework focused on simplicity and modularity.
Aurelia – Framework known for its clean syntax and extensibility.
Meteor – Full-stack framework, but popular for front-end development with JavaScript.
Dojo – JavaScript framework known for building high-performance applications.
Inferno – High-performance, React-like library focused on speed.
Blazor – Front-end framework by Microsoft for building interactive web UIs with .NET.
Riot.js – Simple, lightweight framework for building UI components.
CanJS – Focused on building maintainable and performant applications.
VuePress – Static site generator powered by Vue, primarily for documentation sites.
The post Is the Full Stack Engineer Dead? appeared first on Just Another Tech Lead.
Top comments (0)