I am a software engineer who geeks on learning, using a scientific approach to solve problems, and optimizing my performance. Working as a software engineer, I’ve felt burnout and noticed other people feel it. In this article, I will share a few recommendations, supplemented with sources, on how to deal with burnout. What is burnout According to the , the most common symptoms of burnout are: mentalhealthUk Feeling tired or drained most of the time Feeling helpless, trapped, and/or defeated Feeling detached/alone in the world Having a cynical/negative outlook Self-doubt Procrastinating and taking longer to get things done Feeling overwhelmed that around 38% of workers reported feeling burnt out before covid. This number grew to 43% after the pandemic hit. For software engineers, the numbers are even worse. During the pandemic, 54% of software engineers said that they are affected by (21% and 34% accordingly). The top three reasons for that are: high workload (47%), inefficient processes (31%), unclear goals and targets (29%) Statistics show burnout to a great and moderate extent So, burnout is widespread, and it became even more prevalent during covid, which may still hold as some burnout triggers manifest to a greater extent in remote positions. Let’s address this widespread issue, its causes, and how to deal with them. Major Causes of Burnout High workload I personally feel that staying late at work to fix some critical issue or brush up on a feature that you want to complete is pretty fun. But, and a very important “but”, only if it is done at leisure and in a comfortable environment. On the contrary, being in a situation where staying late is a habit or having permanent upcoming deadlines, extra important throw-everything-you-do-now-and-fix-this production bug, or having higher performance expectations that one can achieve is detrimental. So, when I notice that having a high workload is a constant state of my work, I know I need to fix it because I borrow from my resource pool and if it is going to continue for a while, my pool will end up empty. And it is going to punch me back in my face. Hard. This is often an issue that must be addressed with your manager as they can typically solve it, tell you when it can be solved, or explain why it cannot be solved at all - the case when you understand that you have other options open in front of you. Once I was working in a startup that had a tight budget, and last-minute changes, overtime, and a high workload were the norm. When we asked the manager for the strategy to deal with that, he said that it’s the nature of the company to execute it in such a way. We are a startup! It became clear, that if I want to stay sane, I should not linger on the project for too long. My mental stability is much more important to me than continuously meeting deadlines with vague benefits. For the startup, their execution was a sprint, win-or-die situation, because they needed to secure another financing round and were always running out of money. But for me it was a marathon - I needed to think about remaining stable and passionate through my long career. I don’t want to overperform for 6 months and try to deal with the consequences of a serious burnout for another year. I didn’t have to leave them as I got reassigned to another project and the company closed soon anyway, but I knew that I would have eventually left. Typically, a high workload can be solved by: Constraining it to a time period; Putting/hiring more resources; Reducing the performance expectations. Also, I’ve seen behavior that is more typical for Junior Software Engineers - to prove that you are a great developer to superiors by working much more than required. It can come from fear of being fired or from feeling insecure because you produce less code than other more-experienced colleagues. The truth is that it is expected that it will take more time and some guidance to achieve the same result as your senior peers. Be careful of somebody who would utilize your Junior title as an excuse for you to work more. You don’t have to. Inefficient Processes Inefficient processes can be both time-consuming and frustrating. Imagine you have a gatekeeper security manager who is the only one with access to the company’s DNS provider. And to add a new subdomain, which is a fairly frequent process, you need to create a ticket, wait for her for a week to pick it up, and schedule a call. Then after all that she questions all the decisions you make, even though she personally does not know how to configure DNS records. Or imagine you want to change the blur of a background picture by 10%, and do A/B testing, but to do that, you need to submit a formal design change proposal document and get approval from the design committee in the company. Or that you must write a 200-word review to 20 engineers in your department every half a year, even though you work only with two colleagues all the time. Some bad processes are created as a failed experiment, some residues from different company times, some are cargo-cults, and some are improvements of even worse processes. But the key thing is that you can try to change them. It happened to me a lot of times, that I would propose to change how we organize meetings or ask to cancel it altogether or I would explain how terrible or frustrating some process feels and how I see it becoming better. At times I got a decent explanation of why things are like that, at times the processes were changed, at times nothing happened at all and I needed to bear with that. But I, at least, knew that I did all I could. Unclear goals and targets This issue kills even the strongest. I think you’ve seen the folks who have no idea why they develop a piece of software or why they are kept in the office as well. With losing the goal, one loses a sense of meaning. This is why it is so important to align the whole team on the company’s goals and explain why they do the things they do. When I see the whole picture, it inspires me, because now I know what I contribute to and how to do it. This Issue often arises as a result of: poor team communication; sunset of the team absence of a good Product Manager who will find the goal which ultimately leads to the previous point. Often, if there is no clear goal for a team, and the team does not understand why they exist, it leads to the imminent sunset of the team, because, well, it’s a pricey team of developers not put to work. In such situations, I try to reach the management to understand how I can be useful elsewhere. If it is not possible, I know that I need to look for another job. When there is no clear goal, I tend to become cynical. I try to dissociate from the company, I am disinterested in what it wants to accomplish because I cannot contribute to that as I don’t have a goal, and my initiative drops. This is why I find having a clear goal so important. Unmatched values Writing code is a game. It is an entertaining process in itself. But what makes it even more fulfilling is writing code for a project that corresponds to your values. At my first job, I developed websites for Belgium businesses. It was fine and entertaining because everything was new, but I would not say that creating a management system for aquaparks was so fulfilling. And I remember the day I was said that I am going to work on a system that will provide exercises for children with dyslexia. I like teaching, I like games, and I like helping people out. I became so passionate about the idea that I couldn’t sleep well that night because I was thinking about all the cool things I could build. It had never happened to me before. So, even though it is not always easy to find a job where values correspond with the ones an engineer has, I think it is one of the very rarely mentioned but most rewarding things to look out for. To find projects I’m passionate about, I ask the following questions: What are the problems in the world and around me that I deeply care about? How can I contribute to the world to make it a place where I want to be? Which hobbies or topics capture my interest the most? What company would I feel proud about working at? Lack of change Another critical thing for companies to do is change things up a little bit. For a software engineer, there is no one place where all of your learning can be done. New information, tools, techniques, and languages come out all the time. I am writing this at a time when personal coding assistance based on big text models is in the works. For a software engineer, you’re either moving backward, stagnating, or slowly becoming obsolete. Change is important. Another important thing that goes hand-in-hand with change is curiosity. A lot of engineers go into development because they like to tinker and experiment. This is why I believe in the power of in-company rotation to boost the knowledge level and job satisfaction across software engineers. It makes us learn new things, understand other people’s thinking, and explore new tools. This is why I don’t think it is beneficial to be in one company, in one culture, or in one position for more than a couple of years. I believe that it is very fun to engage in different activities in different companies, solve tasks using new technologies, and do new things. Manual work I used to be very pragmatic about what I would automate. If I need to do a process that takes 10 minutes every month, and I would spend half a day automating it, I’d typically not go for automation as the upfront cost is pretty big. However, recently, this approach led me to feel frustrated about the functionality I needed. I needed to change a repetitive and complex JSON structure into a bulk of in-code objects with manual typing and our proprietary templating library. Initially, it seemed it didn’t need to be automated since the process of converting it didn’t involve so many steps, so I spent 2 weeks coping, adapting, and converting the JSON file. At some point, I noticed that every time I think about the task, I wanted to avoid it. I took other tasks meanwhile, I tried to bargain with myself, and I procrastinated as the result (so it actually took me a month to produce the 2 weeks' output). I had approximately half left when I realized, that it makes more sense to spend 3 weeks automating instead of pushing my way through and making me do the work that I hate. And the 3 weeks of coding were fine. Did I use more time just to automate it? Theoretically, yes. But overall, it was a good decision because I don’t think that I would indeed do 2 weeks of work in 2 weeks. After all, I found it to be so daunting. What is more important is that the process was interesting, and I enjoyed it. I did not need to push my way through and suffer. Since then, I try to also add the cost of the damage to my mental state that doing a long manual task incurs so that I can compare it fairly with the cost of automation. Resilience The final aspect to consider is resilience. It allows one to endure and adapt to moderate levels of stress and pressure, recover from them, and return to a state of equilibrium. Inevitably, one will encounter frustrating, confusing, stressful, and challenging situations, whether in software engineering or life in general. Hence, it's crucial to equip oneself with the ability to manage such situations effectively. The most important aspect here is general health. While I’m not going to give any medical advice as I’m not a health professional at all, I feel that the following protocols have changed me to become a much more resilient version of myself: (7-9 hours, regular times of falling asleep, no bright/any light 1 hour before sleep, 15+ minutes of sun exposure early morning, colder temperature when I fall asleep and a little bit higher when I wake up, no coffee after 2 pm, no alcohol 6 hours before sleep); Good sleep (resistance training 3 times per week and 90 minutes of cardio per week) Regular exercise (little amount of sugar/fast carbs, little amount of processed food, a wide range of vitamins, macro, and microelements, 5 grams of Omega-3, 5+ grams of fiber, 8 hours feeding window, vitamin D when there is winter and there is little sun outside) Versatile diet High-quality supportive relationships with people Cold and heat exposure (cold showers or bath for 3-10 minutes, 1-2 times per week, sauna 80-120 °C, 2-3 times per week for 20 minutes) (20 minutes per day) Meditation Psychotherapy Don’t take my word for it, research the topic of well-being yourself, experiment, and find what makes you feel the best. Conclusion Keep an eye out for the following things: Notice early symptoms of burnout like feeling constantly tired, avoiding responsibilities, and a loss of motivation. Don’t stomach a high workload for a long time, talk with your manager to modify your work if possible. Find out inefficient processes that affect your work within a company and do your best to change the,. Strive to get a clear idea of goals for your team and yourself Automate big manual tasks Find a workplace that matches your values Change what you do, learn new, do new things Get your physical and mental health in order This article is a part of the "The Rational Software Engineer" series on Hacker Noon. It covers topics related to optimizing personal processes, education, career development, and being passionate in a software engineering context. Some other titles in this series include: The Rational Software Engineer: A Guide to Work Time Organization The Rational Software Engineer: There is No Perfect Project ] The Rational Software Engineer: How To Be Passionate About Your Work [Part 1 ] The Rational Software Engineer: How To Be Passionate About Your Work [Part 2
