Hi friends 👋 Welcome to a new edition of Frontend at Scale, the only newsletter with the word "frontend" in its name that sometimes isn't about frontend at all.

That's not the case today, though. Today's essay is very much about frontend development, and it's a bit of a preamble to one of the exciting projects I'm planning to work on and share with you all this year.

It doesn't have a name yet, but it'll be a series of interviews with people who have had successful careers in tech coming from a frontend/UI/JavaScript-heavy background. I love hearing stories from folks who have walked the path before and I always learn a ton from their experiences. So yes, this is pretty much a way for me to satisfy my own curiosity, but hopefully, it'll also be a way to share invaluable knowledge we could all apply to our own work.

If that sounds interesting to you, please reply to this email (or email me at [email protected]) and let me know! I will be much less likely to procrastinate on this project if I know some of you are looking forward to it :)

Alright, we have a meaty topic to chat about today, so I don't wanna make the intro too long. Let's dive in.

MAXI'S RAMBLINGS

Breaking the Frontend Ceiling

If there's a list of questions that are sure to cause controversy in tech Twitter, here's one that will surely be at the top:

Do frontend developers have a lower career ceiling than backend developers?

As with most arguments on Twitter (and social media in general, really), there are plenty of people in both camps, passionately defending their side of the tech stack with examples, counter-examples, and the occasional all-caps breakdown. I don’t usually participate in these discussions, but I enjoy watching from the sidelines because I think it’s a worthwhile topic to talk about.

There’s one thing that bothers me, though.

While most people try to answer this question from a curiosity standpoint, there are others who will outright try to convince you that if you’ve chosen a career in frontend development, you’ve chosen wrong. That by choosing to be a frontend developer, you’ve chosen a path that will never lead to Principal Engineer, VP of Engineering, or whatever your aspirations might be. That your only options are to change paths and fully devote yourself to the more serious discipline of backend development, or to settle for a mediocre career as a forever-senior frontend engineer.

Well, I just couldn’t disagree more with that. I believe it's entirely possible to have a thriving career without leaving your frontend roots behind. And if you allow me to take out my soapbox and stand on it for the next few minutes, I’ll gladly tell you why.

Backend’s Little Brother

Before we get too deep in the weeds, we should probably start with a more basic question—why are we even talking about this?

Or, to be more precise, if there is indeed a lower career ceiling for frontend developers, what could be the reason for it?

Is it because frontend is an “easier” discipline than backend development? Or perhaps it’s because it has a lower barrier of entry? Or maybe, and hear me out here, it’s because frontend is “less technical.”

None of these make sense to me.

As anyone who’s ever had to set up a Webpack build or debug an infinite loop that only happens in Firefox on Tuesdays at 3 pm will tell you, building a modern frontend application is certainly not an easier endeavor than building, say, a REST API. I can’t say that frontend is harder than backend either. Heck, I can’t even say that they’re equally as hard. Frontend and backend development focus on domain problems so different that no matter what dimension we use, it’s never going to be an apples to apples comparison.

The lower barrier of entry argument is also debatable. Yes, maybe it’s easier to get started with some basic HTML, CSS and JS than it is to get started with the JVM, but it won’t be long before you get overwhelmed by all the different tools that today are considered table-stakes knowledge for any frontend developer: Vite, ESLint, Prettier, TypeScript, Tailwind, React, and probably a dozen others—each with its own config file that has to be precisely defined so that all these libraries play along nicely with each other. It’s a pretty high barrier of entry if you ask me, so I don’t think that’s the reason either.

And finally, the “less technical” argument. But, what does “less technical” even mean? Is Svelte’s reactivity less technical than C#’s object-oriented model? Is the obscure syntax of some programming languages more technical than plain-ol’ easy-to-understand JavaScript?

Of course not.

And yet, even though we can’t come up with a logical explanation for it, frontend development is very much treated as a second-class citizen among people doing “real” software engineering. At best, frontend is treated as backend’s little brother, with its cute drawings and CSS animations, but no real programming skills.

If you’re a frontend developer, I’m sure I don’t need to explain this to you. We’ve all felt it, haven’t we? The need to justify our technical knowledge in fear that we’ll be considered less capable engineers than our backend counterparts.

