What is a Full-Stack Software Engineer?

You’ve heard the buzzword, you’ve seen the job postings. If so many people are hot about this topic, it must be worth learning about, right? What is a full-stack software engineer anyway?

My goal is to paint a picture of full-stack software engineering. What it is, what it isn’t. Full disclosure: this is an opinion based on my own career working as a full-stack software engineer.

Constructing a definition

Let us begin by constructing a definition: A full-stack software engineer is one whose work spans the entire stack within the software development lifecycle. This may not be the definition many job-seekers fit nor necessarily what job-posters are looking for. But it is what it is.

I like to look at full-stack engineering the same way I look at family practice doctors. They are generalists. Generalists have some knowledge across the breadth of their field. They may have some areas of particular interest, but overall they know “enough” about “a lot”.

Given that definition, it is easy to become dissuaded by the market’s insistence that applicants are full-stack engineers. Beginners, especially, will struggle to fit that mold.

With the nasty bit out of the way, how about we start decomposing it?

What is the “stack”?

A lot goes into software development. It also highly depends on the audience and platform for your application. Applications may or may not include pieces from the following basic stack (based on 3-tier or n-tier architecture):

• Backend
• Middleware
• Frontend

Ah, but Jon, you said “the entire stack within the software development lifecycle!” Yes, I did. We’ll get there. Let’s focus on the basic stack for a moment.

Backend

Backend software development focuses on exactly what it sounds like. The “behind-the-scenes” work of an application. This may include database, scheduled services/tasks, service-to-service interaction, message queues, ETL, APIs, and more. In an extremely general sense, we view this as the “server”. The backend interests itself with data. Many engineers who focus at this level are versed in database and storage systems, data optimization, etc.

Middleware

Software middleware orchestrates requests and messaging from one system or process to another. It deals with “business” logic. As with the backend, the middleware is also frequently called the “server” by outside observers. Engineers at this level frequently work on APIs and services exposed to the front-end. Backend and middleware are commonly paired together.

Frontend

According to the unwashed masses, this is where the real magic happens. Except it isn’t. The front end is the interface between humans and the rest of the application. In a truly full-stack system, business logic and decisions (aka domain) should not exist here. The front end concerns itself with presentation and data collection.

A common joke in the backend software world revolves around front-end engineers getting the credit when all they did was add a button. While untrue, it highlights that work in the backend is largely ignored by observers of the system. They can only judge what they can see.

The front-end can take many forms. In today’s modern world, this is most frequently viewed as a web-hosted SPA or other web application, a mobile app, or a desktop application. That said, virtually any human interface is a front-end.

Expanding the stack

As I previously defined, a full-stack software engineer works on the entire stack within the software development lifecycle. That’s a mouthful.

I’d like to give some historical context to this bold statement.

At some point in our technological past, development tools became accessible and easy enough to empower lone developers to accomplish great things. They could write the software, package it up, and deliver it out with “the push of a button”. I say that tongue-in-cheek, of course, but the concept is key here.

In other words, a single developer was able to deal with everything involved with delivering software. Smaller companies not only hoped candidates could “do everything”; they frequently expected it.

But the world got bigger.

The new stack

While the following list is by no means exhaustive and some items cross multiple lanes, my effort below is to highlight where concerns commonly fall. Dylan Iqbal also has a great post that talks about full-stack development and more detail about what the stack is.

• Project management
  • Planning/requirements gathering/documentation
• Systems design and architecture
  • Which technology(ies) to use, how to glue them together, etc
• Software Release Management (SRE)
  • Source control (Git, etc). Branch/PR protections, build pipelines (CI/CD), application versioning, artifact storage, etc.
• Backend
  • Database technologies, read/write replication, storage mechanisms, eventual consistency, message queues, etc.
• Middleware
  • Authorization/Authentication (OAuth, SAML, etc), service transport (REST, gRPC, SOAP, etc), system integrations, etc.
• Frontend
  • HTML, Javascript (React, Angular, Svelt, Vue, etc), CSS/LESS/SASS, Design Systems, XAML, SwiftUI, Android XML, WinUI, WPF, and the list goes on.

It is my hope that by viewing this list, it is easy to see that it is full of areas of specialization. I also hope you can appreciate how broad the field is becoming and thus how difficult it is to have depth across the breadth here.

Unicorn?

Now that we have a better picture of what the entire stack is we can ask the question: “are full-stack software engineer’s unicorns?” For the most part, yes. In order to qualify that statement, however, we should probably settle on the definition of what that means first. Unlike mythology where unicorns aren’t actually real, let’s go with the portion of the mythological definition where they are extremely rare and hard to catch.

I invite you to jump over to Atlantic BT and their post about The Myth of the Full-Stack Unicorn Developer. They go quite a bit more into detail about the unicorn concept of full-stack engineers though they focus mainly on the polar-ends of the stack. They do reference cloud deployment as well, but their focus drills into devops and still not what I consider the new stack.

Companies that actually know what they’re asking for are rarely asking for such a unicorn. Of course, it may be hard to discern which companies do and don’t know that. At the end of the day, however, they are trying to get the best deal they can on the best developer they can find.

If you’re not a so-called unicorn, does that mean you can’t or shouldn’t apply for full-stack positions? I’d say no. By all means go for it. Some may exclude you based on your apparent lack of full-stackedness and that’s ok. Others will give your experience a chance to speak for itself.

Recall that I said these days a full-stack engineer is more of a generalist than a specialist. It is great and advantageous to have a breadth of knowledge. Even so, there is going to be some aspect of that stack that interests you more than others. That’s your specialty. Take it. Own it. Win it.

Do you call yourself a full-stack software engineer?

I imagine by this point you’re asking whether I call myself a full-stack software engineer. I’ve worked in the field long enough and in a wide variety of industries that I’ve had a lot of exposure to a lot of different “hats”. Wearing these hats has given me experience in what I’ve aforementioned as “the new stack”.

So back to the question at hand: do I call myself a full-stack software engineer? In the broadest of terms, I absolutely do. After all is said and done, however, I’m also experienced enough to know when I should step back and let a specialist in [insert area here] do the work instead of me. I consider backend and middleware to be my particular areas of specialization.

I ask you, reader: do you call yourself a full-stack software engineer?

Parting words

We’ve briefly gone over what a full-stack software engineer is, in practice. They are generalists. Ones who are truly skilled across the new stack are rare and valuable catches; unicorns, as it were. You don’t have to be a full-stack engineer to be skilled or valuable to a company; picking a specialization and niche often affords deeper understanding and value.

Other reading

While the results of this blog post are primarily based on my own experiences, I find it important to familiarize myself with other viewpoints as well. Here is a small collection of posts similar to my own.

• Sam Saltis on The Rise of The Unicorns AKA “Full-Stack Developers”
• Alexey Chalmov about 3-in-1 Developer: A Jack of All Trades or a Unicorn?
• Full Stack Developers: Unicorn? Or Reality? by iWeb
• University of Toronto: What is a Full Stack Developer & What Do They Do?
• Wikipedia: Middleware
• What is Three-Tier Architecture – IBM

Credits

Cover Photo by La-Rel Easter on Unsplash