Sneaky painful frontend burnout
The history of modern web development and the dangers that come with it
I've recently noticed an alarming trend. There is a high churn of frontend developers due to the burnout. It's a shame, but it totally makes sense if you take a deeper look at the problem. It's not something you normally notice. All burnouts are sneaky, but this one is special. It comes creeping very slowly and before you notice it's too late. This article is a personal reflection from the interviews conducted with people who decided to leave the frontend field due to the burnout.
Rough history of web development#
Things were simpler back in the days. jQuery was king and we relied on it to get things done. And we did get things done too. Browser wars made the frontend world accelerate at incredible speed. There were many new cool APIs we could use, but they were often browser specific. This created a lot of inconsistencies and forced us to use polyfills. Modernizr was a popular library that we relied on to detect what was possible for us to do in the browser.
The speed of browser advancements propelled the development of new tools. Bower was a popular, but short-lived package manager for the web that many developers relied on. We used different task runners such as Grunt and Gulp to get things done. The frontend ecosystem was getting complex, but we could still wrap our heads around it.
We were getting things done with the tools and libraries we had, but it wasn't enough. We wanted more and better tools. Webpack was gaining traction and Browserify was released and this is where I personally lost track of everything. I think it was around 2014 where things got blurry and made it impossible to keep track of all the news. This is also the year when I had my first frontend burnout and decided to move back to backend development. It became too much. I craved simplicity.
Let's fast forward to today and see if things have improved. The popular frameworks of the past are merely ghosts of their former glory. Today, React is the undisputed king followed by many other modern frameworks such as Svelte, Vue and Angular. TypeScript has become a de-facto standard language of web development. For sure, frameworks and languages have advanced for the better, but did they actually make our life simpler or allowed us to reduce time to market?
npm install broke the Internet#
My opinion is that npm install broke the Internet. There were a few different attempts to bring package management to Node.js and NPM won. Today it's the standard of JS package management, but in the beginning it was actually for managing packages for Node.js only, hence the name - Node Package Manager.
Not that long after developers realized that they could also publish frontend libraries to NPM. I think it was Bower package manager that started the trend. Sometimes later, Bower quickly became out of fashion when most of developers switched to different JS bundlers. Fast forward to today and think of one frontend project that doesn't use a bundler and downloads half of the Internet when you run npm install.
That's the norm today. Why is it like this? First, NPM's recommendation to package creation was to create small focused packages that do one thing and do it well and I was a big proponent of this myself telling all other developers to think this way. Second, it's often easier to find and install a package from NPM than to write it yourself. Is it a good thing? I am not sure. Remember the leftpad incident? Also, if you rely on some NPM package and find a bug in it, how much effort is required to fix it versus if you would have written the functionality yourself?
It's easy to add new packages to your project and if it's easy we tend to do it. We have too much freedom of choice. It's also a little too easy to publish packages on the NPM and everyone wants to scratch their own itch. I am not saying it's bad. On the contrary, sharing knowledge and contributing to open source is good, but does it really justify itself as NPM package? Maybe a simple Github gist is enough? Copy, paste, adjust.
Here is a thought experiment. Would you be able to build the same app with the same level of interactivity if you could only add your dependencies as scripts in the document head? How cautious would you be?
Enter TypeScript#
JavaScript is a cool language that mixes OOP with FP. Pick and choose. It's also a messy language. Actually not messy, but maybe the right word would be - flexible, and if you know your way around the language and all its quirks you will do just fine. Many existing websites and apps were written using plain JS.
When TypeScript entered the scene (almost) everyone cheered and thought that it will make all of their JS problems go away. Sure, it might have solved some of the existing problems, better IDE autocomplete comes to mind, but what people don't realize is that by adopting TypeScript they just made their developer lives more complex. If you ask me, TypeScript is a weird language with a fake type system that gives you fake confidence. I too do use TypeScript for some projects, but it feels like the only thing I do is try to keep the TypeScript compiler happy.
TypeScript is rarely frictionless, especially its setup. I bet there are very few developers that throw together a working tsconfig.json on the first try. It comes with a cost and it's something you have to think about. Because it's so wide-spread today, it's hard not to use TypeScript when building open source libraries. I mean, you don't want people to think you are a weirdo, right?
Adopting TypeScript is not enough. There is a whole JS surrounding ecosystem that you have to adopt to as well. Because JS is such a loose language you have to solve linting and code formatting. Should you adopt ESlint or StandardJS? Is there room for Prettier? If you go with ESlint what plugins do you need? Should you adopt Airbnb style or is there something else, something better and newer? You might want to introduce automatic linting too so you can't commit bad code. Husky might help you with it.
The tooling ecosystem surrounding JS adds additional complexity layer to your project. Now, I am sure that you can reach the perfect setup for your project, but how many many hours of frustration, searching and reading documentation did it take you to get there?
Where are we at?#
It's clear that the frontend world is getting more and more complex and those people who tell you it's still young and we are still trying to find good solutions to existing problems are ignorant. Two decades is a long time for the dust to settle, but if you keep adding more wind all the time your sight of view will only get shorter. The wind is added by a lot of new frameworks and libraries, the flexibility and shortness of the JavaScript as a language and NPM. It's too easy to publish and consume NPM packages today and everyone is doing it. The flexibility and the possibility is what got us here. I understand that innovation is hard, it's blood, sweat and tears, but what if we have been running in the wrong direction this whole time? The direction of complexity instead of simplicity.
In fact it's so bad that I've heard that some of the developers have developed the green field project anxiety. There are too many choices and they rather take on maintenance projects than make the tough decisions. React fatigue and overall frontend fatigue is real. How do I know that the tech stack I am betting on will still be relevant in two years? SSR or SPA, routing, state management, style libraries. It's easy to end up in the state of analysis paralysis and it's not a nice place to be in.
We also tend to get things backwards. Developers think that in order to get things done you have to use [insert some cool framework name here]. I've witnessed this myself. I have seen code schools teaching newbies without any IT experience how to build apps with React without teaching them the basics of HTML and how the web works. That's crazy, but also sad. It's sad how much money people pay in hope to get a job after they finish the coding course.
It's not the fault of the people who taught the course. It's Economics 101, demand vs supply. If someone can make money out of you they will. React should be the last thing you learn because React is super-complex, but there is a surge for React developers so let's skip the essentials and concentrate on the needs of the market.
Choosing boring technology for the project is boring. I myself is guilty of this too. Luckily I can figure most of the things out because I have a lot of experience under my belt, but it can imagine how frustrating it can be for a newbie. Heck, sometimes even I don't figure stuff out. Not because I can't, but because it's hard and I don't want to invest my time in it, spend my mental energy. To me it's a clear sign of how complex current frontend stack is.
This leads me into the main topic of the article - the dreaded frontend burnout.
The signs of burnout#
This burnout type is sneaky. You don't usually notice it because it doesn't really feel as a burnout, but more like a never-ending mild frustration at first.
It's a slow burnout. It's like drinking coffee from your favorite coffee cup that has a small, but sharp crack in it just at the right place and you scratch your lip every time you take a sip. First it's annoying, but then you get used to it, only to realize months later that you have had enough, and you throw that cup into the wall with anger.
When you reach this moment it's usually too late. That's why you have to pay close attention to the following signs.
Bringing your work home. Not physically, but mentally. If you come home with the constant nagging feeling that you didn't finish what you planned to accomplish today. The feeling of mild frustration.
Yak shaving. If you feel that the only thing you do is fight with the tools and project related things and it leads to a lot of time spent tweaking, solving, dependency management, but no actual coding. Frustration builds up.
Mentally taxing. If you come home mentally drained and the only thing you have energy left to do is to watch Netflix. You have no power to do anything else.
Lost opportunity cost. If you start doubting if building UIs and web sites was the right career choice for you. You ask yourself if things would be different if you programmed an operating system or backend APIs, but you are building interactive UIs and it's just as complex.
Negative feedback loop. If you feel that things are getting worse at work every day and you are not getting anything done.
Work/life balance. If you feel that work bleeds into your private life and work/life boundaries become fuzzy. It can be as simple as thinking about the unfinished ticket in the evening or fail to fall asleep because you are thinking about work. This is especially common if you work remotely.
Performance drop. If you feel tired and lethargic when you come to work and can't get anything done. You have hard time concentrating on the task at hand and procrastinate. Nothing feels exciting anymore.
Framework envy. If you are thinking that things would be easier, more productive or fun if only you used another framework or technology in the project.
Quitting. If you are thinking about switching jobs. This is a common fallacy. People often think it's their current employer that is the problem, but oftentimes it's not.
Denial. If people close to you tell that you have changed lately or you are not present mentally, and you blame it on the tough intense period at work, it's definitely a sign. It's called self-denial.
These are just a few signs that you are nearing the point of no return and it's only a matter of time before the burnout hits you. There are also always physical symptoms associated with those feelings. The most common are: lack of energy, irritation, agitation and sleeping trouble. Pay close attention to your body, not only to your mind.
If you can relate to any of those signs it can mean that you've caught this early and it might not be too late yet. Recognizing and accepting is the first and most important step.
My best advise here would be to take a break and go out for long walks in the nature. They help clear your mind plus you get the physical exercise as a bonus. Also, make sure to book some social events with friends or family even if you feel that you have to force yourself. Next step is have an honest talk with your manager and explain how you feel. It might be hard to do, but you will be glad you did it.
What can we do?#
There are things in my opinion we can do to reverse this trend, and they are exciting too, but it's a topic for another upcoming article.
Tune in into your feelings#
I fully understand, and accept, that the frontend world is turbulent at the moment, and it will be a bumpy ride before we get to somewhat stable state, but please be careful. Watch out for the signals yourself, watch your friends and colleagues. Pay close attention to how you feel and your body. Burnout is never worth it.
Think objectively. Development is fun, but sometimes it can be too fun. Do you really need to use this frontend framework? Do you really need to use SSR? Is SEO a requirement? Remember that complexity increases with every choice you make. It might not be obvious at first when you get everything setup and running, but it will be obvious later when you find yourself in the hole you that have been digging yourself and it's too deep to climb up from.
We, as programmers, often tend to complicate things. It's in our DNA. We like a good challenge, to solve complex problems and we are really good at it too. The problem is that the complexity often steals our time. Time that is better spend building features instead that bring real value to the users.
Next time you are about to start a new project always ask yourself: What is the simplest solution I can get away with?
It's totally fine if you don't agree with me on everything. I just wanted to get it off my chest.