February 10, 2020

Burnout

by Brian Donahue

On Tuesday night, I spoke at the Software as Craft Philadelphia meetup as part of their “2019 Reflection” lightning talk series. Initially, I wasn’t sure what I’d talk about, but as I found myself struggling to finish a blog post on my recent struggles with burnout, I thought it would be a good topic, and help to refine my thoughts. I also wanted to force myself out of isolation a bit as I haven’t done any public speaking in quite a while. Perhaps it would resonate with someone dealing with similar feelings, or help others to avoid it themselves.

It was not the most comfortable thing I’ve ever done – standing up and talking about personal struggles in front of 30-40 people, most of whom I had never met. But in the end I felt good about it, and I got some encouragement and even some sincere thanks from some attendees who related to my story. It did indeed help me clarify and organize my thoughts, and I thought I’d share them here, in blog form.

• What Is Burnout?
• What Does It Feel Like?
• How Does It Happen?
• How Do We Recover From Burnout?
• How Do We Prevent It?

What Is Burnout?

The first question you may ask (truthfully, I kept asking myself this, even as I was in the midst of it) is: Is burnout really a thing?

As software developers, we have a lot going for us. Job opportunities are abundant – experienced developers are more likely to complain about being harassed by recruiters than about struggling to find employment. We are typically paid pretty well. Many jobs offer very nice perks like remote work, or a nice office with all sorts of amenities and benefits, as well as flexible work hours. What do we really have to complain about?

It’s easy to dismiss burnout as a another “first world problem,” but a quick google search will unearth story upon story of people of all ages struggling with burnout in our industry. I certainly don’t think it’s exclusive to software, and likely not statistically more prevalent than in many other industries, but it certainly is not uncommon.

What Does It Feel Like?

As with anything related to mental health, burnout can affect each person differently. I can only share my experience, but I did find many commonalities with other stories of burnout I read from various sources, and I think the general feelings, if not the specifics, will be familiar to anyone. For me, burnout manifested in several ways.

Lack of Motivation

When I am engaged in a project, time melts away and I often have to force myself to break away for lunch, meetings, or to go home at the end of the day. You’ve likely heard this referred to as “being in flow.” When feeling burnt out, it is the exact opposite. I can not force myself to focus on the task at hand. And I’m not talking about periodic distraction or procrastination that we all sometimes engage in – this lingers for days on end. It’s like my brain is actively working against me, pushing back against my attempts to move forward. I find myself rethinking what I’m doing, deciding I better do some more research, read an article, or just take a break to re-energize. But when I return, I have the same feeling. Sometimes I’ll do a small, lower priority task just to feel like I got something done – but I know I’m putting off more important things. I’ll start to feel bad about myself, and put more pressure on myself to get more done in shorter amounts of time, which backfires and results in a vicious cycle of minimal productivity.

Loss of Confidence

Of course, feeling stuck and unproductive starts to eat away at your confidence. You start to wonder if maybe you just aren’t that good at what you do. It’s easy to forget past successes when you are staring at a task you know you should be done by now but somehow have not been able to move forward on. Maybe your skills have eroded? Maybe you’ll never feel up to coding again and you are in the wrong career! I tend to be very hard on myself, and my thoughts would get pretty erratic and negative the longer I felt stuck.

Feeling Trapped

Pretty soon you are starting to feel completely trapped. Is it this particular task/role/company? Would changing any of those make it any different, or is it just me? If it is just me, what can I do? Change careers? Every solution to the above questions seem overwhelming, does not have a clear answer, and feels like you are admitting defeat. This is where I'd often crawl further into my shell and just hope that I might be able to force my way through this.

How Does This Happen?

There are many things that can contribute to burnout, but some research suggests that it is the most engaged employees that are at greatest risk of burnout. These are the employees that really take pride in their work, and want to be at their best. It makes sense that they are also hardest on themselves when things aren’t going well.

I would not presume that what contributed to my feelings of burnout are the same things that will contribute to yours, but there is likely overlap. For me, this was a long build over years of growing frustration at various jobs, culminating in my leaving my longest tenured role only to find myself optimistically jumping into new roles that were not good fits for me. There were many contributing factors, and I’ve tried to summarize them into categories.

