The boring debate over the use of "full-stack"
Arguing over miscommunication
The most unproductive arguments are the ones where people are complaining or defending completely different things that happen to be described by the same words. In the software world, "full-stack" is one of those cases.
I never witnessed a debate over the term that wasn't as boring as writing cover letters for job applications over LinkedIn. The sad part is that people arguing about a particular use of full-stack might have relevant insights substantiating their position. Only that they are so busy pointing fingers to the people they want to judge that we never see what they have up their sleeves.
I will list a few typical interpretations and try to separate the misconceptions from the valuable discussions. The point here is not to make fun of people holding these arguments, but to show how a conversation loses its value when words are not equally understood among both parts.
Definition by boundaries
A full-stack engineer is someone who can design a microprocessor, solder the chip, map the machine language, create ELF files, program in assembly language, build an assembler, build a compiler, design system architecture, code in a backend language, manage a database, implement a CI/CD flow, implement cybersecurity, manage networks, code in Javascript including a known framework, create the HTML code and vertically align a div.
I don't have the CS background to make this list even close to completion (any volunteers?) but it’s long enough to show that a completionist definition of full-stack is impossible and irrelevant.
People draw from all the possible skills of a software engineer and create their arbitrary boundaries of what defines a full-stack; then, they spend hours debating with people that happened to choose a different arbitrary set of skills.
The misconception is thinking that full-stack should have a very narrow and consensual meaning. Full-stack is context-dependent. In particular, stack-dependent. It is fine that a full-stack in one stack (e.g., NodeJS + React) is not full-stack in another (e.g. NodeJs + Swift for native iOS apps). It would be much better to ask: "What skills are you including in your definition of full-stack?" and realize they were just talking about different things.
The hidden valuable debate is the pros and cons of learning different parts of the stack. It might provide you with insight into complex problems that traverse stack boundaries and give you more flexibility in your career. Or it might restrain you from gaining more in-depth knowledge on any topic and hurt your career for not being a specialist.
Instead of debating if one must know about SQL performance to be considered a full-stack, better discuss in what circumstances learning more about it will help, when it won't matter, what kind of problems it solves, how it would affect one's career. This debate will help others make more informed decisions about what to invest their time on.
Definition by ego
I only ever met one real full-stack engineer my whole life. A real full-stack engineer does not exist. A real full-stack engineer would know how to write a compiler.
The misconception is that full-stack engineer is not a description, but an acclamation. People mythicize the full-stack role because they both think it's the quality of a better software engineer and feel threatened by it. These people fight to avoid the use of the full-stack label at all costs.
The hidden valuable debate is if learning more parts of the stack will make you a better software engineer. The answer to the question, "Will I be a better software engineer if I learn native mobile app development?" is different for each person in each moment of their careers. The observation of the end state of an engineer as a full-stack says nothing about how good of an engineer they are. Accept that the full-stack label has no correlation with the quality of a software engineer and try to answer to question only to your own case.
Definition by experience
No one with 6 months of experience can call themselves full-stack. There is no such thing as a junior full-stack engineer.
The misconception here is similar to full-stack as a quality label. It is practical for a junior developer that is learning to code studying PostgreSQL, NodeJS and React describe themselves as full-stack while looking for their first job. They don’t have to exclude themselves from frontend or backend positions that might be a good fit for their skills just because a senior engineer from the comfort of their big salaries might look at them with disdain. It does not imply that they are anything more than a junior developer looking for their first job.
The hidden valuable debate is what would be a better path for someone learning to code. Frontend? Backend? Doesn’t matter as long as you focus on only one of them? Both of them to better understand software as a whole?
Definition by focus
I see that 51% of your Jira issues are backend, so you are a backend developer that can help with frontend.
I see you started your career as a React developer, so you are actually a frontend developer that happens to know about NodeJS.
The misconception here is that full-stack is binary, not a spectrum. Or that full-stack engineers should be doing all parts of the stack all the time. You can consider yourself a full-stack and decide to invest your learning in becoming more full-stack by learning new stuff or less full-stack by specializing more in one technology. And one of the advantages of a full-stack is the flexibility to be more of a frontend at one moment and then only perform backend tasks at the other.
The hidden valuable debate is how an engineer makes those choices about their learnings and tasks. When to learn something new versus learn more about something old? Will I help the team more by only taking frontend tasks this cycle?
Definition by job descriptions
We have an open position for a Full-stack engineer…
The misconception is that stack-related words on a job description have any meaning.
Job descriptions are where technical words go to die.
There is no valuable hidden debate when arguing about job descriptions tech-related word choices. Just don't.
If a word can mean anything, it means nothing. I agree. Some people might resent this; I don't. Such is human language. Context matters, meanings change organically, temporarily, and geographically. Words aren't unique identifiers on a database. "Full-stack engineer" per se doesn't mean anything. Make sure to clarify what you are talking about and debate about that, not about the term. And accept that other people might have a different use for the term.
This is a newsletter in English about writing by someone who is not a native English speaker nor a writer. You can find all past advice in the archive and sign up to receive the next ones on your email.