Why frontend developers NEVER get promoted

Frontend developers never get promoted because they are limited by the systems they work on. Your skills can only be as good as the problem you're solving. Sure, you could learn some backend and go full stack and do a thousand different things, but not so well. What if there's a better way to level up without having to betray your craft? In this video, we are going to travel from junior front and developer all the way up to mid-level, senior and beyond.

At every stage, you are going to find out exactly what you need for you to unlock the next level. But for now, let's get back to where we all started. That's junior death. And the first question that best to mind it's what is a junior frontend developer in the first place? Well, while there are many definitions being thrown around on the internet, a junior developer, it's a frontend developer who can deliver component level solutions.

This can include small features, unit tests, even documentation. Junior devs can work well in a controlled environment with proper guidelines and they can use templates or cheat sheets. For example, they can copy paste a test and then adapt it to their own use case. Juniors can also work very well on the implementation level. One good example, it's accessibility. Exactly, Dragos, like you mentioned, juniors work on component level problems, or they do things like styling emails with a lot of markdown.

They always work in a controlled environment and they get a lot of help. deploying and finalizing their work, which usually gets reviewed by a senior developer, and they usually fix the edge cases that might left over or add additional tests to make sure that the junior developer code it's production ready. Now, as you probably know, there's a lot of things that junior front and developers actually struggle with, things they cannot really do.

Like, for example, junior developers need a lot of assistance when dealing with high-level design decision, like deployment, like architecture. Juniors also have weak fundamentals, So whenever they will get a weird bug, they will either throw it to GPT these days, or Google it immediately. But they struggle following through and doing a decent good cause analysis. This is why it usually takes them longer to solve more complex bugs, or they'll go into these infinite loops until they would ultimately need help from a senior to get unstuck. Another thing, junior front end devs really struggle with it's whenever you have to deal with things outside the system, right? Things like fetching data, authentication, security, again, junior devs are great for component level solutions. Not so much for application or system-wide solutions. Whenever you are working with a junior front end and they need to fetch data, you need to be very explicit in what is the exact call they need to do and very explicit in what do they receive back. Because they cannot really improvise outside that component boundary. And finally, junior devs struggle to define problems and solutions, right? They they cannot, for example, work alone directly with product managers and work out directly from business requirements. You're probably asking yourself, hey, but when do you stop being a junior? Well, you start being a junior dev when you can handle application level tasks without difficulties. And bear in mind, this can take six months or six years. It's really up to you. So you know you are past the junior level when you can take on more global problems in the application. You can work with global state, you can work on global CSS styles. You can define components that are reusable and other and other teams or other developers will use in the same application, but in a different feature context. You'll also start handling tasks regarding the overall web performance of the application. Now, a lot of junior front end developers that I talk to these days find themselves very demotivated and some of them don't try to improve their skills at all. Because aren't companies only hiring senior devs these days? And you might have a point. But

There's a way for you to get hired as a junior developer, even in a senior only market, because companies don't only want senior devs. They can't even afford senior devs in many cases. What they don't want, it's juniors. They just don't want junior devs, because junior devs are seen as a liability, as someone that needs guidance and training and mentorship for them to actually be productive and give a positive return on investment for the company.

Once you understand that, you realize what you really need to get hired right now as a junior dev is to develop a senior dev mindset regardless of your skills. What does that mean? Basically, the key here, it's not to do more, but to do better. For example, do not try to learn another programming language, simply get better at JavaScript or at the stuff you are already doing. Same with frameworks.

Exactly. And this is one of the hardest things for juniors because they get bombarded with all this information while they just are starting out, everybody's telling them that you should learn this framework or that you should learn Go and that you should start with Rust or you should do Zig. And all this noise is coming to you in a very vulnerable position when you cannot really discriminate the signal from the noise because you don't have those references.

Now, what you really want to do when you're at a junior level is get extremely good at the skills companies actually hire for. Those are the only ones that matters. The people that will pay you and grow your career want someone that can write working software. That's it. Sometimes that will mean you need to get better at Vanilla JS. Sometimes it will mean CSS. Many times it will mean React or Angular or Vue.

That's pretty much the whole front end market, at least 94% of it. You can sure experiment with the other things, but again, here you are in a stage where you don't want more bread, you want to go deeper. Secondly, you want to get insanely good at doing things at component level. You want to really get good at delivering at the level you are at. And that will free up time and space for you to start thinking outside that box, for you to start going out and getting slightly more and more responsibility, and gradually moving up.