I’m fortunate to work at a place and have a role where I don’t feel the constant need to justify how “technical” I am. But this wasn’t always the case, and I still feel it whenever I introduce myself to a new circle of developers (at a conference, at a meetup, or online) as a mere frontend engineer.

“But wait, there’s more!” I wanna say. “I can also shard a database and design an API. I’m pretty good at system design and architecture, too. I even know what Kubernetes is, sort of!”

I don’t actually say these things of course, but even if I did, it wouldn’t be much help. As soon as the word “frontend” comes out of my mouth, people immediately tag me as someone whose job is to make things look pretty, but who’s certainly not a real programmer. Joke’s on them—I can’t make things look pretty even if I tried.

Is “full-stack” the answer?

Unfortunately no. While the term “full-stack” was supposed to communicate the nuance of a discipline that can do more than one thing, in reality it isn’t that much better.

Walk into a room full of backend people and say that you’re a full-stack engineer, and you’ll immediately get a suspicious look as people try to determine if you are really a full-stack engineer, or just a frontend engineer in disguise. Don’t be surprised if you start to get quizzed about your backend knowledge.

The sad thing is that even if you get all the answers right and pass the backend quiz, you might still be denied a seat at the big kid’s table. After all, if you were a real backend developer, you would have said so. The unspoken agreement seems to be that not only frontend development isn’t a serious discipline, but that real developers shouldn’t have any frontend skills at all.

But that’s enough complaining for one day. Is this a frustrating situation for frontend developers? Sure. But I know my little rant here is not going to change anything. I don’t think it’s possible to change the way an entire industry looks at our discipline, so honestly, I wouldn’t even try. Also, it’s Sunday and I’m tired.

Instead, a much more interesting conversation to have is figuring out how you (or me, or any individual person) can break through the ceiling and misconceptions despite their frontend origins.

And it all starts with a discussion about pillars.

Breaking Through

Whether the frontend ceiling exists or not, the truth is that anyone on the Individual Contributor (IC) track will eventually hit a ceiling in their careers if they only focus on developing their technical skills.

Let’s take a look at a typical career ladder in tech companies.

Up to the Senior Engineer level, you can get around by focusing on your hard, technical skills alone—plus any soft skills you collect along the way. But beyond that level, you’ll have to start focusing more heavily on other areas.

I will talk about the IC track here because that’s the one I have experience with. But even if your aspirations are on the manager’s path, the same principle applies—if you want to keep leveling up, you have to increase your impact.

My favorite way to visualize this concept is what Tanya Reilly calls “The Pillars of Staff Engineering.” In her fantastic book The Staff Engineer’s Path, Tanya teaches us that our impact in the organization is determined by how strong these three pillars are:

• Big-picture thinking: the ability to take a step back and take a broader view; to think longer term and to consider more context.
• Execution: the ability to tackle bigger, messier, more impactful projects with increasingly ambiguous requirements.
• Leveling up: the ability to grow the engineers around us, both within and outside the organization.

The stronger our pillars are, the bigger and more positive our impact will be. The bigger our impact, the higher in the career ladder we’ll go. The higher we go, the larger our income. The larger our income, the more we can spend on those fancy cheeses they sell at Costco. Have you tried their Kirkland-brand Pecorino Romano cheese? It’s so good! Anyway, what were we talking about? Oh, yes. Pillars.

Embedded in these three pillars are what we often refer to as “soft” skills—communication, leadership, mentorship, and so on. Developing these skills are were most of the advice around becoming a Staff+ engineer focuses on, which makes sense since most software engineers aren’t naturally good at these things.

But while these soft skills are obviously crucially important, there’s one aspect that is often overlooked when it comes to leveling up your career as an IC, which is that you have to keep developing your technical skills as well.

You’ll notice that in Tanya’s diagram, the pillars sit on top of a foundation of technical knowledge. These are your “hard” skills, such as your ability to build a React application, or all your knowledge about accessibility and performance. This foundation of hard skills plays an equally important role in the impact you can have.

