Developer Burnouts is a chapter from my upcoming book, Web Developer Dot Meta. Subscribe to my mailing list to get more information.
Burning out is an issue that all developers face. And younger developers are often not aware of. To put it simply, a burnout is a state where one is overly fatigued by continued over-exertion. A burnout, left untreated, can result in terrible consequences. Think of it as an Athlete training without a break to let their muscles heal.
This doesn’t stop from managers pushing, however, nor does it stop developers from continuously working away through a burnout.
What is it?
The simple definition can stand on its own but let’s explore the topic further. Where does it come from? How long does it last? Well, every developer has their own amount of resistance to a burnout but everyone is susceptible to it even those that don’t think they do.
There are some symptoms that accompany a burnout:
- continued fatigue. When you start the day the next day, you still feel mentally tired.
- inability to focus on a task. You may be trying to program one thing but you can’t seem to understand exactly what you’re trying to do so you have reread instructions several times.
- inability to do simple tasks. Given an easy programming task, you struggle to accomplish it via normal means and end up making a lot of mistakes.
- physical symptoms such as muscle tension, headaches, itching/burning eyes.
- many tasks you’re presented with feel either a waste of time and dull or extremely overwhelming on the other hand.
- you have a grim outlook on your day.
It can be soul crushing to keep running through a burnout. There are developers that “run on fumes” for years without any kind of reprieve and that can express itself in further health problems, it will kill your happiness, and it will kill your development productivity very quickly to an all-time low.
I’m not being overly dramatic here either. I’ve worked with developers that nearly quit their careers over burnouts that they thought was general unhappiness with the field. After they were able to reach a normal state of being, they realized they loved what they did and had a renewed sense of energy about them.
I know for myself that I often reach the point of a burnout but have learned to curb that situation and I haven’t had a real burnout in a while.
Before I get into remedies and preventions, let’s discuss a cause for burnouts. The cause is in its definition, basically overexerting yourself without taking a break to recharge; however, as simple as it sounds, most of us don’t internalize it. There are still young developers on forums that seem to think they’re invincible. And by young, I mean junior, not age-wise.
Working long hours. Contrary to popular belief, working longer hours does not necessarily get you faster results. In fact, the longer you work, the more likely you are to make mistakes, degrade the quality of your code, and create problems. Even the popular eight hour work day is seemingly not the best approach to work. Sweden recently put seven and even six hour days on trial with much success. However, that may not be an option for you. The important thing is to balance out your day and not work more than your allotted eight unless it’s an emergency.
This means that, no more weekend work, no more “staying after five” or whenever, and no more working late at night at home just to get a project done on a deadline. But if you do need to work longer hours it should happen rarely and not be a habit. On top of that, it should be followed by a time of less stress and responsibility. Meaning that once you launch that long difficult project, take a break.
Taking on too much. Another good point is not to take on too much. It might seem inviting to volunteer for every new project but in the end, it’ll lead to stress. And if it doesn’t lead to working long hours, it will still lead to fatigue. Sometimes, it’s inevitable but over-assignment should be a last resort. Prolonged exposure to high stress will definitely knock you out of the game.
There are other reasons but two those are the top ones. Along with that are less visible and recognizable ones:
- working monotonously with no new projects and no real change in the form of the projects.
- unclear job expectations.
The solution is to never get to the point where you’re starting to think you’ve burnt out. However, you may have already passed that point of no return. It’s fine, we’ve all been there and we will all be there again. Let’s talk about what you can do once you reach that point.
First of all, stop doing what’s putting you in this position. If you’ve been working long hours, cut them back to your regular hours. If you have too many projects, talk to your PM or your manager about clearing your plate. If you can’t, try to push the projects off as much as possible.
Next, try the quick-fix solutions:
- whenever you’re off work, go outside and away from electronics.
- take a few days off to just relax and get away.
- spend a weekend doing this you want to do, no programming.
But that will only keep things from getting worse. What you’ll need to do is start changing the way you work:
- Don’t allow long work hours.
- Speak to your PM or Manager and communicate with them about your workload.
- Switch to a new project if you can.
- Ask for recognition of the work you do.
Honestly, if you encounter severe issues with any of these points, start looking for a new job. You’re worth it.
Lastly, let’s discuss prevention. From the solutions list, you should already have an idea of what you need to do. But just to be organized, I’ll go over it again with some extra tips especially ones concerning lifestyle because work burnout can be caused by outside influences as well. Prevention is probably the most important part of this chapter as prevention should slowly become a part of your life as a developer and internalizing the advice in this section will help you become a better developer. Because what’s better than a developer who can handle stressful situations, can work sustainably at the same level, and rides high on productivity and low on burnout? Not much, and it’s a big step toward become a better dev and moving along in your career path.
There are some main criteria that you should adhere to but make sure to tailor everything to your own specific needs:
- If you have time off, take it throughout the year to replenish your reserves. Vacations are great. Vacations away from electronics are better.
- While working, make sure to take breaks. If you follow the pomodoro technique, work for 20 minutes, and take a 5 minute break for a stretch. Go for a walk during lunch.
- Work only during your hours. That means no working through lunch, no getting extra work in at home at night, and no long hours. If you absolutely have to, make sure to follow with a replenishing activity.
- Switch up projects. Make sure to communicate with your superiors and try to switch up the nature of what you work on every once in a while.
- Outside of work, get a non-computer-related hobby. It’s very tempting to go home and code some more but make sure you have other things to do as well. Most high-profile developers do, from wood burning to writing and composing music.
- When job-hunting, consider the challenge in your future job. Don’t pick a job that’s too dull nor too chaotic.
- Keep an open communications channel with your supervisors about work. They should know if you’re overworked or underworked or if expectations of you are unclear.
- Work out. Seriously. I’ll talk about dev health later on but exercise is the number 1 way to get rid of stress and tension and to reset your mind away from work.
- Whenever you finish a big project, do a small celebration for yourself. Include others in on it if you want, and celebrate your teams’ successes as well. This goes double if your team doesn’t celebrate anything, ever.
- When you encounter a problem you can’t seem to solve, get away from your desk and go for a walk.
It all boils down to communication about your job and taking breaks from the computer. It sounds simple but most developers can’t uphold even 2 of these suggestions in their workplace.
It’s unfortunate for them and they WILL argue with you that working 15 hours a day is great for them and how much they love it but a couple of years down the road they’ll be stringent advocates of 8-hours-only days. If not, just do what works for you and let others do what works for them!