** If you're a generalist with a full stack title, this article isn't about attacking your valuable contributions to your Team.
TLDR: just skip to the conclusion i guess
Intro
The term has been gaining popularity for quite some time now, and it makes sense, because on paper it sounds like a good idea. As someone who works on web related technologies, you want to be seen as proficient in every possible area of the stack, thereby increasing your hireability. As someone who leads an engineering team, you want to be able to hire individuals who can contribute seamlessly to every area of your codebase. While sounding like a great idea, this concept is untenable for several reasons.
Every Stack is Different
There is no specific set of technologies used to create an end to end web application. There are an endless number of programming languages, server frameworks, database platforms, preprocessors, and package managers to choose from, all geared towards solving specific issues that vary depending on the type of application you’re looking to build, as well as the experience of the team responsible for maintaining the application. At best, identifying as a full stack developer can only mean that you’re proficient at contributing to every level of a particular stack that you’ve used in the past. Any hiring manager looking for a full stack developer is really just looking for someone who has worked with every piece of technology that the hiring company is currently using to deliver web applications. At the same time, they’re ignoring those who focus on other technologies and practices that may greatly improve the usability, functionality, and capabilities of their current application.
Specialization is Important
Even in a land of self titled full stack developers, there are technologies that some of us will be more comfortable with than others, and vice-versa. A developer with a CS degree may sometimes be more interested in GO, Rust, and Node, than a self taught developer who transitioned into the field learning about CSS in order to change a background color on their WordPress blog. While there’s absolutely nothing wrong with these differences (as both serve necessary purposes), it’s entirely unfair and irresponsible to expect both developers to contribute to the same parts of the codebase with equal proficiency. Even those with full stack titles tend to gravitate towards technologies they’re most comfortable with after joining an engineering team. A focus on full stack developers tends to ignore these differences, which in turn goes on to negatively affect the health of your application.
Full Stack is Bad for your Application
A job posting for a full stack developer has a tendency to attract a particular type of candidate. Usually this is someone who is comfortable with highly programmatic languages while having a small bit of experience with CSS, HTML semantics, accessibility, and front end performance. This makes sense in an environment where Javascript is emerging as a dominant programming language, and new developers are starting out by learning that first. As a result, other equally important facets of web development take a backseat, and are supplemented by a proliferation of frameworks and tools designed to make these less-paid-attention-to areas easier to manage. In a world where proficiency in Javascript can make you a lot of money, it may sometimes feel like a good decision to only focus on Javascript throughout the lifetime of your web development career. This pattern has led to a few unfortunate trends that can be found in a large number of web applications.
The largest (no pun intended) issue that has emerged as a result of a focus on full stack developers is that of performance. It has become routine to see web applications needlessly delivering hundreds of kilobytes images, CSS, and Javascript down to a user on first page load. Most of the time, these performance issues are due to nothing more than a lack of attention to front end performance by developers who are not interested these areas of web development. As a hiring manager, there’s nothing wrong with having developers on your team who don’t focus on front end performance. There is however something wrong with having no one on your team to focus on it.
Another issue that gets less attention than it deserves is that of accessibility. Making an application accessible for users with disabilities starts at an HTML level, which is a highly disregarded area by most full stack developers entering the hiring market (which is not the developers fault, it’s often ignored by schools and coding bootcamps alike). If you lead an engineering team, enabling your application to serve the largest number of users is an obvious and profitable strategy, and cannot happen without a developer on your team to focus on accessibility.
The final issue I’ll touch on for the sake of brevity is that of emerging features and capabilities in front end technology. Service Workers, responsive images, new CSS layout modules, push notifications, and background syncing capabilities are all features that the front end web is capable of handling today, but are nearly unheard of by a large majority of full stack developers because they require a special level of focus outside of the traditional skills mentioned in a full stack web developer job posting. Again, there’s nothing wrong with being unfamiliar with these technologies. There is a case to be made that an application loses to competitors when the team that manages it is packed with full stack developers who don’t specialize in these emerging areas.
Full Stack is Bad for your Hiring Pipeline
I’ve attended several interviews where technical evaluations have included nothing more than a few algorithm challenges and Javascript framework specific tasks (such as implementing a sortable table with React). Lately, these are the only technical evaluations that I've been subject to. It emphasizes the full-stack driven thought pattern that emphasizes backend capabilities over user interface development. As noted earlier, this can go on to negatively affect the overall health of an application. Hiring should be more holistic, focusing on individual strengths and weaknesses while scrutinizing a candidates overall potential to contribute to a team.
Conclusion
Moneyball was a good movie. It teaches a valuable lesson that applies to more than just baseball: Individual contributors bringing different strengths and weaknesses add up to a team that outperforms a roster full of MVPs. Being a full stack web developer sounds great on paper, but in reality, often translates to a team that lacks knowledge in specific areas of application design and development. Specialization and balance can fix this issue, and improve the overall health of your application. Hiring managers, team leads, coding bootcamps, and individual contributors should toss the full stack idea, because the stack is very big and very complicated - and you might just make a better app when you hire a CSS expert and a Kubernetes veteran, instead of two full stack developers who don't yet know what your stack is.
Top comments (39)
I consider the term "full stack" to have a different meaning from most people ( i guess ). I think you can be considered full stack when you reach enough knowledge to be technology agnostic, and use the most appropriate technology to solve the task, even if that means learning something new.
After you get deep into a couple frontend technologies and a couple backend technologies you start thinking by design/architecture instead of language constraints, and that allows you to easily take into any other language as needed
"No, Johnny, I'm telling you... you don't exist. You're not real."
It comes across as a bit insulting to invent reasons to tell people why they shouldn't exist.
Just like Johnny, full stack developers do exist, and they fit very specific roles and circumstances.
Where I believe the author has questions, the article jumps to assumptions and conclusions instead of just asking the questions and getting real answers.
There are full stack developers, that is, people who can set up the OS deployment and configuration, configure and tune the database, write the backend handling code, and code HTML, CSS, and JavaScript competently with a view to accessibility and design. Generally they began when the web was a lot simpler and just kept up. So 15 to 25 years of experience later, you have a full stack developer.
As you might imagine, such people are not cheap and are rarely on the market.
And even that is pretty limited in scope to web dev. What about embedded, systems, kernal, data science, IOT, financial & quantitative...
Absolutely spot on and would describe my career, though I consider myself a front end developer nowadays
[This is a bit of a hot take - I really enjoyed your piece! I've been trying to refine the below for the last half an hour so please excuse me if it's a little rough or repetitive, but I thought it would be better to submit it now rather than let it sit for five days and then not submit it anyway.]
It's important to me for the health of the team and the application that everybody knows how everthing works to some degree, if only so that when half the team gets the flu the other half can still change the CSS, write tests, talk to the client, etc.
I'm not demanding that the frontend specialist become a JVM performance ninja. But each developer in my team cannot be solely responsible for a single technology.
They must be responsible to the customer. The customer doesn't see a stack; they see a website. The website is either working or it isn't. The customer isn't going to complain about the JavaScript load time, they're going to complain about the website being slow.
It's the responsibility of the whole team to make sure that the website working - that's every layer of the stack. I want to employ curious and motivated developers who are willing to learn outside their area of expertise in order to better support the team and, ultimately, serve the customer.
So, yes, I'm happy to hire the K8s veteran (how veteran can you be in Kubernetes? It's like 5 minutes old!) and the CSS expert, but what's more important than their specialism is that they are more focused on their team and the customer than any particular technology.
Thanks David, I really appreciate the feedback!
We don't ever use the term 'full stack', but at my place of work we are expected to be able to learn how to make changes to everything - our legacy Delphi application, JS frontends, & JVM lang services. Some people are better at certain things than others, of course, so in that way we still have specialists.
The important thing is that people will always help others where they can. Identifying experts really helps with this, so when a question I can't adequately answer comes my way, I know exactly who to point to.
I don't think it's useful to constrain yourself to 'front end' or 'back end' - all dev work can get complicated in its own way, but I think anyone can learn enough to get by in any language, in any situation.
Disagree.
The first point, you can think of different strategies when you are proficient in different domains. Your CSS could be enhanced by knowing various visualization techniques through things like D3 and GIS (mapping). Your Kubernetes could be enhanced by knowing about distributed systems, networking, systems analysis, configuration management, etc.
Second point. You need less full stack developers than if you were to hire an expert in every different area and these developers would be more efficiently utilized. What does the CSS expert do when the UI is completed but there needs to be some back end work or cloud configuration done? What does the Kubernetes expert do when the app is being developed and no services/cloud configuration is needed?
The third point, Full stack developers are generally the more experienced developers and can bring other skills to the table like troubleshooting, QA, mentoring, product planning, and communication, project mgt., etc.
As a full stack developer, I believe (and have demonstrated) that I can perform at an expert level in a technology in six months. That comes with (a lot) of practice in jumping into the deep end and learning to swim when deadlines loom.
It takes a lot of confidence to genuinely believe that you can master any technology in six months.
That aside, D3 is a rather large library that can heavily impact the overall performance of your app - medium.com/@PepsRyuu/why-i-no-long...
I have made a career out of fixing performance and front end issues in apps built entirely by full stack teams. There are libraries and tools for everything, and your Kubernetes expert might have a tough time assessing why one of them adds 100kb to your CSS file
I didn't mean to include D3 I meant that after using D3 you will know things like what a Dendrogram is and how to use it to visualize a dataset. Knowing this (for example) might give you ideas of developing a similar visualization in CSS.
One thing we might agree on (or not) is hiring. I don't believe in technical tests, take-home projects or really any demonstration of mastery of any particular skill set. When I interview and hire I mainly look for two things:
Does the individual truly love the art and science of software development?
Are they a self-starter? ie. do they go out and learn new software development tools, techniques, ideas, etc. on their own without having to be told to do this?
To the extent that both of those are true, you're hired!
Clearly you are considering only the tech parts, but from a business perspective that makes no sense in most cases.
First you will have to hire at least 5 specialists to replace 2 full stack devs.
2nd you will not find those specialists, your HR will look for at least 1year.
Also they will cost at least 4times more and the app would be delivered later with more costs.
Also you will be suprised but some full stacks are better than the experts at their mastery, just because they learn more and have more experience.
Interesting take. I generally agree with you. I had a take on this about a year ago (same title, in fact) that has a bit of a different focus. dev.to/remotesynth/theres-no-such-...
This is a better & nicer version of my article. Excellent work!
I completely agree that a quite a lot of front-end applications that make it into production are underbaked, bloated, error-prone and often inaccessible to folks. I personally think this is due to the dangerous categorization of front-end work as "simple" or "junior," rather than a result of the idea of a "full-stack developer."
This is where I disagree a bit - when my team hires a new developer, we use the term "full-stack" as a goal to be continually worked toward rather than a criteria for entry. Every member of our team is expected to familiarize themselves with the different aspects of the applications their team is responsible for - whether that be on the server, the client, or the infrastructure and processes we use to ship and support software. This helps us collaborate well, and decreases the bus factor in general! As a way to build that familiarity, we all strive to work in the different languages and codebases that make up the system.
That said, we do encourage specialization and highly value expertise! For example, I work on codebases in React and Ruby, but as my expertise is higher in serverland than UI-topia (excuse my silly puns), I lean heavily on my front-end-focused teammates for their experience by pairing and/or requesting their reviews before proceeding.
I agree that no one person can be an expert in everything web-development-related. Everyone's got different strengths - it's up to the hiring manager and team lead to ensure we're building a team whose strengths complement each other; that we don't end up with holes in our knowledge as a group.
I think one of the issues is the defined term, "Full Stack" means different things to different developers. For me, It used to mean I can build an application in whatever front-end framework or even Vanilla.js with an MVC pattern and Observables to glue it together and the ability to create a REST API to persist data. Unfortunately, after I got a job I realized I knew almost nothing about the back-end other than the api part. I know my way around Express.js, Restify and other similar backend Node.js based frameworks but I couldn't actually deploy anything at scale. I can build a MEAN/MERN stack app like nobodies business but god help me if I'm by myself trying to load balance anything, cache resources, setup reverse proxies, setup server monitoring/logging, dev-ops tool chains and a plethora of other things in the stack that are required to handle millions of connections. I've been humbled by it all and I slowly want to learn more but it's a long road that a 3 month boot-camp will never be able to teach.
I disagree with this. The comolexity of your work as software engineer doesn't have to do with your diplomas. We are made of experience and training/learning. The more valuable engineer/developer is made of a large test/error life: there resides his expertise.
I mostly agree with the above, well said.
Still for small teams/projects "Full stack" knowledge might be valuable in the sense that this developer is not the expert in all situations but has enough knowledge to make decisions on his "field" without calling a meeting every hour.
Found this on Reddit, still makes me laugh
People wearing fedora hats will tell you that you are not a full-stack engineer, unless you are smelting your own copper.
I guess that everything depends on the scale. If your project is highly complex, mixing lots of technologies, and with an over-complicated infrastructure, it will be hard for anyone to be able to understand all the parts.
On the other hand, for instance, in my scale, a lot of Rails developers are "full-stack", in the sense that they can develop a feature entirelly by themseves. That means, from deciding the schema of the database, writing the API, coding React/Redux, and writing the CSS.
Of course, it is good to have specialists, but having people who can do anything is useful as well.
man i guest i'am full stuck