Lack of Agency

Art by @Artvader_AF

For me to feel engaged and challenged in my work, I need to feel invested in the problem I’m solving, and feel that I am able to use my critical thinking and creativity to figure out a good solution. If I feel rushed to make design decisions without being given time to understand the problem and consider options, or worse, if I make suggestions or raise concerns and they are ignored or rejected without consideration, I am going to get frustrated pretty quickly. I enjoy productive debate with other developers, and always can learn from other perspectives, and think it’s an important part of the job and the way we come up with our best solutions. If we don’t feel comfortable sharing our ideas and concerns in our workplace, there is likely a problem.

Isolation

Remote work is growing in popularity, and the software industry may be at the forefront. I am a big fan – I hate commuting. But working remotely does not come without risks, and a remote culture needs to be carefully designed and cultivated. If not, it can be easy to go days without speaking to anyone directly, and to feel very isolated.

You don’t have to work remotely to feel isolated, either – you can feel isolated in an office full of people. The culture of the company or team is key. Interaction and collaboration need to be encouraged and prioritized, at least that’s how I prefer to work. There are so many advantages - from simple camaraderie, to knowledge sharing, to brainstorming for better ideas. Yet many companies prefer to “divide and conquer” tasks by giving each developer completely separate tasks, often discouraging “interruptions” to discuss your tasks with coworkers. This can be compounded by having an architect or or team lead that is also assigned tasks, as well as other responsibilities, and therefore does not have time to collaborate with the team.

This is one of the biggest struggles I faced over the past couple years. I believe so strongly in collaboration, that I think some amount of regular scheduled collaboration - pair or mob programming would be my ideal - is hugely important. By limiting the number of concurrent tasks a team commits to, we can collaborate more and come up with better solutions and a better overall understanding of the team’s goals and the code base itself.

Unclear Targets

Software development is a creative, evolutionary process. We start out with an idea to solve a problem but often the idea, and many times the problem itself, can change as we design, build, and test our software. Good software teams embrace this, and design small experiments to validate assumptions as they go. They are ready to adjust if their experiments show them a better way. Many software teams do not allow time for this sort of analysis. Experimentation and validation are seen as wasteful, and the only goal is to ship code that completes the original “requirements” given to the team.

Requirements are typically vague and include a lot of unvalidated assumptions. As a result, developers often struggle to know when they are “done.” Features have unclear boundaries, and typically only considered the simple or “happy” path, and not all the things that may go wrong, or supporting requirements (e.g. a “log in” feature typically requires the ability to “log out” and for new users to register). We often don’t consider the “invisible” work a feature requires, such as testing, monitoring, performance, traceability/logging and reporting on usage.

Many teams are not incentivized to do this level of due diligence as they build software, so they delay or ignore it entirely. Vague discussions around “tech debt” may be had, but in practice, it is typically not addressed until something goes wrong in production.

For an experienced developer, the blind pursuit of feature delivery, ignoring due diligence, will wear on your confidence in the product. We know a reckoning is coming, we see the shortcuts being taken. We may raise our concerns, and be politely deferred or even flat-out shot down due to (often arbitrary) deadlines and delivery promises.

Hero Coder / Bus Factor

Along with isolation and "divide and conquer" strategies can come the pressure of being the "hero coder" or perhaps simply the only developer who knows a particular part of the application. This is commonly referred to as a "bus factor" of 1, meaning if you get hit by a bus, no one else can take over your work. Of course this is a bad strategy for a company, but it also puts a great deal of pressure on you, as the developer. Whenever something goes wrong, you have to shift your attention and put out fires. Taking time off becomes trickier because you are going to get called for any issues that are in your silo. Constant firefighting and being the point person for all issues takes its toll, and this is exacerbated when management will not prioritize fixing recurring issues – because as long as you are able to get things working again in the short term, they would rather ship new features.

How Do We Recover From Burnout?

