Introduction
At some point in the last five or six years, “full-stack developer” stopped being a description and became an aspiration — and then a requirement. You see it everywhere now. Job descriptions that list twenty technologies across frontend, backend, DevOps, and cloud infrastructure, all under the heading “Full-Stack Engineer.” LinkedIn profiles where someone three years into their career lists React, Node.js, Express, MongoDB, Docker, AWS, and GraphQL under their skills, and describes themselves as full-stack in their headline.
I have worked as a frontend specialist on teams where backend engineers wrote the server code, and the collaboration between people who were genuinely deep in their respective domains produced systems that were better than either could have built alone. I have also worked alongside developers who called themselves full-stack but whose frontend knowledge collapsed under scrutiny — who knew enough React to get a component rendering but had no mental model of what the browser was actually doing, and whose backend code worked in development but hadn’t been thought through for production.
The gap between the label and the reality is wide. And the industry, in its enthusiasm for the label, is making that gap worse — while quietly penalising the people who chose depth over breadth.
This is about that.
What Full-Stack Used to Mean
The idea of a developer who could work across the full application stack is not new and it is not inherently problematic. In the early days of web development, the distinction between frontend and backend was much blurrier. A developer building a website in the early 2000s might write the HTML, style it with CSS, handle server-side logic in PHP or ASP, and manage the database. The entire stack was smaller, less complex, and more surveyable by a single person.
That era produced developers who genuinely understood the full system because the full system was comprehensible at a level of depth that mattered. They knew how the request moved from the browser to the server and back. They knew how the database query affected the page load time. They knew what the browser received and why it rendered the way it did. The full-stack label, applied to these developers, was accurate in a meaningful sense.
Then the stacks got deeper.
Frontend became an entire discipline. JavaScript grew from a scripting language for simple interactions into the foundation of complex application architectures. CSS grew from a styling language into a layout and animation system with a model sophisticated enough to require years of serious study. Build tooling, component architecture, performance optimisation, accessibility, state management, reactive programming — frontend became a career’s worth of depth on its own.
Backend followed the same trajectory. Distributed systems, microservices architecture, database design and optimisation, caching strategies, API design, authentication and security, message queues, serverless functions — the depth required to do backend engineering well expanded dramatically.
The full stack became two full-time careers sitting next to each other. And the label “full-stack developer” started to mean something more like “developer who can contribute to both sides” rather than “developer who is expert in both sides.” Which is fine, as far as it goes. But that nuance has been almost entirely lost in the way the label is used today.
How the Label Got Debased
Here is how I think the collapse happened, and I am going to be specific because I think the mechanism matters.
JavaScript runs everywhere now. It runs in the browser and it runs on the server through Node.js. A frontend developer who knows JavaScript can write a basic Express server, connect it to MongoDB, and have something that resembles a backend running in an afternoon. The technical barrier between “frontend developer” and “someone who has also written some backend code” became very low.
This coincided with a generation of developers whose first serious framework was React. React has a large ecosystem — React on the frontend, Node.js and Express on the backend, and a family of tools that share a JavaScript vocabulary across both. A developer who learned this ecosystem could credibly claim exposure to both sides of the stack. They could build a full application, end to end, in JavaScript.
And then — and this is the critical step — companies started preferring it. Startups in particular. A single developer who could wire up a React frontend to a Node backend was cheaper than two specialists and required less coordination overhead. The label “full-stack” started carrying a salary premium. Job boards started optimising for it. LinkedIn profiles started featuring it. Bootcamps started marketing around it.
The incentives created the supply. Developers learned enough of both sides to claim the label, because the label got you further than being honest about your depth. And the industry, which was evaluating candidates at volume with limited time, accepted the label without always examining what it contained.
What I Actually See in Codebases
I want to ground this in specific observations, because I think the abstract debate about full-stack vs specialists misses the texture of what the knowledge gap actually looks like in practice.
On the frontend side, I have reviewed code from developers who described themselves as full-stack where the following were true: they did not know what triggered a browser repaint versus a reflow, and wrote animations that janked on every mobile device they were tested on. They did not understand JavaScript’s event loop, and wrote async code that had subtle ordering bugs that only appeared under load. They did not understand CSS specificity, and maintained stylesheets that were a maze of !important declarations because they couldn’t reason about why styles were or weren’t being applied. They could make things work in the happy path. They could not reason about why things failed in the unhappy one.
This is not a personal failing — it is a predictable consequence of having divided your learning time across two stacks instead of going deep in one. You learn enough to ship. You don’t learn enough to understand what you shipped.
On the backend side, the equivalent looks like this: database queries written without indexes, discovered in production when the table has grown to a million rows and suddenly every page load takes four seconds. Authentication flows that work but have subtle vulnerabilities that a security engineer would catch in thirty seconds. API responses that return far more data than the client needs because nobody modelled the data access patterns. Error handling that swallows exceptions in ways that make debugging production issues nearly impossible.
Again — not stupidity. These are gaps that arise when someone is spread across a wide surface area and has not gone deep enough in any particular area to develop the intuitions that catch these mistakes.
The Full-Stack Boast
I want to talk about something specific that I have encountered enough times to consider it a pattern.
There is a version of the full-stack developer who is genuinely skilled — who has gone deep enough in both frontend and backend to contribute meaningfully to both, who has the intellectual breadth to hold the full system in their head and reason about it as a whole. These developers exist. I have worked with a few of them. They are usually at least eight or ten years into their careers, and they have specific, deep experience in both domains that was accumulated over time.
And then there is the developer who lists twelve technologies on their LinkedIn profile, calls themselves full-stack, and in the first technical conversation reveals that their knowledge of each of those technologies is wide and shallow — enough to use the API, not enough to understand what the API is doing on their behalf.
The second type is, in my experience, significantly more common than the first. And the confidence with which the label is worn is often inversely proportional to the depth it represents. The developer who genuinely knows both sides tends to be precise about the boundaries of their knowledge — “I’m stronger on the frontend, I can do backend but I’d want a review on the database design.” The developer who is performing full-stack tends to be expansive about it — “yeah, I do everything.”
I don’t say this to be unkind. The incentive structure created this behaviour. When the label gets you interviews and the absence of it costs you interviews, you learn to claim the label. That is a rational response to an irrational selection mechanism.
But the codebases remember what the interview process forgot.
What It Does to Specialists
Here is where I want to talk about the cost that is not being talked about loudly enough, because it is being paid by a specific group of people who tend not to complain publicly.
I am a frontend specialist. I have spent a decade going deep in HTML, CSS, JavaScript, TypeScript, Angular, React, accessibility, performance, state management, real-time data, component architecture. The knowledge I have accumulated is specific, hard-won, and genuinely useful. It makes me meaningfully better at building frontend systems than a developer who has divided that decade across frontend and backend equally.
And increasingly, that depth is being treated as a liability.
Job descriptions that require full-stack experience exclude me from consideration for roles where the actual work is eighty percent frontend. Salary bands that were designed for the “does everything” developer compress the range available to the specialist. Engineering culture that treats generalism as the default expectation creates pressure on specialists to demonstrate breadth — to prove that they can do the backend work — even when the role does not require it.
The implicit message is familiar: your expertise in one domain is less valuable than functional competence in two. The specialist who can debug a subtle change detection issue in Angular or architect a component system that scales across a large team is less marketable than the developer who can wire up a React frontend to a Node backend without either being done particularly well.
This is a strange set of incentives for an industry that also regularly complains about the quality of its codebases.
The Pressure to Become What You Are Not
The practical consequence of this for specialists is a pressure to acquire skills in domains they did not choose and may not enjoy — not because those skills are required by the work they actually do, but because the label those skills enable is required by the market.
I know frontend developers who have spent months learning Node.js and Express not because they had any particular interest in backend development, not because their current role required it, but because they kept encountering job descriptions that said “full-stack preferred” and felt the competitive pressure to be able to claim the label.
Some of them found they enjoyed it. Most found they tolerated it. A few found it genuinely demoralising — spending significant time and energy on a domain that did not interest them, producing competence that felt thin compared to the depth they had in their actual specialism, and ultimately not being sure they were meaningfully better positioned in the market for having done it.
There is something specifically uncomfortable about being asked to learn something you are not comfortable with, or that you actively do not enjoy, not because it will make you better at the work you care about, but because a label in a job description requires it. It is a different kind of uncomfortable than learning something hard that you want to understand. Difficulty in the service of genuine curiosity is energising. Difficulty in the service of market compliance is just exhausting.
And the worst part is that the competence you build in the domain you were pressured into is always going to feel thin next to your actual depth. You are going to know enough Node.js to claim it, but you are also going to know that a genuine backend developer would see your Node.js code and have notes. You are performing a kind of breadth that is permanently one level shallower than the depth you have on the other side. That asymmetry is uncomfortable to sit with.
What “Full-Stack” Usually Means in a Job Description
Let me translate some common job description language, because I think there is sometimes a gap between what companies write and what they actually need.
“Full-stack developer required” often means: we are a small team and we need someone who can help with both frontend and backend tasks, we cannot afford two specialists, and we are using “full-stack” as shorthand for “flexible.”
“Must be comfortable working across the full stack” often means: our codebase is a mess and everyone touches everything because we never defined ownership clearly, and we want someone who will not object to being asked to fix a database query even though they were hired to build UI components.
“Full-stack with strong frontend skills” is the most honest version, and it usually means: the frontend is the priority, but occasionally you will need to touch the backend, and we don’t want to hire someone who will refuse.
None of these requirements is unreasonable. But none of them is well-served by hiring a developer who calls themselves full-stack because they know React and Node, and who has a shallow understanding of both. The first requirement is well-served by a strong frontend developer who has some backend exposure. The second requires better engineering culture, not a different kind of hire. The third is what it says — frontend first, backend occasionally.
The label “full-stack” is doing a lot of heavy lifting in job descriptions that would be better served by more specific language. And developers have responded to the label in kind, claiming breadth that the specific requirements do not actually demand.
The Industry Is Getting Worse at Depth
I want to make a claim that is harder to prove but that I believe based on a decade of code review, mentoring, and working alongside developers at various stages of their careers.
The general level of depth in frontend engineering specifically has declined over the period when full-stack generalism became the default expectation. Not uniformly — there are more excellent frontend engineers today than there have ever been, and the quality ceiling has risen. But the average has shifted. The developer who calls themselves a frontend engineer today is, on average, less likely to have a deep understanding of the browser platform, CSS layout, JavaScript’s execution model, or accessibility than the developer who called themselves a frontend engineer ten years ago.
Part of this is the increasing abstraction of the tools — frameworks do more work, and you can ship more without understanding the underlying platform. But part of it is the simple reality that the time developers spent going deep in frontend has been partially redirected toward acquiring enough backend knowledge to claim the full-stack label. Time is finite. Depth requires time. If the time goes somewhere else, the depth does not accumulate.
The industry has traded some depth for the appearance of breadth. I am not sure it is a trade most companies would make explicitly if they thought it through, but it is the trade the incentive structure has produced implicitly.
What I Think the Industry Gets Wrong
I want to be fair to companies here, because I don’t think they are hiring full-stack developers out of malice or laziness. The genuine appeal of a developer who can contribute across the full system is real. Coordination costs between specialists are real. Bottlenecks created by strict specialisation are real.
But there are a few things I think companies consistently get wrong when they default to full-stack hiring.
They undervalue the multiplicative effect of genuine depth. A frontend specialist who is truly expert in their domain does not just produce better frontend code — they elevate the entire team’s frontend output through code review, mentoring, architectural decisions, and the standards they set by example. A generalist who is good enough at frontend does not do this. The difference between “good enough” and “excellent” in a senior engineer multiplies across every junior who is watching and learning.
They confuse flexibility with capability. A developer who can contribute to both frontend and backend is flexible. A developer who is expert in both is capable in both. These are different things and they require different amounts of time to develop. The first is achievable with a few years of broad exposure. The second requires a decade of deep work on each side — which is why genuinely full-stack senior engineers are rare and valuable, and why most people who claim the label have the flexibility without the capability.
They create a culture that makes specialists feel unwelcome. When the default expectation is generalism, specialists feel pressure to claim breadth they don’t have, to apologise for depth they do have, and to spend their development time on things that don’t serve their actual growth. The specialist who says “I focus on frontend” in a culture that valorises full-stack is quietly implying a limitation rather than claiming an expertise. That cultural message has consequences.
What Genuine Full-Stack Looks Like
I want to be clear that I am not arguing against full-stack developers — I am arguing against the conflation of the label with the reality.
Genuine full-stack depth is rare, takes a long time to develop, and looks specific. A developer who is genuinely strong across the full stack can tell you why a particular database query is slow and how to fix it. They can explain what happens in the browser’s network tab when a request is made and what the server is doing on the other end. They can design an API that is genuinely useful to the clients consuming it. They can build a frontend that is performant, accessible, and maintainable. They understand the security implications of their authentication choices. They can reason about the trade-offs between different caching strategies.
This is not something you arrive at by learning React and Node.js. It is something you arrive at after years of going deep on both sides, building real systems, debugging production failures, and accumulating the kind of intuition that only comes from having been wrong enough times to understand why you were wrong.
The developer who has done this is rare and genuinely valuable. The developer who has learned enough of both sides to claim the label is common and, in the right role, perfectly adequate. The problem is that they are being evaluated by the same filter, which is good for neither of them.
Where I’ve Landed
I am still a frontend specialist. I have some backend exposure — I have worked on Node.js services, I understand REST and GraphQL APIs, I know enough about databases to write queries that don’t make backend engineers wince. That exposure makes me a better collaborator.
But I am not full-stack, in the sense that genuinely matters. And I have stopped pretending otherwise, because the pretence does not serve me or the teams I work with. When I claim depth I don’t have, I create expectations I cannot meet in the moments that matter — the production incident, the performance investigation, the architectural decision that will live in the codebase for years.
What I have instead is something I think the industry undervalues relative to its actual worth: a decade of genuine depth in frontend engineering. The knowledge of what the browser is doing. The mental model that makes debugging fast. The architectural instincts that come from having built and rebuilt the same categories of problems enough times to understand what the mistakes look like before they are made.
That depth is not celebrated on LinkedIn the way full-stack is. It does not always get past the filters that are looking for breadth. But it produces better software, and in the end, that is what the work is for.
Conclusion
Full-stack is a real and valuable thing when it is real. When a developer has genuinely gone deep across the frontend and backend — not “I know both frameworks” but “I understand both systems” — the combination is powerful and relatively rare. Those developers deserve the premium the market gives them.
But the label has been decoupled from the substance it was supposed to describe. It now primarily signals flexibility and ambition rather than genuine depth in multiple domains. And the market’s enthusiasm for the label has created a set of incentives that push developers toward breadth at the cost of depth, that penalise specialists for not claiming generalism, and that quietly accept lower quality in both domains as the trade-off for the appearance of covering both.
The codebase does not care what your LinkedIn profile says. It does not care whether the person who wrote the component called themselves full-stack or frontend specialist or anything else. It just reflects the depth of understanding that went into building it — or the absence of that depth, in the bugs that surface six months later.
The industry keeps saying it wants better engineers. It might want to think about whether the way it hires is producing them.