The Mythical Fullstack Developer

Photo by Greg Rakozy on Unsplash

The Mythical Fullstack Developer

I have been thinking about the so-called Fullstack Developer role lately, and I wanted to get some things off my chest.

I don't like the term. It is misleading, and more importantly, dangerous for entry-level developers who are joining our industry. The thing is that the term means different things for different people.

On the one hand, it is used to describe the work of those backend developers who could move up the tech stack and do frontend work with HTML, CSS, and Javascript. But, doing frontend work or feeling comfortable with it is way different from being good at it. I am not saying that these individuals do not exist, I am sure they do, but they are rather exceptions who were presented with unique projects and opportunities to expand their skill spectra. In any case, I am still skeptical that someone is good at writing multi-thread management applications and CSS. In this context, the term Fullstack Developer by definition encloses some seniority and comes with a payload of discredit and underestimation of the frontend work. It is diminishing the relevance, importance, and careful thought needed to complete professional frontends in 2021. No matter what framework or architecture you use (SSG, SSR, SPA) ... you need specialists to take care of frontend work.

On the other hand, the term's meaning started to shift recently due to the surge of serverless and infrastructure as a utility. Let me put it this way:

All architecture is design, but not all design is architecture. Architecture is when we make significant design decisions, where significance is measured by the cost of change.

Where am I going with this? With serverless and the modern cloud, developers can make significant design decisions at a lower cost of change. In the past, with physical infrastructure and even IaaS, reverting a lousy design decision meant a complete refurbish of the servers and even contacting vendors to supply new material. Now instead, if you screw up your design by using AWS DocumentsDB because it is too costly, you can switch to AWS DynamoDB with way less cost of change. Also, if you decide to write an AWS Lambda function for some piece of work and find out that it does not scale well, moving it to AWS Fargate or ECS with auto-scaling is relatively more straightforward.

What does this mean? It means that it is now way more accessible for frontend developers to step into the structural design work (aka Architecture). Does this make them fullstack developers, as many suggest? No, it does not. Similar to my point above, if a given developer is good at CSS and NextJS and can decide how to deploy their stuff with serverless components, this does not make them a Fullstack Developer. I refuse to think that someone is still skilled at CSS, NextJS, and NoSQL database optimizations or event broking at a professional-grade level. The term here also comes with a payload of underestimating the importance and relevance of backend work.

Again, I am not saying that these profiles do not exist as individuals in particular cases. However, I am skeptical about companies who use the term extensively in their job title architecture, especially when it comes preceded with the label junior. It just does not make sense.

Since the term was originally coupled to the use of the MEAN/MERN stack, maybe what the community meant was just JavaScript Developers? Why didn't we use it? There is nothing wrong with that. If that is the case then, the term also denotes a bit of underestimation of the language as if it was a toy not ready for prime time. In any case, the fact that we could use the same programming language across the stack does not mean that one can be good at every stack layer.

Even within the context of the same programming language, the term fullstack developer is not very accurate.

Folllow me on Twitter!