Engineering video
6:54 · 18 July 2024
Dealing with product managers who demand pixel-perfect UI and repeatedly push back work over one-pixel differences causes burnout, which can be mitigated by defining development standards, estimating changes, or using global stylesheets and design systems.
Hear it at 0:33 →Enduring six or seven interview rounds that result in rejection, ghosting, or irrelevant full-stack and database questions leads to disappointment and demotivation. Developers can avoid this by seeking companies with shorter processes or running multiple short interviews simultaneously.
Hear it at 1:07 →Constantly feeling pressured to learn new front-end libraries and frameworks from social media creates a sensation of never catching up. The solution is to focus on durable knowledge like how browsers work and to limit exposure to shiny object mania on social media and newsletters.
Hear it at 1:56 →Unchecked feature additions by stakeholders turn projects into never-ending endeavors that risk becoming legacy code before release. Mitigate this by avoiding commitments to improperly specified features and spending as much time refining requirements as coding.
Hear it at 2:36 →Jumping into UI development based on rough deadlines and unstated expectations leads to unwanted results and rework. Developers should halt coding until requirements are fully clarified and documented in writing.
Hear it at 3:26 →Because front-end work is visual, non-engineers often micromanage and pressure developers for faster timelines. If management lacks a professional product owner, the best remedy is often to look for another company.
Hear it at 3:55 →Dealing with back-end developers who assume code is self-documented creates friction for front-end engineers. This can be addressed by setting common standards, clearly communicating needs without emotional reaction, and telling back-end teams what is required.
Hear it at 4:34 →Constantly switching between different codebases, frameworks, meetings, and bug fixes fragments a developer's time. This can be prevented by blocking calendar time for deep work and batching similar tasks together.
Hear it at 5:17 →Supporting thousands of browsers and devices with inconsistent feature support—such as spending excessive time on Internet Explorer—causes major friction. Teams can fix this by convincing management to encourage users to upgrade outdated browsers instead of wasting development resources.
Hear it at 5:42 →I meant over 250 front end developers helping them move to a senior level and beyond. And what I realized is that success sometimes comes not from being a JavaScript genius, which of course helps, but from doing the right things and doing them for a sustained period of time, which sounds easy, but it's not. Because most front end developers burn out before getting to the point of being successful.
Here are the 11 most important reasons why front end developers burn out, and how you can avoid them to make sure that you stay in the game long enough for you to be successful. The first one, it's pixel pushing. For example, if as a front end developer, you have a product manager who wants like pixel perfect UI, and they're constantly pushing things back to development because of one pixel differences.
You will inevitably burn out. To fix this, you should talk to your product manager up front and define some development standards. If they want pixel perfect UIs, then you should estimate the changes. Of course, it will take longer. The other way is to encode these standards into your design system or global style sheets. So you kind of define once, implement everywhere, and make things easier for yourself.
The second sure way to burn out as a front end developer, it's by having endless interview rounds. Having to go to six or seven interview rounds, just to get rejected or worse, ghosted, is a sure way to burn out and end up disappointed and demotivated. What also happens is that by the time you get to the fourth interview, people forget that you were interviewing for a front end position and start asking you full stack or back end questions, like how to petition database and wine.
You cannot really choose how to be interviewed. What you can choose, it's which company to interview for. If you can, avoid companies with long interview processes. And if you have a long interview process, then do other shorter interview processes at the same time. So you don't put all your eggs in the same basket and at least avoid being disappointed at the end. The third sure way to burn out, it's framework fatigue.
This one is pretty common. YouTube feed, you see some new front end library or a front end framework you are supposed to learn. And if you do this for long enough time, you're going to start feeling like no matter how much time you spend learning, you will never manage to catch up. A way around this is to focus on durable knowledge, on the things that don't change so often. JavaScript frameworks might change.
But the way browsers work, it's quite similar to five or even 10 years ago. The next thing you can do to avoid framework fatigue is to simply opt out of this shiny object mania, and limit the time you spend on YouTube, social media, limit the newsletters you are subscribed to, just limit your exposure. The fourth reason why front end developers burn out, it's scope creep. I bet you've been in this situation at least once in your life as a front end engineer.
You know, you start defining some initial requirements, then you start working on that. Then the product manager or stakeholders keep adding features and changing things. And it quickly becomes a never ending project. I remember in my second job as a developer, once it took us so long to get a project to production, like about the year, that we had a joke in the development team that the moment we will release it, it will actually become legacy code because it's so late already.
Scope creep will happen from time to time, no matter what you do. But a good way to mitigate it is to avoid committing to things that haven't been properly specified. So, spend as much time refining requirements as you spend coding. Of course, you cannot do this if you are not good at coding, so get good at coding first. On to the next one, unclear requirements. This one is kind of self-explanatory, but sometimes people think that you as a front end developer can read their mind.
They give you some rough deadlines of how the UI should look like. And you jump in, you try to build it, they don't like it and ask for changes. Back to scope creep. Again, the solution here, it's roughly the same. But make sure you have clear requirements before you start working. And if not, don't start coding, ask for clarifications and have it all in writing. Which gets me to the next reason why front developers burn out, and that is having their or either estimates question by the management or the product managers, which always one thing is faster and faster.
The problem with front end is that it's so visual that everybody can have an opinion about it. The other problem is that sometimes you have a marketing kid in the management who is able to add Google Analytics pixel to the website and already thinks of themselves as some kind of software engineer and they start getting into your estimates, also called micromanagement. I wish I could give you a perfect solution for this one, but unless they've hired a professional product owner, you should really look for another company to work for.
The next sure way to burn out as a front end developer is having to deal with undocumented APIs or with back end developers who assume that the code is self- documented and that, you know, everything you need is right there for you to implement it, and you should just grab their API endpoint or client or whatever and work with it out of the box. And while you cannot really control how the back end development team does their job, what you can do is to try to set some common standards and communicate your needs as a front end engineer clearly.
Also, try not to react emotionally in these situations. I had some bad experiences with back end teams, but most back end devs I've dealt with were nice and helpful. Just let them know what you need from them. Don't assume they know. The next sure way to burn out as a front end developer is by constantly switching between tasks, also called context switch. This can be switching different code bases, switching different frameworks, switching between coding, meetings, bug fixing, and whatever comes your way.
A good way to prevent this is to block your calendar during deep work times where no meetings are allowed, and by batching similar tasks together. The final reason why front end developers burn out, it's because the reality of our job, which is that we have to support thousands of browsers and devices and platforms that don't always support the same features. And sure, most ways you can add a polyfill to help you with that, but polyfills don't always cover all the use case.
I remember one of our projects, the front end team would spend 20% of their time developing your features, and 80% of the time getting them to work on Internet Explorer 11. What a freaking nightmare. The way we fix that is by convincing management that spending so much development time on supporting like 3% of our user base, it's a lot harder than just forcing our users to kind of upgrade their browsers because, you know, it's about time.
Okay, question for you now. What is one reason that maybe you've burned out as a front end developer? And how have you fixed it? Let us know in the comments. And by the way, if you're looking to develop that kind of durable knowledge, the best way to start is by understanding what you're the know first. Check out the free think skill assessment, link it's in the comments, which will help you find out your think gaps as a front end developer and give you personalized hints on how to fix them.
