Photo by Martin Sanchez on Unsplash
Full Stack Developers: The Good, The Bad, The Ugly
Full Stack Developers are a thing...but there is a lot more to consider.
I am, or have been, a Full Stack Developer. And by that, I mean that I have worked and continue to work with both the front end and backend of a software project. I was afforded the opportunity to attend Microsoft's Live! 360 conferenced in Orlando, Florida in November of 2019 and one of the main events was a discussion on this topic. It has been on my mind ever since.
A lot of job postings prefer people with experience as Full Stack Developers as opposed to developers with specialized experience. You will find a number of tutorials on how to become a Full Stack Developer. Is being a Full Stack Developer a good thing? For you? For the employer? I personally believe that the answer to all three of those questions is both yes AND no.
The Definition
If you were to search "what is a Full Stack Developer", there will be a variety of definitions. However, I want to highlight two.
A full-stack web developer is a person who can develop both client and server software.
A full-stack developer is a programmer who works within software development and is knowledgeable in both the front end and back end of an application.
Those both sound very similar and basic. But I want to compare two statements further down on each page.
From W3Schools.com (under Advantages):
- You can master all the techniques involved in a development project.
From indeed.com (just three sentences below the definition):
It's important to note that as a full-stack developer, you're not required to know everything, but having an overall understanding of what's going on in the front end and back end is key.
It is my experience but even more my opinion that very few people, if anyone, can master all the techniques involved in a development project. I lean more towards what indeed.com says.
What is in the stack?
Again, what is in a project's stack can differ wildly. Here is another quote from the same W3Schools.com article that shows just a few stacks (focused on Popular Web Development):
LAMP stack: JavaScript - Linux - Apache - MySQL - PHP
LEMP stack: JavaScript - Linux - Nginx - MySQL - PHP
MEAN stack: JavaScript - MongoDB - Express - AngularJS - Node.js
Django stack: JavaScript - Python - Django - MySQL
Ruby on Rails: JavaScript - Ruby - SQLite - Rails
These are just the popular ones. There are a bunch more that are less popular that are still widely used.
At my current job I work on at least five projects. Some of the projects have similar components, such as SQL Server backends. But at present one of those projects is using SQL Server in the Cloud and the other four are on-premises. Some of the projects use VB.Net and some use C#. Some use JavaScript, some do not. Some use Dapper, others use EntityFramework. Some are .Net Framework and others are .Net Core. I think you get the picture - there are a lot of different stacks.
I would also argue that there is more involved with a tech stack than just knowing the language. Anyone can run a build command for a project in a deployment. But can that person do it efficiently? Do they know how to make it build faster? Do they know what gets deployed? Do they know how to minify and obfuscate javascript? Do they know how to maintain code secrets? Do they know how to write all sorts of tests (Unit, Integrated, Front-End, etc.)? There are so many aspects from development to deployment that people miss because they are doing too many things to become really good at a few.
The Good
While I may not agree with the advantages W3Schools.com mentioned, I do believe that there are some good things about being (or trying to be) a Full Stack Developer.
Career Longevity
By working with all components throughout a project's stack, you are exposed to different aspects of software development. If you needed to find another job, the breadth of available jobs would be wider than that of someone who has specialized experience.
Higher Salary
Showing the ability, even if it is not mastery, to work on all levels of a tech stack is very enticing for employers. Most employers, though not all, would rather pay more for a single Full Stack Developer than two, or three, or four specialized developers. It is a cost savings for them, but a monetary gain for you.
Better Troubleshooting
Having a basic to advanced knowledge of all areas of the tech stack may increase your effectiveness in troubleshooting issues within the project. This can shorten project downtime and increase user experience, leading to a better overall product.
Never Bored
As a Full Stack Developer, you should have the comfortability to work any ticket (for the most part). This can be very beneficial to the project which bodes well for promotion and/or pay increases.
The Bad
It would be great if there were only advantages to Full Stack Developers. Unfortunately, there may be more bad than good.
Lack of Focus
There is a common phrase: "Jack of all trades, master of none." As I stated earlier, I believe it very hard for anyone to master all levels of a full tech stack. Many Full Stack Developers may be closer to T-shaped Developers who specialize in one area but are able to touch other areas. What happens if you hire a bunch of "Full Stack Developers" that are really T-shaped Developers and all of their specializations are the same area? Then you get a team that is great in one thing and mediocre at best in other areas.
This is not your problem; it is the employer's problem. But if you find yourself on a team like this, then you could be asked to do things you struggle with which could risk your employment.
Noise
Who should get pinged if there is a database problem? Who should get pinged if there need to be accessibility updates? Who should get pinged if Security found some vulnerabilities? Who should get pinged if deployments are failing?
Maybe each of these areas have some specialized employees: DBAs, System Administrators, a Security Team, etc. However, because a team may only hire Full Stack Developers, EVERYBODY gets pinged. All of the email, all of the Teams or Slack messages, all of the phone calls, etc. It can get noisy very quick.
Expectation
Because you are a Full Stack Developer, there can be expectations that no matter the work item, you can (and maybe should) pick it up. Some employers also mistake Full Stack Developers as masters of everything, meaning that whatever ticket you pick up you should be able to do it right the first time. Again, this is not your problem but your employer's - you are just the victim.
Changing Stacks
Let's say that you get hired for a job, you learn their current stack, and you become extremely proficient in that stack. Then the company decides that it needs to make a shift and wants to use a different stack. That shift may need to be quick depending on the business' needs. Your ability to shift to this new stack may not be as quick as the company wants/needs it to be or may not happen at all - which puts you out of a job.
The Ugly
Yes, there are some pretty ugly things when it comes to Full Stack Developers... All of these may not be the fault of the Full Stack Developers themselves, but simply because Full Stack Developers are a thing.
Company Overhead
Assuming a company paid $100,000 for every employee, do you think a company would rather pay a Database Administrator, a System's Administrator, a front-end developer, a server-side developer, a designer, and a security developer or three Full Stack Developers? That is a cost savings of $300,000 per year. And that may be per project.
Why is this ugly? Personally, it is again because I do not believe most Full Stack Developers are masters at everything or anything. And in this example, even if they were T-shaped developers with different specialties, you would have three developers really good in three of the six areas and "ok" in the three others. That may be good enough for the company but could provide a horrible experience for the developers and users of the product.
Ego
There are some Full Stack Developers that are REALLY good. And some of them do not hesitate to let you know that. "I've done this before." "I'm used to doing this." "Why can't so-and-so just do this?" "Why do I have to go behind other developers and fix their mess?"
People with this attitude can be toxic to a team environment. These kinds of Full Stack Developers care not to bring everyone else up with them but run full steam ahead telling everyone else to catch up. This can cause the other developers to intentionally push back and/or leave a project/job.
Companies love these developers because of their output and may even start using them as a bar for what the other developers should be doing, putting the other developer's jobs at risk. And if the company tries to build a team of solely these types of developers, people get to butting heads and team or company culture could be drastically affected.
Burnout
To know any one aspect of software development very well takes a lot of effort. Some languages, frameworks, libraries change very frequently and may require recurring training to stay on top of them. Take for instance React.js. The first version of React was released in May of 2013 - that was 10 years ago. The current React version is 18.2.0, which was released in June of 2022. That is 18 versions in just over nine years, or two versions per year. Every major version number change likely means new and/or deprecated functions.
Just staying on top of React could be a full-time job. But then to also stay on top of the database changes, security changes, accessibility changes, authentication changes, libraries you use changing, etc. is exhausting. Again, it is entirely possible to be ok to good in all of these areas and that may be enough for some people or companies. But is it ideal for the users of the products, the team environments, the company culture, etc.?
Conclusion
I am in no way saying that people should not be Full Stack Developers. Many developers are Full Stack Developers either because their job required it, they intended to learn the whole stack for career reasons, or it just happened organically. I love having an understanding of all aspects of my projects. But just because I love it does not mean that it is possible, easy, or good.
I plead that any employer reading this not over burden their developers in an effort to save costs. The better the developer's workload/expectations, the better your work environment, the better your output, the higher chances of more users, the higher chance of higher revenue.
I plead that any developer reading this be mindful of just how daunting being a Full Stack Developer can be. Please do not be afraid to learn new parts of a tech stack as you may find something others have missed. But also know your boundaries and abilities.