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.
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.)
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.
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.
This post originally appeared on O’Reilly Radar. (“Full-stack developers”). It’s been republished with permission.