Full-stack developers

Developers who understand the whole stack are going to build better applications.

Large tree with branches. Photo by Alex, used under a Creative Commons license

Some see the full-stack developer as a unicorn, but it’s starting to look more like a tree, with tooling, cloud services, design, data, and networking added.

Since Facebook’s Carlos Bueno wrote the canonical article about the full stack, there has been no shortage of posts trying to define it. For a time, Facebook allegedly only hired “full-stack developers.” That probably wasn’t quite true, even if they thought it was. And some posts really push “full-stack” developer into Unicorn territory: Laurence Gellert writes that it “goes beyond being a senior engineer,” and details everything he thinks a full-stack developer should be familiar with, most of which doesn’t involve coding.

Lists like Gellert’s are both too long and too short; and, while I agree that a full-stack developer and a senior engineer aren’t necessarily the same people, I resist the idea that full-stack developers have near-magical skills in many different areas. (So does Gellert; he asks for “familiarity in each layer, if not mastery.”) At the same time, I’d add several items to the list that he only hints at: source control, data infrastructure, distributed computing, etc.

With that in mind, we can try to start by defining the stack. We can start with the now-ancient LAMP stack: Linux, Apache, MySQL, Perl. That list is only partial and certainly dated. Linux and Apache are still with us, though there are other servers like nginx that are gaining importance; MySQL is still around, though we now have dozens of post-relational databases (most notably MongoDB and Cassandra); and I wouldn’t be surprised to see MariaDB displace MySQL in the next few years. Nobody writes CGI programs in Perl any more; many languages come into play, from Haskell to Java. But even though dated, the LAMP stack has the right idea: an operating system, a server, a database, middleware.

LAMP dates back to the days when HTML was trivial, and all computation was done on the server. JavaScript was a toy language that helped to glue things together in the browser, but that was all. JavaScript has evolved into a serious, fully capable programming language in its own right, and CSS is almost there. If you are going to be a full-stack programmer, you certainly need to understand the platform on which the real front end of your application is running. The MEAN stack, Mongo, Express, Angular, and Node, a more up-to-date take on LAMP, shows how JavaScript has evolved into a platform of its own.

In addition to web programming, a full-stack developer needs to understand something of design. We’re still realizing the importance of user experience to a successful application. And just as designers are realizing that they need to do more than create mockups in Photoshop, developers need to understand the rationale behind design and talk to designers about what can and can’t be implemented effectively.

There’s also the hardware on which the stack is running. Much of the writing about full-stack programmers stresses performance, and it’s frequently only possible to understand performance by understanding how the software is interacting with the underlying hardware. So, as Bueno points out, it’s important to understand how SQL processes queries, how the CPU executes those instructions, and how the disk drives deliver data through several layers of caching.

Next, there’s the network: these days, nothing happens without a network, and what you’re doing on the network can have a huge effect on performance. Ilya Grigorik does an excellent job of explaining networking to web developers.

These days, many new applications (and just about all applications developed by a startup) run in the cloud. They don’t just store data in the cloud; they take advantage of Amazon’s infrastructure to build a virtual server farm and data center that’s almost infinitely scalable. Therefore, a full-stack developer also needs to understand Amazon and its APIs, what you’re buying, how it’s billed, and what services you can take advantage of. Cloud computing also throws distributed computing into the mix. Despite well-publicized outages, I’d bet that Amazon has better uptime than any homegrown datacenter, but you still need to understand how to make your application resilient in the face of those outages.

These days, there are few interesting applications that aren’t data driven. Are you building an ecommerce application that makes recommendations? In addition to all the other stack components I’ve mentioned, you’re probably dealing with Hadoop, plus Mahout, Scikit-learn, or some other machine-learning library.

And there’s the tooling infrastructure. I’m always surprised when I hear about companies that aren’t using source control, automated testing, and some form of continuous deployment. I can understand being leery of continuous deployment, and for many kinds of applications, CD isn’t appropriate. But there’s no excuse not to use Git or SVN (or a commercial equivalent). And it seems to me that a full-stack developer needs to understand modern tooling.

