On the Legitimacy of “Full-Stack”

Casey Kinsey, Co-Founder, HeapSort

Update: We’re thrilled with the overwhelming response to this article, both complimentary and critical. If you’d like to weigh in, there’s a fervent and (mostly) civil ongoing discussion on Reddit.

Considering the background of HeapSort’s founding team and the goals of our product, it’s only fitting that the first post to our blog should tackle this topic head on.

I’ve been building web based software for just shy of a decade now, but my entry to it was probably a bit different than most engineers. I didn’t graduate with a CS degree and go to work for a software company. Instead, I took a job as a web designer (with a hobbyist’s understanding of programming and a year of 1000 level Computer Science courses under my belt) for a tiny newspaper in a small Arkansas college town.

I’ve gone on to work in the news/media industry for the better part of my career. Something I discovered quickly working in the newsroom is that in the newspaper business, you are in a perpetual state of “get shit done” mode. And get shit done we did.

A Skill Set is Born

It wasn’t by choice, but rather necessity, that I picked up front-end development. Prototype.js was getting really popular at the time and with it we were able to create a new type of interactive online advertising for our customers. As soon as the ad sales department saw what we were capable of, there was an endless supply of JavaScript development tasks in the queue.

And when we started building products that needed data persistence, our corporate provided IIS web server that only served static HTML no longer would suffice, so our tiny team of two web designers learned how to provision Linux machines, set up Apache, code with various server side scripting languages, and maintain databases.

We had to learn to do it because there was no one else in the company that knew how.

So there we were. Designing applications in Photoshop, building up bare metal infrastructure, writing server side application code, building out front ends with client side scripting. We were engineers, sysadmins, DBAs, QA techs. Hell–we were even sales and marketing.

To us, this was web development.

It wasn’t until several years later that I started work at a software company that I started to discover that large teams were comprised mostly of specialists. I met Python engineers that couldn’t write a line of CSS to save their life. And that was okay, because they were damn good at what they did, and there was plenty of front-end talent to pick up where they left off.

But at a small newspaper in Arkansas, they would have been DOA.

This Ain’t an Arkansas Problem

Fast forward to 2013 when I was working as Head of Technology for a fitness tech startup in NYC. It was a great fit for me from a talent perspective: The team was minuscule and funding was tight. Hiring an engineer that could write application code while maintaing the entire company’s web infrastructure wasn’t a nice-to-have; it was life and death.

I did this for several months before the workload began to pile up too high. There was much to be done in server side code, our front-end specialist needed backup, and it was all I could do to keep our infrastructure upright while building out the rest of the product.

It was time to hire, and I hit a brick wall. We had so much work to be done and the budget to hire one person. Do I hire a Python engineer? Do I hire another front-end developer? Maybe we should hire a sysadmin? Would that give me the help I needed in building out product features? Would they be busy or just held up by the same bottlenecks we had now?

What the Hell Am I?

What I really needed was another “me”, but I didn’t really know what I was. We weren’t looking for an engineer that was amazingly great at everything–I certainly wasn’t. We wanted an engineer able to adequately do any one thing. We had recruiters out there searching but nobody really knew what to look for. We were scouring resume databases for devs that identified as “generalists,” which was the best description I could think of for my skill set, and we hardly found anyone.

We finally ended up finding a consultant via an agency to fill the position. It seemed that consultants were more likely to have acquired the breadth of skills we were looking for due to their exposure to a large number of projects and organizations. I’ve done quite a bit of consulting work and I know that you have to adapt if you want to keep work coming in the door. You might be a project manager on month and a DBA the next. You learn new things if you want to put food on the table.

I started working on HeapSort immediately after this experience. I knew our industry needed a better way to source this skill set, and I knew engineers like me needed a better way to find positions where they could excel.

If you were to look back at all the comps and wireframes I made for HeapSort before we started development, you’d see words like “generalist” all over the place. While “generalist” satisfied our definition of the skill set, nobody out there was calling themselves that.

We had a marketing problem on our hands. In an internet marketing world driven by status updates, PPC ads, and blog posts, how do you effectively promote a product to a group of people that don’t know how to classify themselves?

We were certainly aware of the term “full-stack”, it had been gaining popularity ever since Facebook’s Carlos Bueno had written on the topic, and even more so when Laurence Gellert expanded on Facebook’s position. At first we avoided it because it had something pretty negative going for it: It had become a controversial recruiter buzzword.

And dear lord, we didn’t want to be the next group shilling for “JavaScript Ninjas”.

But we polled potential users, and talked to engineers. We compiled lists of the terminology they used to describe themselves. And damned if we didn’t find out that it wasn’t just a controversial term–it was, simultaneously, the most consistently used one.

After a while, we started to like it.

Taking “Full-Stack” Back

So how do you embrace a term that has some developers feeling all prickly? We’re staging a coup.

The first step is to rid it of its buzzword baggage.

“Full-stack” is a high demand, necessary skill set. If you don’t believe me, go out and ask any small newspaper, magazine, or television station. Ask any angel-funded tech startup. How big is your software team? What about your QA team? What’s the head count in your operations division?

Spoiler alert: It’s all the same team, and on average it’s less than 5.

“Full-stack” is not destined to die among the ranks of “ninja” and “developer rockstar.” It’s not a bullshit, corny marketing buzzword. It’s on my resume, and it should be on yours too. It belongs in our job descriptions and in write-ups about company culture.

The second step is to quantify and define what it means.

Every organization has a different application stack, so its natural that one person’s specific definition of full-stack might not align with someone else’s. Instead of infighting over some esoteric, all-encompassing list of skills that qualify an engineer as full-stack, we must recognize that it’s a vector and a mentality.

“Full-stack” stands in contrast to “specialized”, and a full-stack developer, while he may have some specializations, is widely capable of stepping into all of a software team’s roles when necessary.

In this vein, one of the first features we launched on HeapSort is “StackSplit,” which is our measure of this vector. It gives a clear picture of how broad a full-stack developer’s experience is, or how broad of expertise a position requires:

It’s the first of many ways HeapSort aims to bring credibility to the term and to the developers who identify with it.

We’re the among the first in the community to totally embrace and actually foster the “full-stack” descriptor for software engineering roles, but we don’t want to be just one of a few. Embrace “full-stack” and join us!

HeapSort - Find Full-Stack Web Development Jobs

Update: We’re thrilled with the overwhelming response to this article, both complimentary and critical. If you’d like to weigh in, there’s a fervent and (mostly) civil ongoing discussion on Reddit.