There is a bias toward backend engineers at the principal engineer level. This leaves frontend engineers heavily disadvantaged when it comes to pro...
For further actions, you may consider blocking this person and/or reporting abuse
Front end skills are so often thought of as both beginner skills and "too hard to even bother with, lol" among a lot of the developer culture.
It can't be both for beginners and so hard that it's not worth doing. There's a stigma-oriented misalignment.
Interesting..I would say that there is a bias towards frontend engineers in the whole webdev area. I understand that YMMV, but this is my mileage. Sure, FE can be a fine principal engineer, but generally I would say it's not a trend that FEs are neglected.
Yeah, this has been my experience as well. There are far more front-end engineers at my company than any other kind of engineer (back-end, SRE, QA) by an almost 3-to-1 ratio. Everybody loves doing React and Vue, very little interest in digging into the GraphQL or REST back-ends. That's always reserved for a "specialist" or "Sarah does that for us".
Guessing that Principle Engineer is a more general position than specifically front or back end, I think you basically answer your own question. The position values general software engineering skills, like "networking, system design, database design, [...] or designing fault-tolerant systems". While, for the most part, the front end skills you bolded are just that, front end skills.
Don't get me wrong, I've focused on GUI design and development for the majority of my career, so I value UI skills very highly, but web accessibility, design concepts like microinteractions, and front end performance as skills aren't very portable outside the (mostly web) front end.
and networking & fault tolerance isn't portable outside backend
I would disagree here. Networking is very important if you build highly interactive multi-user front-end experiences. You MUST know networking, timing, interpolation, and queuing theory to properly build the client. This is a vital part of our front-end that heavily uses web sockets. It's also what you see being a big part of web-UI based mobile games or web UI's interacting with large worker queues or data visualization.
As for fault tolerance, as the infra scales, load balancing in the backend and the caching involved makes the client now have to be capable of handling these issues as well. What does your client do when the cache isn't hot and loaded? What happens when you're loading from an edge API as well as a more remote (less hot) API? A lot of this stuff is client side code and very relevant for a senior level front-end engineer to know!
What I'm getting at is that all of this knowledge and these skills cross the front-end and back-end barrier if you go up high enough in your career. The more responsibility you take on, regardless of background, the more you are required to learn and know!
I agree with all this
Thanks for reading, Ben!
Some of full-stack developers I know came from freelancing as a one-person band, myself included. It's hard, sometimes impossible, but inevitably teaches you the value of diversity.
I definitely see a dedicated front end developer in charge of consumer oriented product as a much better fit than a backend. But then a backend would be a better fit for a purely technical B2B company.
And I certainly agree that front-end is not by any means simpler, or, in the words of my fellow mobile developer: "It's pretty much the same, but you don't need to care about the view"
Points 2 and 3 are probably ignored in the case of companies with a dedicated UI/UX design team/person, where they want the front end dev to just implement the design. But other than that I totally agree that's way more useful than being able to solve the knapsack problem
Right now one of the biggest problems that businesses are concerned about is scalability, data is increasing and the bottleneck is usually the backend infrastructure. Ex, doesn't matter how good YouTube's UI is if videos don't load.
Because of this businesses put UX in the back burner, using pre built solutions and cutting as many edges as they can, heck they even do that with the backend. The backend is just the first point of improvement they focus on once they realize their business can't function anymore with a subpar product.
And even in design focused companies, what that usually translates to is hiring more designers, better UI mockups and design systems. Frontend engineers are mostly just treated like code monkeys that have to translate those designers into the product directly. No code level implementations of design systems, accessibility reviews, standard compliance, etc.
I agree. But there are companies which have separate teams for FE and BE engineers. There the leads for front end are usually specialist only on FE side. Same goes for BE.
What I would say is that there are less companies which have separate teams. Most of the companies just try to get "FULL STACK"
What's missing here is the concept of a T shaped developer.
Think of the vertical line as a deep understanding of a single area like front end (design, components, accessibility, responsive, UX etc), networks (routing, spanning trees, redundancy, capacity, monitoring, etc), databases (structure, scale, transactions, sql/nosql, redundancy, scalability, monitoring, consistency, etc. ), micro services (api, server/serverless, messaging, events, scalability, availability etc) , cloud infrastructure, etc... Every area has more depth than most people appreciate.
Now the horizontal line is breadth of skills which are not so deep, so the backend dev who knows about HTML, CSS, and JavaScript may come across more T shaped.
My advice is don't over emphasis your depth in a single area and work on developing the wider skills. Remember as a good senior it's more about working with a skilled team who have depths you do not and not so much about being better than your peers.
If you are in even in semi-big corp you are hired to do one specific thing. If thats frontend you are missing most of the info about BE because well its not necessary to be part of those meetings / watercooler discussions.
That being said If company has its core business in the backend (which in most cases it is), BE sr. dev is more likely to be chosen as Principal.
Amazing article, thanks for sharing
Folks must be taking your advice to heart. The majority of promotions for higher level senior and principal positions are all front end engineers at my company. It's gotten to a point where all of the more back-end infrastructure focused folks struggle to be anything more than a cog in the machine who just keep the lights on.
As someone who does both, I really wish I could share the load on the back end infrastructure. Take it as anec-data how you will, but I'm tired of constantly being the only person who is willing to dig into the back-end infra, wrangling the tech debt and performance concerns that control how well our product scales. I wish we had more back-end engineers to work with.
Honestly, it's a bit painful how our team is mostly front-end focused. I know why, front-end is directly visible and is the face of the product the customer sees every day. Until there are performance concerns and the database is too expensive to run cause our API is slow. Then all of the sudden, you need that back-end engineer and want them to fix the issue so the company can go back to deploying new front-end led features.
I say this to point out that back-end is often a largely thankless job and that might be why some engineers who know the pain it is keeping a large infrastructure alive respect them so much. Optimizing queries, wrangling custom data caches, and keeping it all affordable without endlessly throwing money at the problem is sweaty work!
Thought there was already a Principal UI/UX Engineer?
Principal to me means an experienced expert, this you can achieve as either a backend or frontend developer.