As for most of these questions, the answers vary for each individual. Of course, if you are struggling and feel you need help, you should not hesitate to reach out to a doctor or therapist. There are online options these days such as Better Help (not an endorsement, I have not used them) so that you needn’t even leave your house.

That said, there are several things I found helpful in working through and dealing with feelings of burnout that may be helpful for others as well. Later, I’ll discuss some of the things I plan to do when considering future projects to try to ensure I don’t allow myself to feel burnt out again.

Admit It’s Happening

This seems obvious, but for me it was one of the bigger challenges. When things weren’t going well, I tended to beat myself up. Even when dealing with people I knew were being difficult, I was often harder on myself for not being able to appease them rather than considering if I was being treated fairly and/or their expectations were fair. It can be a hard situation to navigate when you are new on a team, and you don’t want to make waves. Your team accepting that “this is the way it’s always been done” does not make it okay. This is especially true if you see people being mistreated. Being told, “oh, that’s just [so-and-so], she can be really short with people” doesn’t mean you have to accept this culture. Similarly, just because your new team is okay with recurring bugs and messy code, doesn’t mean you should lower your standards and do sub-par work.

In these cases, you should of course try to constructively address the situation. Depending on your authority on your team, and the willingness of leadership to listen to other opinions, you may or may not be in a position to do much about it. If you find your ideas are regularly ignored or summarily dismissed, most likely it’s time to move on.

Self Care

When you are in the midst of burnout, it's basically a form of depression. You may be able to shrug it off a bit outside of work, but every time you return to your desk it sets in again. Once you've recognized it, you should do what you can to take care of yourself. You will not make your best decisions in this state of mind, so it's best to find ways to get some distance from it. It should go without saying that you need to make sure you are getting enough sleep and exercise, and eating healthily. If you aren't – start there! But here are some other things that might also help:

Be mindful. Mindfulness is a big buzz word these days, and I'm not saying you have to get in the lotus position and meditate. Personally, I do find meditating helpful, and I try to meditate at least 10 minutes a day. But apart from meditation, when you are feeling stressed or down, it can be helpful to just stop and be present. Take some deep breaths and just observe how you are feeling. What thoughts are playing in your head? Are they helpful? Can you identify unhelpful thought patterns? There are many resources for learning to be more mindful and aware, and these tools can help prevent you from lingering too long in a negative mindset.

Go outside! You should be doing this anyway! But, it’s important to break yourself out of negative thought cycles if you are struggling. Don’t bring your phone, get out of the office, and take a 15 minute walk, or longer if you can. I’ve taken half or full days off to just go walk in a park for a few hours and think, and as long as the weather cooperates, you can’t help but feel better.

Do some writing. Writing can be very helpful, and it almost doesn’t matter what type of writing you do. Write your thoughts unfiltered into a journal or text file. Delete it when you’re done if you like. Write – but don’t send immediately! – a note to a person you are feeling conflict with. Unless you really think it’s constructive, you can delete that too. Write a blog post!

Putting our thoughts into words can help us organize and analyze them. You might come up with something worth keeping or sharing, but you will always learn something. If you make a habit of it, it will help you understand where your feelings are coming from and help you think through ways to change your situation.

Reconnect. Isolation is a common theme in burnout. It’s important to take time to connect with people outside your work, such as old friends or old coworkers with whom you enjoyed working. These friends will often help by providing perspective, empathy, and perhaps suggestions for how to deal with difficult situations. Equally important, they may help validate your feelings if you’ve been second-guessing yourself, and help encourage you to take the steps necessary to address it, even if that is moving on.

How Do We Prevent It?

Alright, so we’ve discussed what burnout is, how it feels, and how we can deal with it. But what about avoiding it altogether? Of course this is the ideal. There are two critical times in our careers where the actions we take can make a huge difference on whether or not we find ourself in a bad situation.

When You Begin To Struggle At Work

This may be the most important time to be mindful of how things are going and get ahead of problems before they fester. This of course depends on the culture at your employer. But the first thing to do is to talk to your manager. Some questions to consider:

