Dealing With Burnout: How I Learned to Stop Worrying and Appreciate Life
And how you can too
There has been a call in recent years for hustle. You hear people talk about it all the time. Some believe you should wake up early and then work until you fall asleep. They claim that is the only true path to success. But is it?
Hustle is a great sound bite, but no one wants to step back and look at the largest pitfall behind that mentality: burnout. Some may have seen this article recently floating around the inter webs and social media. It was not the first of its kind and will likely not be the last. That’s because burnout is cropping up more and more, and we in the software development profession (or hobby) are extremely susceptible to it.
How did we get here?
One of the largest reasons software developers are susceptible is because our field is still relatively young and dominated by those who never stop working. Bill Gates, Steve Jobs, Mark Zuckerberg, and Jeff Bezos all have comic book-like origin stories surrounding their success. Similarities include garages, shoestring budgets, and long days at work. These have become glorified in our industry, and we’re led to believe that to achieve any level of success, we must replicate it. (Interestingly enough, a few of them have also recently shared their thoughts on how much sleep we should get per night.)
But it’s not only the ghosts of developers past that haunt us. The present environment has its own stumbling blocks. It’s hard to open up any type of social media and not see fellow developers discussing work in some capacity. Overall, it can become overwhelming. There is also a tendency to feel some type of imposter syndrome in our field, which can lead to a dual path to burnout; you feel like you have to work overtime just to keep pace or you already feel beaten down by being so far behind.
Neither of which are true.
The fact of the matter is just about anyone can be a successful developer. Sometimes (especially when starting out), it’s just hard to see yourself that way.
Where are we now?
The current attitude toward work also plays into all of this. Unlike other professions, we can take our workload home with us which means we’re never far from the job. Software is fickle and everlasting. There is always another bug to crush, feature to write, or code to refactor. The work can always call out to you, so stepping away from it can prove to be exceedingly difficult.
Where do we go from here?
The first step to fixing a problem, as they say, is realizing you’ve got one. Easier said than done. My experience with burnout is generally full of emotion, mostly stemming from what was discussed before (the fear of falling behind and the drive to be successful). These impulses war with the rational side of my mind which tells me I should take a break. Sometimes, I even listen to that rational side and actually do so. When I don’t, the situation can go downhill quickly. It starts as an inability to concentrate. My mind tells me to switch gears. I really enjoy coding though, so it’s a difficult task. But of course, it’s extremely hard to code well when you can’t concentrate because software development requires a great attention to detail.
The next stop on the Burnout Express is lethargy. At that point, not only can I not concentrate, but I just don’t want to do anything any more. If I don’t address my situation in some form, it can devolve into a mild depression where I convince myself that all of my thoughts, ideas, and code are generally terrible. In truth, my code does suffer when I’m stuck like this, which is unsurprising. It’s not the best mindset for producing quality work. The worst part is that this is such a massive negative feedback loop. It leads people to just want to walk away.
Which, ironically, is what they should have done earlier. One of the best ways to beat burnout is to take a break. Go for a walk, have some tea, meditate, read a book, or talk to a friend or family member. Stepping away to clear my head helps me solve many of the issues I face while working. I’ll sometimes figure out a solution when I’m not thinking about it at all. Even if I don’t, I come back refreshed and more likely to fix what I was struggling with before.
Another solution I’ve found to the burnout problem is structuring my day to plan for small breaks. There are even productivity techniques built around this idea. I know I’m not alone in my tendency to get caught up in work so that hours go by in what feels like minutes. If I felt productive during those hours, then this is a great feeling. If I was struggling with an algorithm, or failing to adjust my UI to exactly what I saw in my head, then it hurts. Going through the second scenario time after time is when I start getting near burnout territory.
Does software development as a whole need to be this way? Of course not! Yes, there will still be times when a developer needs to work late or over the weekend, but that can be the exception and not the expectation.
What’s needed is a semblance of balance.
Focusing our entire lives on work will put us in a dark place. Well-rounded people make well-rounded developers. Having a wide breath of experiences will give a developer a different perspective on the software they are writing. One of the sure-fire ways to create an app that your audience will enjoy is to be a part of that audience yourself. I’m not saying you need a million hobbies, but wouldn’t you write a better cookbook app if you spent time in the kitchen?
As developers, we should stop judging ourselves based on the amount of work we do, but rather on the quality of the work we do and the good we bring to the profession. Instead of fighting imposter syndrome by working eighteen hour days, try mentoring someone interested in development. It’s one of my favorite ways to avoid burnout because I feel like I’m contributing in a positive way to our community. (I like it so much I started a podcast!) Hopefully in the process, you will start comparing yourself to you at the beginning of your development journey instead of developers who have been in the field for decades. This would be the true yardstick.
It’s also beneficial to realize that our job isn’t to finish an entire app in a single day, week, month, or year. Break down the steps needed to produce your app, and then focus on one piece at a time. If you can only get around to working on Step One today, then great! Only move on to Step Two once you’ve completed Step One. It sounds simple, right? Though as a codebase grows, it’s easy to get distracted by all of the features you want to build and bugs that are lingering. Stay on task. There will be times when you want to take the work home with you, do more, and grind grind grind. Move on to Step Two when it’s time to focus on Step Two.
In the end it all comes down to balance. It’s an easy idea to conceptualize but difficult to put into practice. The work will be there for you tomorrow. In the immortal (and possibly over-quoted) words of Ferris Bueller, “life moves pretty fast. If you don’t stop and look around once in a while, you could miss it.”