In a perfect world, full-stack developers are developers that can—in theory—create a usable end product with minimal input or support.

It seems simple enough, not everyone agrees on what makes a “full-stack developer.” Some don’t think the term should be used. Some adamantly defend the need for it. Some don’t even believe full-stack developers exist.

The strife over what constitutes a “full-stack developer” doesn’t just lead to online arguments (though it does incite a…lot… of… them). It also spurs misalignment in how to assess, attract, and hire full-stack candidates.

And while it’d be easier to put this dispute on the back burner, the term “full-stack developer” isn’t going anywhere. Not only has the job seen 198% growth in demand in the last year, but it’s also the most popular occupation for developers across the world (per our 2018 Developer Skills Report). In other words, it’s not a disconnect teams can afford to ignore.

In this piece, we’ll help clarify why there’s confusion around the oddly political job title, explain each side of the debate, and help you align with your hiring team to ensure you identify the skills you really need for your team.

To better understand the current disagreement over the term “full-stack developer,” we’ll have to unpack how the argument started.

The birth of the full-stack developer

The term “full-stack developer” hasn’t actually been en vogue for long at all. One of the earliest known mentions cropped up in 2008, and the first Google queries for a “full-stack developer” didn’t happen until 2010—and it’s only increased in popularity since:

“Full-stack developer” Google search trends since 2004 – this uptick in popularity is mirrored in alternate representations of the term, e.g. “fullstack developer” and “full stack developer”

But if this role has existed in some form since pre-internet times, why don’t we see this search term gain popularity until the early 2010’s? It turns out, answering that question requires a little bit of a tech history.

Per the history of the term, “full-stack developer” originally gained popularity in the mid-2000’s, where simpler, more streamlined technologies meant that many developers could feasibly execute a project end-to-end. The approach was a total 180 from the siloed responsibilities that defined the previous era of the late 1990’s and early 2000’s.

But as time wore on, a shift back to more complicated technologies and more layered stacks in the early 2010’s once again encouraged stratification of roles. Server-side and client-side work became increasingly polarized, contributing to the popularization of the terms “front-end developer” and “back-end developer.”

In response, in the same era, “full-stack developer” regained popularity in an attempt to distinguish developers that didn’t identify with the front-end/back-end specialist binary. Instead, they defined themselves as a third type of developer—one that could tackle both front and back-end responsibilities.

But of course, not everyone in the tech community agreed with that interpretation. And while it’s hard to pinpoint exactly when this debate surfaced, most credit two happenings for catalyzing it: first, a 2010 piece from former Facebook Engineer Carlos Bueno on the definition of full stack, and second, a claim that Facebook “only hire[d] ‘Full Stack’ developers” in 2012, as heard by Laurence Gellert at OSCON.

The result? A broiling terminology debate that’s still alive and well almost a decade later.

The case against the full-stack developer

The anti-full-stack developer camp is perhaps one of the most dominating voices in the argument over what does (or doesn’t) constitute full-stack. In short, their argument is hinged around the idea that a full-stack developer is someone with “the ability to easily navigate the back-end and front-end with a senior level of expertise.”

While there’s some variety within this view, this camp believes that full-stack developers should be able to:

• Write all around top-notch client side (or, front-end) code at the same level as a front-end specialist
• Write equally top-notch server side (or, back-end) code at the same level as a back-end specialist
• Manage the server infrastructure
• Handle the non-technical project management and business demands of coordinating their work with product
• Oversee QA, DevOps, and security

And while this group concedes that many developers can do some work that spans both disciplines, they feel very few can do both well. In short: they allege that a truly full-stack developer is a unicorn, and that too many people bill themselves as a full-stack developer without having full-stack qualifications.

This camp’s gripe with the “full-stack developer” term can be summed up in the following points:

• It’s a way for companies to make unrealistic demands of their employees. It allows them an avenue to task one employee with massive amounts of responsibility, which benefits the company, and at the expense of the developer. Companies ask for huge amounts of work and expertise at a low price (compared to the price of hiring multiple specialists).
• It implies a global level of expertise that most developers don’t have. Being a true full-stack developer entails “dual mastery” of both front and back-end tasks, which just isn’t possible, given the speed at which new tech evolves. Calling oneself “full-stack” with any less expertise is a misuse of the term.
• It encourages wide breadth, shallow depth knowledge. A full-stack developer can never fully immerse themselves in either the front-end or the back-end. A focus on the entire stack makes developers a jack of all trades, master of none.

This argument alleges that true full-stack developers are few and far between. Instead, they’re more apt to believe that self-identified full-stack developers are actually front-end developers with some back-end capability, or vice versa.

The case for the full-stack developer