Which brings us to the third point, when you code it clean, when your PRs are not getting pushed back, then you have more free time that you can invest in you building up the skills to move to the application level. If you try to get to the application level before being able to do things well at component level, then you're just going to accumulate gaps and your imposter syndrome will only get worse.

Now that you nailed the junior level game, we can move on to the mid-level. So, what can a mid-level front end engineer do? A mid-level front end engineer can write end-to-end and integration tests. They can do application level debugging, look into things like global state, global CSS, performance optimization. Again, they can work at application level. They can negotiate scope and features with stakeholders, and even push back with dealing this application level.

And they can identify application level technical debt. So we saw how a junior developer would be focused around components and unit test, but as a mid level, they can go farther and work on end-to-end test inside, of course, a front end application, they get better at mocking, they get more comfortable with data requests and authentication state, and they can identify trade-offs inside the same application.

They can say where should certain state live? Should we lift state? Should we do prop drilling there? And that touches on the last point you made, which is identifying application level technical debt, so they start reviewing their code. They start understanding the consequences, at least the mid-term consequences of the choices they've made. mid level is that there's a lot of unconscious incompetence.

And so, because people are so good in application level, they many times overestimate what they can do. Usually they find out how good they really are when they go to the market. And that's when people usually struggle to get that senior job, even if they felt like they were senior, because they're working on the same application, they're very familiar with that code, and maybe in that boundary they deliver at the senior level.

But that's only because they are playing in their comfort zone. Now, what mid-level front end engineers cannot actually do? Well, they can give limited input outside of their specialization. If they are a front end engineer, they cannot comment too much on back and work. Exactly. So, if you put a mid-level front end engineer in the same room with somebody that's very deep in the database, they would need someone in between to help them reach a conclusion.

Because they speak very different languages, and there's no way for them to actually bridge that gap. Secondly, mid-level front end engineers cannot do system wide decisions or third-party integrations. Exactly. So that's when you'll see at the mid-level that there are a lot of struggles, because once they start reaching out of the system, their skills go closer to a junior level. Where they need a lot of guidance, they're not that fast anymore.

It feels a lot harder, and again, when we talk about system wide decisions, we are referring to the front end. Another behavior you'll see a lot, it's these debates about frameworks or versus webpack or prettier or which subset of configuration we should use. Because again, as I mentioned before, there's a lot of unconscious incompetence at the mid-level. So, yeah, mid-level engineers can deliver, but they struggle building things from scratch.

They cannot make system wide decisions. And they can, of course, support junior devs into solving issues, but they cannot really teach them. Exactly. A lot of the things you hear from junior devs when they get helped with a mid level it or they didn't show me how to do it. They just went ahead and do it themselves. Because at the mid level, they still have a lot of problems, verbalizing their expertise and understanding in depth the problems, but they can solve it mostly as a reflex because again, they are so familiar with that specific application that they know it almost at an unconscious level.

Which is why mid level, it's where most front end developers get stuck. Exactly, you can spend 5 to 10 years at this level. People will switch jobs and it will be pretty much the same job, maybe a different application, but building the same, and you never really expand. The reason for this is because again, you are delivering at that level, so it makes sense for companies to keep hiring you at that level, and they're afraid of giving you more responsibility outside that level because they feel like it's a very low risk decision for you to have you there.

On top of that, mainstream advice about how to get better as a software engineer doesn't usually work past this mid level. Do everything at once, as fast as you can do web performance, do data structures, do testing, do cloud. will only get you confused, overwhelmed and burn out. And unfortunately, this is what most people here on YouTube recommend you to do because honestly, many of them don't know any better.

Exactly, and so you have people studying Kubernetes or studying system design when they cannot really explain well what a closure is, and they cannot really explain what the event loop is. Or they cannot work with a promise constructor. And so people will jump towards this fancy high level Kubernetes distributed caching buzz words that will give them a false feeling of seniority, but then again, going into the market, they will stumble about basic questions in technical interviews like, can you give me a real life example in your code of where you used a closure?

Or can you tell me the difference between a sync weight and promises? This again, it's mid level knowledge, because everything I mentioned, it will help you solve problems at application level. Another piece of advice, you see, it's do some side projects, because then you get to practice things that you don't usually get to practice on your day job. But that's pretty false because production experience it's the only thing that counts.

