I've never been comfortable calling myself a "full stack" engineer. Even though I've built many full stack applications, I often describe myself as a, "frontend engineer that plays full stack on TV".

The term "full stack" just feels loaded and meaningless at the same time. We want to think of a "full stack" engineer as simply someone "who can write backend and frontend code equally well"; but that definition isn't really helpful. On top of that, this dichotomy between backend and frontend ignores many other skills required to build full stack applications.

So in this post, I want to share a diagram that I think better explains the nuances of what it means to be a "full stack" engineer. It is designed to help us identify our strengths and weaknesses and communicate those to others and our teams.

I want to be clear though that this diagram is not absolute and is more of a conversation starter than a set of hard and fast rules. I'm sharing it mostly because it was very helpful for me to see where I lie on...

✨ The Full Stack Spectrum

Unlike other diagrams, the Full Stack Spectrum focuses very little on mapping proficiency and skill. Instead, it tries to help us understand where we as individuals often place our focus when working across the stack.

You'll notice that our old dichotomy between backend and frontend now cuts across the spectrum and is replaced with the question of whether you think frontend first or backend first. Do we visualize the UI first or the structure of the data? That can be helpful in showing us which direction we might follow when it comes to the axes.

＋The Axes

At each end of the X and Y axes is an influence. We can think about these as different problems we often want to solve as engineers. Each of these influences is important, but often we are attracted to some and not others based on our interests.

To the left of the X axis, we have the common engineering mindset that wants to "make it fast" (or I should say blazingly fast). On the opposing end of the X axis, we have the want to "make it useful". Being drawn to this question often happens with engineers that have a product focused mindset.

I put these in contrast because I think focusing on "making it fast" often comes at the expense of making it quickly; and building something that can be rapidly shipped, tested, and iterated often comes at the expense of optimizing it for speed. It's not that you can't make something fast and useful - just that in development they are often opposing forces.

At the top of the Y axis, we have the mindset more of a designer who wants to "make it pretty". At the bottom, we have the infrastructure focused mindset of wanting to "make it scale".

Yet again, it's not that these are influences are in direct opposition to each other. I've placed them this way mostly because I've never met an engineer that spends a lot of time in the AWS Console and Figma. But if that's you, right on 💪. Again, the diagram is mostly for self-exploration.

That being said, with an understanding of our axes, we can ask ourselves which problems we focus on personally as full stack engineers. And with this information, we can see where we might lie on the spectrum.

To make it a little easier to identify ourselves, I've written persona descriptions for each quadrant. Let's go through each of them and see which one stands out to you - starting with the top left quadrant...

🎯 The Ace

The Ace focuses on making things fast and making them pretty. They can think frontend or backend first. They can build nice looking UIs while building performant backends. They know enough about infrastructure to be dangerous in the AWS console, but aren't super comfortable there. They often leave product decisions to other members of the team and focus more on building the thing right than building the right thing.

The Ace is what companies are looking for when they list jobs for "Full Stack Engineer". They want someone who focuses most of their attention on problems of speed - with a sense of design that enables them to make something look relatively nice at the same time. An interest in scalability is always a plus, but a focus on questions of product is often not what they need from someone in this role.

And this explains why I've often felt insecure applying to full stack engineering jobs; because I'm not an Ace. I'm...

⚒️ The Hacker

The Hacker thinks frontend first and most often focuses on making things pretty and making them useful. They focus more on optimizing feedback cycles over request/response cycles. They value beautiful design that helps differentiate their products and makes the user flow more seamless. They focus on algorithmic optimization only when users are asking for speed; and their favorite infra is a cheap single server on platforms like Fly, Railway, and Vercel.

This is definitely where I lie on the full stack spectrum. Realizing this has helped me in profound ways. By identifying my place on the graph, I've been able to better identify my own weaknesses and opportunities for growth. And by acknowledging my own strengths, interests and expertise, I've been able to understand and communicate my unique value as a team member when building applications.

To that end, it's also helped me understand who I need to surround myself with on projects in order to fill in my knowledge gaps. This also partially explains why Keith and I work so well together. Because on most of our project, Keith plays the part of...

🏗️ The Architect

With a combined focus between Product and Infrastructure, The Architect has a great sense for making something useful that can scale and be used by millions. Like The Hacker, they care about speed when it's affecting the product experience, but making it fast comes after making it right and making it available. Design is not their strong suite, so they often leverage off-the-shelf component libraries in their projects to fill that role.

I think The Architect might be the rarest persona on the Full Stack Spectrum. I have rarely met engineers that can balance good product intuition with the technical ability and foresight to build something for scale. Iterating quickly usually comes at the cost of scalability, but Architects - the persona I feel embodied by most great startup CTOs - have the uncanny ability to see these as complimentary colors. It's amazing to be part of a team with an Architect and I have been extremely lucky to have one as my parter in crime for the last 5 years.

But enough gushing about Keith. Let's take a look at our last persona...

📈 The Optimizer

The Optimizer is the engineer's engineer. The word "blazingly" gets them going almost as much as opening Vim. With a mind for speed and scalability, they are experts in making an application run fast and stay fast. They light up when talking about things like Big-O notation, Kubernetes, or Microservices.

They usually don't have the greatest sense of design. Their personal websites are often just straight HTML with no images. Hey, what's faster than just shipping bare metal, right? They also usually don't focus on product and often leave others to the work of discovering what to build; but once you tell them to build it, man is it gonna be fast.

Now, if you still don't feel aligned with any of these personas after reading through their descriptions, that's okay. Like I said, I made this as a tool for self-reflection - it's not meant to be prescriptive or absolute.

So, regardless of where you feel you fall, I want to talk about the obvious next question this exercise poses...

🤔 Is it better to be a specialist or generalist?

At first glance, it might seem like the ideal full stack engineer sits in the middle between the axes - a jack of all trades but master of none. But I believe there's also value in picking a vector from the center and making that our main area of focus. In reality, I think specializing or generalizing really depends on our interests, the needs of our teams, and the stage of our career.

I don't think we should force ourselves into an area of focus that doesn't align with our interests. We learn best when we have a genuine desire to pick up new skills and information. So, if we find ourselves with gaps on a certain side of the spectrum but no motivation to fill them, I think that's okay. I think the best thing we can do is follow our own curiosity. Our interests change with time, and in a few years, something might compel us to move in a different direction.

One of those catalysts for change is often the needs of our teams. Although we might be experts in one area of focus, we are often called to be the "experts in the room" for our teams in a more unknown area. For example, I'm most comfortable playing the role of The Hacker and focusing on product and design. However, I often take on devops and process optimization projects at my company - playing the part of The Optimizer. This dynamic of switching focus to fill in the gaps of team knowledge can be a great time to get out of our comfort zone and learn something new.

These moments to try on different hats is also extremely important for those earlier in their career. Exposure to real world problem-solving in each area of the stack is the best way to discover our interests and find the parts of building applications that light us up. And drudging through areas we aren't interested in also helps us build an appreciation for people who enjoy the parts of development that we don't.

👋 What do you think?

I hope this diagram was interesting and can be helpful as a reflective tool as you move through your career as a full stack engineer. If it was, consider sharing it with your team - I think it could be really valuable as a way of discussing areas of interest and knowledge gaps.

As always, I write to share what I've learned and spark conversations that help me learn from others. I'd love to hear your thoughts on Twitter, LinkedIn, or over email if social media isn't your thing.

Also, if you want to get notified the next time I post an article like this, you can sign up for my newsletter using the form down below.

Until next time.