The Full Stack Lie
It's pretty common place to see adverts and companies looking for full stack developers, this of course makes a whole lot of sense for smaller companies they want that jack of all trades that generalist to plug the many gaps they just don't have the budget for. But really what is a full stack developer and should it be a title we hold with such high esteem?
Software engineering is a huge amorphous area that seems to only get less well defined each year. There is always the next big thing, new paradigm, new philosophy it is a very dynamic field that doesn't ever stay still, which is one of the best and exciting things about the profession but it of course can be one of the most tiring as well. This of course means no one person nor one group will ever know even a fraction of knowledge required even in one small area let alone in the field more broadly and you know what that is ok.
T-Shaped Developer
One of the common ideas, and one which I personally like, is that of the T-shaped developer which means you have a broad understanding in many areas but have one speciality which you have a deep understanding and knowledge of. Which can mean for example you have a strong understanding on databases and know a great deal about this area but you have some frontend experience, can setup a server with a CI/CD pipeline, generally knowing enough of everything to get momentum in all areas but you have a much deeper understanding in just one segment that you focus on most of the time.
I really like this model because you become proficient across the stack making it easy enough for you to work in a range of areas, to me this is probably the closes you will ever realistically get to full stack as there is just not enough time to learn one specality let alone many. This also means it is very important to know your strengths and weaknesses.
The more you know, the more you know you don't know
This quote pretty much sums up software engineering, and well life in general but due to engineering being just so big developers often hit peaks and vallies along their career and these vallies can really only be overcome by more learning and starting to understand what you thought you knew may no longer be completely true... It is a pretty interesting issue I see in developers they get to a stage they are competent at something and this is generally in stages:
You start off not knowing anything then you learn the basic language syntax and the building blocks (conditional statements, loops, variable assignment) and you are able to accomplish quite a lot but it is all in one file and messy so you hear about OOP and you break things into classes and then someone tells you about seperation of concerns and you start pulling out business logic; next you are told automated testing is a must and you start unit testing the business logic; next you hear functions/methods should be small and reusable so you refacor split and combine common functionality and this just goes on and on the important thing to realise is this cycle never ends, it just changes and you always need to challenge your current position to improve.
I've seen and worked with many good developers who didn't really progress as quick as they could or get better jobs which they are suited for because they get too comftable in what they know and as a result struggle to move up into new roles in the current company and rarely look outside. Now, this is fine if you are the type of person reading it thinking that is me and I have no issue, it is more aimed at the people who feel frustrated they are over looked for a promotion or can't find a new higher paying job this is generally the reason.
Conclusion
For me I am first and formost a frontend developer that is the side of the stack I'm most interested in I have a lot of experience with React but I don't want to pidgeon hole myself into being that specific as that is a different danger and although the modern frontend frameworks/libraries (Vue, Angular, React) are a bit different if you focus on core JavaScript funidmentals, CSS understanding then actually picking up any of them is fairly managable and once you are strong in one the others are fairly quick to get up and running with.
It is also interesting to note that although JavaScript cuts right across the stack I wouldn't be as confident working in a full backend JavaScript role at the same level as I am on the frontend. I can and have worked with Node mostly in Express and Koa and enjoy them enough but I just don't have the knowledge in building out a backend to produce something as well designed and put together as a backend JavaScript engineer. Though if I joined a team of strong engineers I would have little issue getting up to speed and producing high quality code I just wouldn't expect my own backend solutions to be as efficient.
I feel this problem magnifies a bit when you get backend engineers working on the frontend as they differ quite a lot, especially if their backend experience isn't JavaScript, but even if it is the style is still notabally different and then don't even get me started on CSS that is a whole other thing that I still struggle with, I find more backend developers just trying to make JavaScript do what CSS should be doing becuase they generally understand that a bit better but usally not so much better down to the unique nature of JavaScript.
When it comes down to it Full Stack is a compromise because it has to be. Ideal as developers we should say I am a (Frontend engineer) with experiance across the stack in X Y Z as this helps to show our commitment to doing something to the best of our ability but not losing sight of the bigger picture. Trying to spend so much time and energy in everything will lead to a lot of wasted time, burn out, and a struggling developer. My advice will be try a bit of everything and when you find something you enjoy/ understand more consider making that your specality and stop saying you can do everything to the same standard because we all know this just isn't true...
Photo by Kevin Noble on Unsplash