• Clarify expectations. If you are feeling overwhelmed or confused about your responsibilities, talk to your manager about what is expected and what you feel is realistic. It may be that you are taking on more than you need to, and perhaps the conversation will lead to your manager helping to reduce or distribute your workload.
• Break down large tasks. Sometimes a task is too large or too vague to be easily understood, and you may not know where to start, or when it will be considered done. Ask your manager, project manager, or stakeholders to help you break down the task into more manageable chunks, and discuss order and priorities.
• Be honest about your challenges. Maybe you are struggling with a particular implementation, framework, or technology. If you have made an effort but still don’t feel confident in your understanding, do not hesitate to speak up. A supportive team will help each other to improve and share the responsibility of learning.

The key here is not to allow yourself to remain stagnant and/or alone. This can be especially challenging on remote teams, as communicating can take extra effort, and can feel like you are interrupting a coworker’s day. Be respectful, email ahead to request some time, but do reach out when you need some help or answers.

When You Are Ready to Move On

Another important way to avoid getting into a bad situation is do your due diligence when evaluating new opportunities. When I am evaluating and interviewing with companies, I tend to get excited by their specific challenges. I like solving problems and building software, and I will ask lots of questions about the business domain, the existing architecture, and their goals for the product. These are important questions, to be sure, but fixating on technical challenges can lead to glossing over something that is likely much more important: the culture. I think that part of the reason some of my recent engagements did not work out as well as I'd hoped is because I did not do enough to learn about the culture of the company I was joining and only figured out after joining that there were aspects that would never be a good fit for me. There are many resources with suggestions for questions to ask potential employers, but there are several things I would want to focus on in my interviews to get a better sense of the culture of the team and company.

• Continuous Improvement: I would ask individual developers how they keep up with their craft. This is something I always ask if I am interviewing someone, and I think it’s important to ask when you are the one being interviewed. The effort and resources that individual developers put into improving their knowledge and skills says a lot about their commitment to improving. I would also ask if the team does anything collectively to share knowledge or learn new things, and if leadership at the company encourages this or is ambivalent (or even discourages).
• What are the team’s strengths? How did they get good at those things? This should go beyond purely technical, such as languages/frameworks: you might ask about their continuous integration and delivery practices, automated testing practices, project/task estimation or planning…
• What are the team’s weaknesses? How does this affect them, and do they have a plan to improve in these areas?
• Crisis Management: I would ask software teams to tell me about a recent crisis (or, if they are unable/uncomfortable identifying a “crisis”, ask about a big challenge, or difficult deadline) that they endured. I would ask what made it difficult, how the team responded, and what went well and what didn’t go well. The goal here is to try to get a sense of how the team responds in stressful times, whether they band together, “divide and conquer,” or perhaps point fingers at others / each other.
• Ask About the Code! In the midst of dealing with some particularly brittle and hard-to-parse code at a recent engagement, I promised myself I would never take another job without first asking for a tour through their code base. In reality, this will not always be possible, but I think you should certainly ask some pointed questions about the code base you will be working with, or if a greenfield project, ask about other projects the team has worked on. Some questions I would ask developers I met with:
  • What is your favorite part of the application to work on? What contribution are you most proud of? Why?
  • What is your least favorite part of the application to work on? What areas do you wish you could clean up or rewrite? Why?
  • Is there an area of the code base that produces more bugs / support tickets than others? Why?
  • How do they feel about their test coverage? Is it a priority? A requirement before shipping? How much is enough? How easy do they find it to write tests for new features, or add tests when bugs happen?

Moving Forward

Looking back, I can see how my feelings of burnout were really a slow burn building over several years. When it got bad, I tried to fix it by jumping into some different opportunities, but I never really took the time to think about what I was specifically looking for. It took some time off between jobs to regain my perspective, and remember the things that I love about being a software developer. I by no means feel like I’ve figured it all out – I am still wary that I might repeat past mistakes, as I look for new opportunities. But I certainly feel like I have a better understanding of what I’ve gone through and what to look for.

If you have a story to share, please feel free to comment below or contact me directly via my contact form. I am happy to help in any way I can. In the meantime, I hope to write some more (shorter, more software-focused) posts in the near future, and hope to see you here again!