So what we can deduct from this is that, as an Individual Contributor, you increase your impact not only by making your pillars stronger but also by developing a stronger foundation of technical knowledge. The thing is, not every type of technical knowledge will help you increase your impact—there’s a type of knowledge that will have a disproportionate effect here, and it’s the knowledge that develops your technical breadth.

We’ve talked about this concept a few times before. Developing your technical breadth is something that Mark Richards considers to be a key trait of Software Architects, but it really applies to anyone looking to advance their career up to and beyond the Staff level.

For frontend developers, developing their technical breadth means learning more about adjacent areas such as backend and data engineering, as well as product management and design. Not because this type of knowledge is better, or harder, or because it’ll earn you the respect of your peers, but because broader knowledge will help you develop a stronger foundation, which in turn will result in having a bigger impact.

I want to be clear here—this doesn’t mean that you have to leave your frontend roots behind and focus only on other areas. By all means, continue to develop your technical depth as well (your core frontend knowledge), but be conscious of how you balance your learning. Focusing only on depth of knowledge will have diminishing returns, but you also want to avoid coming “all breadth and no depth.” I know, it’s a hard balance.

My favorite thing about Tanya’s pillars of staff engineering is that it makes it really clear that all of us in the IC track are essentially on the same boat. No matter where in the stack our expertise is—frontend, backend, mobile, game, data, whatever SREs work on—we all have to follow the same recipe if we want to increase our impact and advance our careers:

• Develop stronger pillars by focusing on big-picture thinking, execution, and leveling up other engineers.
• Develop a stronger foundation by expanding our technical breadth—without completely neglecting our technical depth.

Simple? Yes. Easy? Absolutely not. But this is your career we’re talking about, not some random weekend project. It’s not supposed to be easy.

You might argue that after going through this process of expanding your technical breadth, developing stronger pillars, and seeing your calendar fill up with meetings leaving little time to code, you couldn’t be considered a frontend engineer anymore. And maybe that’s true. But it’s also true of any other discipline.

As people rightfully call out, what got you here won’t get you there. You will have to go out of your comfort zone to keep leveling up. But the things that got you here as a frontend developer—your passion for UX, your knowledge of accessibility, your awareness of how hard building a modern frontend application can be—are as valuable as any of the skills “real” programmers bring to the table.

ARCHITECTURE SNACKS

Links Worth Checking Out

1. I enjoyed this talk by Rasmus Kromann-Larsen on the good, the bad, and the weird aspects of working on side projects as a software developer. Rasmus has been working on side projects for many years, including maintaining one of the most popular sites used by the Path of Exile community. He shares tons of tips on getting started, making the time, and how to keep the momentum going.
2. There's a new reactive framework on the block, but it's a... backend framework? Skip launched its alpha release this week, promising to bring the full power of real-time reactivity to the backend, allowing engineers to build better systems faster. If that doesn't make any sense, Theo has a good video explaining how it works.
3. Corbin Crutchley launched the second edition of his Framework Field Guide, a three-part online book that teaches you Angular, React, and Vue all at once. Best of all? It's free!
4. You might have heard that React is adding its first-ever animation API based on the amazing View Transition API. Matt Perry, the creator of the Notion animation library, talks about what that means and why it's a big deal.
5. Una wrote an article covering the latest updates of one of the most anticipated features coming to web browsers worldwide: the customizable select API.
6. Martjin Hols wrote about the essential accessibility features every frontend developer should know, which is great news for all of us who often find accessibility to be so overwhelmingly difficult.
7. Carson Gross and Alex Petros wrote about the future of htmx, stability over new features, and their very ambitious plan of becoming the next jQuery.
8. If you're as confused as I am about how Node.js is adding TypeScript support by removing types from your code, Marco Ippolito gots us covered with his article on everything we need to know about Node.js type stripping.

That’s all for today, friends! Thank you for making it all the way to the end. If you enjoyed the newsletter, it would mean the world to me if you’d share it with your friends and coworkers. (And if you didn't enjoy it, why not share it with an enemy?)

Did someone forward this to you? First of all, tell them how awesome they are, and then consider subscribing to the newsletter to get the next issue right in your inbox.

I read and reply to all of your comments. Feel free to reach out on Twitter, LinkedIn, or reply to this email directly with any feedback or questions.

Have a great week 👋

– Maxi