If you've ever tried to actually bring something to production, you will understand that users are the real test. Exactly. And you'll build the same to-do app in a different framework with some different add-on. But at the same time, the experience wouldn't get better, at some point you'll quit that side project. Or they would add it to a portfolio website, which would be even a worse move because there's nothing that screams more junior or mid-level than a portfolio website.

And the other thing they underestimate, and this again comes from a lack of seniority. It's how much effort goes into making a side project look good, so you can actually use it at something that puts you in a in a spotlight, it's extremely hard. And so that's probably one of the worst things I would recommend. Another thing that people would mention it's, hey, why don't you go and do some open source?

Which is like telling an average runner to go run at the Olympics. And most developers are not Linus Torvalds. In the best cases, it's unrealistic and it won't probably pay off because it's outside of the skill set most mid-level developers have. And again, really contributing to a complex open source project, it's almost a full-time job. You need to be extremely familiar with that specific use case and acknowledge the use to actually be able to solve the issues those projects have.

This is why what you see in the JavaScript world, it's so many libraries solving the same thing because everybody's starting the same mini library and open sourcing the same thing. But in reality, if you're looking for reliable libraries, you'll see that there's just so many issues when you install things. There's so many security vulnerabilities we have, because people are rushing towards open source to use it as a V2.

signaling to to show off that they have that seniority. In reality, the fastest path to senior front end engineer is unit level mastery. Unit level mastery skills, rather than chasing shiny objects. And the best way to do that is to start with your technical gaps, which is why Bogdan and I have put together this free 10-minute technical assessment for JavaScript engineers like you who are looking to find out their technical gaps and develop what we call unit level mastery.

Which brings us to the senior dev. So, what can a senior dev do that a mid-level cannot? Well, senior developers can make system-wide design decisions. They can set up services from scratch, and they're not limited by frameworks. Frameworks are just tools. Seniors also consider second-order consequences. So, seniors would be a bit more conservative when it comes to changing configurations, adding the new shiny object to the code base, and that's also because they have better mental models, they can be faster not only in a single front end application, but in different front end applications.

So, they're not bound into a specific framework or this specific architecture style. They can adapt faster and make much better decisions. Senior devs can also implement complex patterns, such as dependency injection. They can work fully independently with product managers and stakeholders, and they can negotiate technical specifications with other development teams. Exactly. So seniors have a lot more productivity, and they can talk to the backend, and they get together, talk about trade offs on how we will design the rest API.

And they can also make the backend see why certain things will take longer, how to make certain things easier from the front-end perspective. When it comes to working with product, seniors are really good at bringing to the table one to three technical decisions and helping product choose which one is better, while giving them a lot of transparency on how long something takes. And that's why companies love seniors or they say they want somebody that's a senior, what they actually love, it's the quality and the time of delivery.

when you work with a real senior. So, again, it's not necessarily only about clean code or solid principles or covering all your code with test. But it's about how well you integrate those skills that you have with the rest of the company and push projects forward. Software projects are complex. Things go wrong. People overestimate. There's never enough time to do everything. And seniors are very good at navigating all this environment and deliver value in the software.

Now, senior devs are pretty amazing. But there's a bunch of things they still cannot do as well. Senior devs rarely think in third order consequences. Exactly, so a senior front end can really well tell you why and when doing server side rendering with a framework like Nextjs, it's a good idea. They understand the core web vitals. They understand that if you have any commerce use case, for example, you need speed and you need SEO, and that's when it makes sense to bring in a framework like that.

What they struggle with, it's CD effect of adding that framework to. the company tech stack, which all of a sudden makes it harder, for example, to hire people, or it adds unnecessary complexity, which makes everything takes longer. That it's a third order consequence that somebody passed the senior level have seen before and can bring to the table. Senior devs are also still very much focused on feature development versus system development.

And finally, their productivity, it's very much bounded by the platform. Exactly, so seniors are usually the the powerhouse of the software team, they are usually in charge of shipping features and solving production bugs. And so because they are so involved in that, it's sometimes hard to think in terms of the platform we are building. It's not only we are building software for the users, right, and not only we are building user features.

But we are building the platform on top of which the other teams built software. This doesn't mean we are setting up Kubernetes to deploy everybody's containers. That's DevOps. This means we are building the architecture in a way and we different teams can extend it. When you go to that level of abstraction, it's a bit harder to follow for seniors. Or they might be able to understand it in an abstract way, but going from there and bringing it down to Earth, well that means in the everyday life or how you can how you can advice a C-level executive, like a CTO, on what they should do next.

