The term “Full Stack Developer” has undergone a radical transformation that calls for careful reflection.
Let’s start with the definition of what it means to be a “Full Stack Developer,” drawing from ChatGPT:
"Full Stack Developers" are software developers who have skills in both front-end and back-end web development or software application development. In other words, they are capable of working on all parts of an application or website, from the client-side that runs in the user's browser (front-end) to the server-side (back-end) that handles business logic and data access.Code language: JavaScript (javascript)My Approach to the Term Full Stack Developer
At a certain point in my career, this definition perfectly reflected my state of mind. It was what I felt I was and what I wanted others to perceive when they looked at me. Proud of this status, I included it in my resume, almost like when you get an excellent grade in school and want to share it with your family.
Over time, I realized that the allure of this definition had captured the hearts of many people, mainly due to a common belief: being Full Stack means being a complete programmer, and for companies, hiring a Full Stack Developer represents added value.
If you assign a project to this type of programmer, they are capable of independently handling all aspects of software development. It’s like having an entire development team encapsulated in one person!
Over time, I realized that this approach could make sense when projects were simple and technologies were few.
Today, the world has changed, and it is much more complex to cover every aspect of a project. Now, being a “Full Stack Developer” seems to be synonymous with working mediocrely on all aspects of a project: you are not an expert in backend, frontend, or DevOps; you have a basic understanding of UX, UI, SEO, marketing, you know a little bit of everything, but nothing in-depth, or maybe just one aspect.
Let’s try to translate the concept of “Full Stack” to your mechanic: your mechanic, when there is a problem with the bodywork, doesn’t fix it by hammering it but involves a bodywork specialist; when there are carburetion problems, they call in a carburetor expert; when there is an electrical problem, they involve an auto electrician.
Similarly, if your doctor suspects a particular problem, they send you to a specialized expert in that area, who will conduct a thorough examination to formulate a targeted diagnosis and treatment.
A “Full Stack” programmer, on the other hand, is chosen not to have to call anyone, to solve everything on their own.
This approach is not sustainable, or rather, it is not feasible if we think of Full Stack as an endpoint rather than a starting point. Many professions make us understand that an expert in a particular field is preferable to a “jack of all trades” if we want to do a job with artistry.
Experienced programmers know how important it is to specialize and recognize the hours wasted searching for solutions that an expert would have quickly resolved.
In mass culture, and often when talking to clients, there is the presumption that a programmer should be able to do everything perfectly.
Responding with phrases like “it’s not my field, we would need a UI expert” is seen as a sign of weakness, even though it is a legitimate, professional, and honest response.
- "I am a Full Stack Developer"
- "Ah, so you're an expert in everything?"
- "Not exactly"Code language: JavaScript (javascript)
The Job Market and the Full Stack Developer
The job market has started riding the wave of demand for “Full Stack Developers,” responding to this need in sometimes bizarre ways.
Figures like “Junior Full Stack Developers” are emerging, who declare themselves “full stack” but add the term “junior” to emphasize their inexperience. Often, this title follows intensive courses like “Become a full stack developer in 6 months”.
We may not realize it, but we are facing a serious problem. On the one hand, we are putting in the heads of young programmers the idea that they can independently and easily cover the entire technological stack, only to have them face the harsh reality: when they encounter their first complex project, they realize they are not able to handle it alone.
However, it is not entirely the fault of these new programmers. There is also a problem related to some companies that cannot accurately assess the real level of competence of individuals and assign roles of responsibility based on limited information.
Responding brilliantly to a technical interview is one thing, but as Linus Torvalds wisely asserts:
Talk is cheap. Show me the code.Code Quality and Programmer Evaluation
The code, the approach to problem-solving, and how difficulties are tackled are the aspects that distinguish one programmer from another, even if both define themselves as “Full Stack Developers”.
Unfortunately, evaluating how capable a person is of producing quality work is not easy at all. I have seen programmers produce large amounts of code but of poor quality, and programmers who produce less but of extremely high quality.
To quote Antoine de Saint-Exupéry:
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.Being able to assess the true value of a programmer is a very difficult skill to acquire, yet it is a fundamental competence for a good manager. It is not enough to evaluate the number of lines of code produced, the number of completed projects, or the number of technologies known, especially in an era where technologies change rapidly and help us write more code in less time.
The amount of code is not an indicator of quality, even if it works perfectly and is covered by numerous functioning tests. Code should not be evaluated by weight but by its quality, maintainability, scalability, and readability.
Who can evaluate the quality of the code? It is not easy to answer this question.
The simplest answer might be another Full Stack Developer, but that is not the right answer.
It is not the right answer because a Full Stack Developer is not an expert in everything but should be an expert in their specific application domain. Therefore, the evaluation of a person’s value by a Full Stack Developer may be influenced by a series of biases due to their personal experiences, previous knowledge, and acquired skills.
So, can an HR person evaluate the quality of the code? Or a manager? A colleague? A client? The right answer is: all of them can contribute.
Even in this case, however, the evaluation will be the sum of the experiences of the various people involved, who may have different opinions and decree that the same Full Stack Developer is a genius in one technology stack like LAMP but incompetent in another like MEAN.
What if We Focused on “Problem Solving Mindset” Instead?
We have now understood that “Full Stack Developer” is a non-qualifying term, open to interpretation depending on the context, and, above all, very burdensome in terms of the necessary technological updates.
Let’s try working on a different concept: “problem-solving attitude”.
A programmer who possesses a strong problem-solving attitude is capable of tackling any problem, even if they have never encountered a similar one before. They can analyze the problem, break it down into smaller parts, find a solution, implement it, and successfully test it.
This type of programmer is not discouraged by difficulties but faces them with determination, adapting and learning along the way. This flexible and analytical mindset is crucial for tackling the ever-changing challenges that arise in software development.
A programmer with a strong problem-solving attitude is not afraid to ask for help, to admit “I don’t know” or “I can’t do it”. On the contrary, they are capable of working effectively in a team, sharing their knowledge, learning from those who know more, and teaching those who know less.
In this context, a wealth of experience in different technologies and contexts, in international projects with heterogeneous technologies, is undoubtedly an added value, much more than being a Full Stack Developer. The latter does not specialize in problem-solving but in an in-depth knowledge of their specific technological stack, which is out of context like a bowler in a game of briscola.
Being able to solve problems even in unfamiliar contexts is a valuable asset within a team. There will always be time later to refine the solution by placing it in the hands of a product expert, but the ability to solve problems independently is an invaluable skill.
A programmer with a flexible, analytical, and collaborative mindset, combined with a wide range of diverse experiences, will be able to successfully tackle the most complex challenges, adapt, and constantly grow.
Conclusion
My advice is to avoid declaring oneself a “Full Stack Developer”.
This term is now too inflated, and when written on the resume of a junior programmer, it adds no value, except for the amusement of more experienced programmers who read it.
It is much better to accurately identify the technologies in which you are an expert and those in which you have less experience. This applies to all programmers: you can be a wizard in Angular, have written REST APIs in Node, but if a backend expert analyzes your code, they will probably find gaps.
By clearly stating your skills and experiences, it will be up to your interlocutor to evaluate your actual value, which is much more important than a generic “Full Stack Developer” label.
We should focus on building a solid problem-solving attitude, gaining experience in different technological contexts, stepping out of our comfort zone, and promoting a collaborative approach to work. These qualities will be much more appreciated than self-certifying as “Full Stack,” which risks being misleading or excessively generalist.