I started by saying that I didn’t like the idea that the full-stack developer was some sort of Unicorn. Then I blew that stack out even further, to where it’s arguably not even a stack: it’s starting to look more like a tree, with tooling, cloud services, design, data, and networking added. I’d be the last person to question the idea that developers need to know more about how businesses run, what management cares about, etc. Add another branch to that tree. So, have I made the picture worse? Is “full-stack developer” just a code name for some mythical person who can do everything, from writing assembly code to sweet-talking the banks? Might as well add “fixing the office plumbing” to that list. (Hey, if you’ve worked in a startup, that’s an essential skill.)

Being a full-stack developer is a tall order, but it’s as much aspirational as anything else.

The situation isn’t that dire. Yes, being a full-stack developer is a tall order, but it’s as much aspirational as anything else. I don’t think a “full-stack developer” is someone above and beyond a senior developer. I can imagine a junior full-stack developer, and sincerely hope that “full stack” doesn’t appear in job titles anywhere. I prefer the notion of the T-shaped developer, elaborated in (among other places) Valve’s employee handbook: a developer with broad knowledge and interests, but who understands one area deeply. The concept of a T-shaped developer does a better job of expressing what’s really important. I don’t expect a software developer to know as much about design as designers, or as much about the network plumbing as the network engineers. But they need to be able to understand the issues and talk to them intelligently.

More fundamentally, a lot of what we’ve learned in the past few years has been about burning the silos that separate developers in different specialties. DevOps is about breaking down the wall between application developers and the operation staff responsible for deploying and running those applications. Performance optimization, more often than not, involves breaking the carefully designed layers that keep our software architecture sane. Sometimes, the mythical “full-stack developer” sounds like: “we got rid of the silos, and now we want one person to replace them all.” That’s nonsense. What’s really needed isn’t someone who can replace all the specializations that the silos represented, but someone who can work across those specializations, someone who can work productively with people on other parts of the team.

Full-stack development is about exposing yourself to a broad range of ideas. This is a theme we’ll see repeatedly in the coming years. Being a full-stack developer isn’t about jumping immediately from working on the Hadoop cluster to the Java middleware to the JavaScript that runs in the browser. Specialization exists for a reason. But developers who understand the whole stack are going to build better applications. A back-end developer will understand what the front-end developers are doing, and be able to work with them so the application doesn’t generate requests that drive the database nuts. A front-end developer who understands design will be able to help the designers build applications that are both beautiful, and can run efficiently on any platform.

The more you expose yourself to different kinds of thought, the more you know about disciplines other than your own, the more effective you’ll be — both because you will understand how to collaborate with your colleagues and because you’ll have a broad repertoire of ideas and concepts to help in your own work. That’s where we’re headed, and that’s what full-stack development is all about.


The importance of becoming a full-stack developer is one of the main themes of the O’Reilly Open Source Convention. Developers attend OSCON to learn about the entire open source stack and how all of the moving parts integrate and work together.

Photo by Alex, used under a Creative Commons license.

tags: , , ,

Get the O’Reilly Programming Newsletter

Weekly insight from industry insiders. Plus exclusive content and offers.

  • Cole Thompson

    I’ve had roughly similar thoughts. Let me just add two more, and I’m honestly not trying to be provocative here:

    – Dev shops could do worse than look to the way that military special forces have evolved. If skill is rated from 1 to 10, individuals within a team tend to have level 10 skill in one area, level 8 or 9 skill in one other area, and then level 5 skill in everything else. So master of two trades, competent in everything else. This has the benefit that there is some ability to adapt to surges in need in one area.

    – With the removal of silos, and versatile team members, the need for classic generalist managers is greatly reduced. Eliminated even. If one places an MBA in charge of 8 technology versatilists, the value lost in explaining the work and overall impedance mismatch will exceed any value gained in extra coordination. Here again hints of a better way can be found in high performance settings such as military special forces, surgical theaters, professional sports teams, etc. The common thread is that these settings have individual contributors who manage by exception (i.e. as little as possible). I submit that in a dev or other tech setting, this would be served by job titles with the word “and”, where doing comes first, managing second, eg:

    Senior network architect and manager
    Backend developer and team lead
    Integration services engineer and manager