That's when it falls a bit short. Senority, it's contextual still in that case. And so if you get someone that's a senior web developer, it will take a bit longer for them to be a senior embedded developer, for example, or even switch to mobile. Because a lot of the seniority, even if it's not application bounded, it's bounded to the web platform. It's bounded to the web APIs that they've been using, they know how things are done in JavaScript or in the browser, but it's much harder to bring that into C# or go do the same thing in Java, or go do it in an environment that you're not extremely familiar with.

Seniors sometimes have very strong opinions based on their experience. And it's sometimes extremely hard if you have three senior developers in the same team to reach consensus. Building a button takes more than an hour because everybody has a very strong opinion about how it should be done. And this is why going back to this senior only market, we do see companies start hiring again for junior and mid level, because sometimes you want to grow your own talent.

You want to make sure that they have the right mentality. Some people might come from another company with a senior title and senior salary expectations, but that doesn't mean that you as a company or a team will actually be able to integrate that person and reap the the value of their experience. That's why companies do normally promote a mix of talent in a team, because too many cooks spoil the food.

So, you got to senior at this point, you could consider going full stack or, of course, getting to the next level, which brings us to the last level, the principal developer, also called staff engineer. A principal or staff engineer can do everything a senior does, plus they can make strategic decisions regarding company wide text stack. incredibly versatile. They can coordinate simultaneously with different teams. They can remove blockers for the development team, right? They can prevent problems even before they happen. They can help define the product road map, like for example, work with stakeholders who are very far from the code, and they usually bypass the management level and work very closely to the C level. In some companies, they're also called a front end lead or architect. Yes, so as a principal engineer, you are expected to push the company tech vision forward. And I know this sounds very generic, but actually this is very concrete. At principal level, you need to master everything we talk about and be able to bring that to people that have no idea of the technical stuff. People that maybe are the chief of sales or the chief of marketing, and you can work together with them to see where does the tech stack need to move. So, for example, um, someone that's building the tech radar of the company, right? Someone that's advising the CTO and the tech leads towards the direction of the architecture, right? Building architecture blueprints together with different teams. Exactly. And a lot of people are misled and think, well, when I get to principal front engineer, I will only do architecture or I only do system design. The reality is you do everything we've mentioned plus system design plus architecture. This is why you'll use your fundamentals more than ever. For principal engineers, coding, writing components, building applications, setting up pipelines, it's as easy as speaking English for a native speaker. It comes almost as a reflex. And that's why they usually tackle the hardest problems in the company. And I remember very well, when I was a senior there, we had a principal engineer that would attend some of our meetings, whenever, for example, we had to coordinate with with other teams, and this person was speaking up the nastiest headers problems we faced, which were usually things like edge cases or we had to integrate when we had to integrate different front end applications.

in one micro front end, which was something that nobody ever did in the company. They were the ones that kind of joined these meetings together with the CTO and the tech leads and kind of building these things from bottom up, basically from scratch. Which for me, even if I was already at senior level, it was extremely high to to grasp because my my knowledge, even if it was senior level, it was very much scoped to the front end position I was in.

But there's a problem. Principal level front end positions are not very common, right? Because you become a big fish in a small pond. Only companies with big teams can support this kind of positions because many of them are over specialized, right? We're talking about the principal engineer in the front end. Those are usually companies with complex front end applications. Think about products like Myro, Canva, Google Sheets, Google Docs, Webflow, Photoshop.

Those were desktop apps that have been ported to the browser. The technical complexity there, it's much bigger than for example, a static website. Now, the good news are that a lot of products are becoming client heavy. A lot of desktop software, it's falling out of grace and being ported to the browser. People are building web app. Even Microsoft, it's moving their office suite to the browser. At the same time, more and more clients are being created.

We have software running in autonomous cars, we have wearables. And finally, more and more people and devices are getting connected to high speed internet. Meaning that staff and principle level front end development positions will only increase. So no, full stack, it's not the only way. You can stay a front end engineer, keep improving your skills and have a very bright future. Yes, and keep in mind that a principle level position usually has much higher compensation.

Then even a senior full stack and even than most engineering managers. And they have a lot more job security. So although these positions are very scarce, they are usually much more secure. I believe they're also more enjoyable because you get to build really cool stuff. f, but of course, you need to be extremely dedicated to the craft.