On the other hand, the pro full-stack developer camp argues for a broader interpretation of the term. They refute the idea that a full-stack developer has to be an authority in every layer of the stack; instead, they need working knowledge of the entire stack, with true expertise in only a few layers.

Their definition of “full-stack” opts for a less restrictive set of requirements, describing someone who can:

• Comfortably write both front and back-end code to some extent
• Generate a MVP (minimum viable product) on their own with minimal support from others, if necessary
• Provide expert-level specialty in a small handful of technologies
• Show at least a basic understanding of technologies they don’t specialize in

In other words: from this view, a full-stack developer doesn’t have to be an all-around expert in every layer of the stack. Instead, here, a “full-stack developer” refers to being an effective and seasoned generalist: someone with a wide knowledge base, a solid specialty, and the willingness to admit when they’re out of their depth.

Their defense of the term “full-stack developer” is rooted in a few key thoughts:

• A good developer doesn’t silo their knowledge. While most developers are either front-end or back-end focused, to be good at either, you need to understand both sides of the table; forcing a strict line between the two sides discourages developers from learning beyond their specialty. On some level, the boundary between back-end and front-end is artificial.
• Companies need all around developers. Specialization isn’t suitable for everyone, or for every business goal. Small companies and startups need the broad expertise and the versatility of full-stack knowledge to build projects with limited people and resources. Large companies tend to have more work for specialists, but can still utilize full-stack developers in a project management context.
  
• They bridge the worlds of front and back-end. Specialized front-end and back-end developers have their place, but developers with full-stack knowledge help to bridge the gap between the two of them. Because they understand both sides of the coin, they can identify issues and opportunities that lifelong specialists might not. It promotes cross-layer functionality.

This argument alleges that full-stack developers don’t replace, but build on and complement the work of front and back-end specialists. Their core value lies in their ability to understand and work on the full breadth of a project, and to bring a more global technical knowledge to everything they touch.

In a nutshell, the philosophy can be summed up in this quote from The Pragmatic Programmer:

“The more things you know, the more valuable you are…the more technologies you are comfortable with, the better you will adjust to change.”

Aligning on a meaning that works

Amidst the debate, there’s some good news for those of us trying to decipher a definition for the term: both sides do align one thing. That is, they expect at least a basic understanding in all layers of a given stack. Their primary difference lies in how much expertise they expect from a full-stack developer in each layer.

Inching closer to alignment, a paper published by the Association for Information Systems (AIS) recently analyzed the top 5 most referenced and visited definitions of “full-stack developer” in an attempt to distill a common interpretation.

Here’s the universal definition they proposed based on that research:

Full stack development is a methodology which addresses all stack layers and in doing so creates a complete, implementable solution to business requirements. Full stack developers have broad experience among all stack layers and expertise in a few layers. They should be able to render a minimum viable product in a given stack.

– “Towards a Consensus Definition of Full-Stack Development”, Shropshire et al, 2018

While this definition is still bound to stir opinions from extreme viewpoints on either end, it’s certainly a step in the right direction to aligning on what, exactly, a full-stack developer is. From here on out, it’s up to the technical community to adopt a working definition—tech hiring teams, especially. After all, they do write the job descriptions.

With that in mind, here’s what recruiters and hiring managers can do to navigate the discussion:

• Make sure your asks are reasonable. No matter which camp you ask, nobody expects a full-stack developer to deliver the output of a full development team. If you decide that a full-stack developer makes sense for your team, be sure you’re not inadvertently asking for a “unicorn”, or asking one person to provide the output of many. Most importantly: be willing to consider that there may be more than one skill set that can succeed in the role.
• Clarify how developers work together at your company. How does your team split work, and who oversees them? What kind of front to back-end flexibility do they expect out of any given individual, full-stack or not? If hiring managers and recruiters align on this point, it can be easier to understand how a full-stack developer would function in context. And better role alignment means a more efficient hiring process.
• Keep your company’s needs in mind. Generally speaking, the bigger the company is, the more specialized developers (and all other roles) can be. If you’re in the process of growing your team, be mindful of how a full-stack developer would work in the team—not just today, but in the long run, as your team scales. A 300 person team might have room for more full-stack developers than an 8,000 person team.
• Consider that “full-stack” is a moving target. The spectrum of opinions on the term “full-stack” mean that full-stack developers can come in many varieties. Just because a candidate labels themselves a full-stack developer doesn’t necessarily indicate a match. On the flip side, a candidate that calls themselves a front-end or back-end developer may have just enough all around knowledge to suit your full-stack role. Don’t ignore the terminology, but take it with a grain of salt, and let the candidates’ skills speak for themselves.

Which camp do you and your team fall in? Let us know what you think in the comments.

You definition of full-stack won’t always align with your candidate’s. Standardize your process with coding challenges.