Human Who Codes Newsletter

Human Who Codes Newsletter - Burnout

Published 3 months ago • 6 min read

Thoughts on Burnout

As tech layoffs continue to fill up news sites, I’m reminded of how hard I used to work as a full-time employee at companies who could dispose of me without warning. Not only was I giving my all to my work, but then I was working on open source and books in my spare time. For years, I had very little downtime as I bounced from one task to the next, all the while pushing through burnout and not taking any time to recharge. It’s no surprise that I ended up so sick that I’ve not been able to return to full-time work in nearly ten years. I wish I had better understood burnout and how to deal with it.

The American Psychological Association defines burnout as, “physical, emotional, or mental exhaustion accompanied by decreased motivation, lowered performance, and negative attitudes toward oneself and others.” Burnout is really the result of chronic stress, which can be physical or mental. Software engineers typically don’t realize just how hard we are pushing the most energy-hungry part of our bodies, our brains, until it seems to stop working. And we’re frequently doing it all for a company that will happily replace us the moment our employment is inconvenient.

So what can we do about burnout?

Establish good work-life boundaries. Remember, your company isn’t looking out for your well-being. It’s okay for you to not check emails outside of work hours. It’s okay for you to spend the weekend with your family. It’s okay to go out for dinner with your friends. It’s okay to turn your phone off. Set good boundaries between your work life and the rest of life, and you’ll be happier and healthier (no matter how interesting the work is).

Take regular time off. Different jobs and different countries vary in the amount of time off awarded to each employee. When I worked at jobs that tracked vacation days, I never took any so I would get the cash equivalent when I finally left that job. That’s an approach I regret. In today’s tech world, where many companies “don’t track vacation time,” employees are even less likely to take time off. But taking time off has been shown to recharge us so we can be more productive upon returning. My current approach: at the beginning of the year, I go through and put regular days off on my calendar to remind me not to work.

Take breaks (from work-related thinking). One of the things I didn’t understand until too late was that going from full-time software work to hobby software work was not giving my brain the break it needed from coding. You can think of your brain as having a bunch of different muscles, and just like your actual muscles, they can get fatigued from overuse. Taking a week off to work on your open source project isn’t actually time off for your coding brain. Taking regular breaks (away from the computer) during the day to let your brain rest can actually improve productivity. My favorite break: going for a walk outside (without my phone).

Learn to say “no.” There is always more work to do, and you’ll never be finished. When you start to feel overwhelmed by the number of items on your to-do list, it’s time to say “no” to anything new. You may be thinking, “but how do I say no to my manager?” Politely, of course, which might look like this: “I’d like to help with this, but I already have a lot on my plate. Here are the things I’m currently working on, which of these should I put aside to focus on this new task?”

Never push through. You know the feeling. Your body is dragging, your mind can’t figure out basic arithmetic, but you are so close to getting this thing working! You might not want to hear it, but this is the exact right time to stop, maybe even for the day. That feeling is your body telling you that resources are low. Pushing through that feeling actually triggers the body’s stress response, meaning it thinks you’re in danger and it’s time for fight-or-flight. This only intensifies the feelings of burnout and makes it more difficult to recover.

There is absolutely a way to have a successful career, have a good work-life balance, and avoid burnout. The answer is in finding a balance between all aspects of our lives. Remember, your employer is not concerned about your well-being, that’s something you need to take charge of. My hope is that the tips in this newsletter will help you avoid the health issues I’ve endured over the last decade.

Key Takeaways

  • Your company will take as much as you'll give; your well-being is your responsibility.
  • The best way to deal with burnout is to prevent it by taking time off: short breaks during the day and time off to recharge.
  • Unplugging regularly can help reset your brain: step away from the computer, put down the phone, and get some sunlight.

More about Burnout

📝 How to Take Better Breaks at Work, According to Research by Zhann Lyubykh and Duygu Biricik Gulseren
There is a fair bit of research around how taking breaks improve productivity. This article reviews the latest research (prior to May 2023) to gain insights into what works and what doesn't.

📚 Shorter by Alex Soojung-Kim Pang
Is it possible that working fewer hours actually leads to better outcomes? The surprising answer is yes. This book digs into the research that shows why knowledge workers are more productive when they work fewer than 40 hours a week.

📚 Rest by Alex Soojung-Kim Pang
Explores why breaks and rest are important for our well-being and productivity.

📚 Deep Work by Cal Newport
The best way to get more done is to structure your day so you have blocks of time to go deep into your work without interruption. This book tells you how and explains why it works.

📝 Managing your to-do list as a staff+ engineer. In this free article published on LeadDev, I teach you how to manage the different types of work typical of a staff+ engineer role. Because staff+ engineers tend to be assigned to projects rather than tasks, it's difficult to organize and prioritize this work. I explain a structure for managing your to-do list and explains how to use that structure to better communicate with your manager.

Stuff I've Enjoyed This Month

📚 The Comfort Crisis by Michael Easter
The central thesis of this book is that the human body was made to survive in harsh conditions, and as a result, is ill-suited for today's comforts. The solution? To get back to being uncomfortable to allow our bodies to thrive. This is a fascinating look at how our biology is stuck in the past and how we can hack it to be happier and healthier.

🎬 Get to know GitHub Copilot in VS Code by Visual Studio Code
If you've never used GitHub Copilot in VS Code, then this video is a nice introduction to the different ways you can use it.

🎓 AI Assistants by Kent C. Dodds
This free mini-course explains how to use ChatGPT and GitHub Copilot as a developer. It encompasses code generation as well as other ways to use AI to boost your productivity.

📝 JSR: What we know so far by Sarah Gooding
The folks behind Deno are working on their own JavaScript package registry called JSR. This article explains the vision for JSR and how it differs from npm.

🎬 Build your own copilots with Azure AI Studio by Microsoft Mechanics
This is a good behind-the-scenes look at what it takes to create your own AI chatbots using the Microsoft Azure AI Studio. In about ten minutes, you get an overview of the various parts of an AI service and how to tie them together.

What I'm Working On

🏠 Real Estate: I'm currently tending to end-of-year bookkeeping in preparation for filing my taxes. It's a bad time to discover that numbers aren't quite adding up, so a lot of my time has been spent digging through records and talking with my bookkeeper trying to get everything sorted out. Follow my Instagram for real estate photos.

💻 humanfs: I released several updates to humanfs in the past month, incrementally adding more functionality and cleaning up the code base. It's been refreshing to work on something new without a huge user base as it has allowed me to iterate quickly and try out new things.

💻 ESLint: ESLint v9.0.0-beta.1 has been released! We also released v8.57.0 to backport some of the bug fixes for the new config system into the v8.x line. It's the first time we've done a backport release and it went about as smoothly as it could have.

Human Who Codes Newsletter

Nicholas C. Zakas

A once-per-month newsletter discussing topics important to senior-level software engineers, with a particular focus on frontend technology and leadership.

Read more from Human Who Codes Newsletter

Thoughts on Open Source Takeovers This past month saw one of the most well-planned open source software supply chain attacks in history. A program called xz Utils, which provides lossless data compression for most Linux distributions, was found to have a backdoor that affected sshd. As Ars Technica reported, “Anyone in possession of a predetermined encryption key could stash any code of their choice in an SSH login certificate, upload it, and execute it on the backdoored device.” There are no...

20 days ago • 5 min read

Thoughts on JSR This past month saw the public release of the JavaScript Registry (JSR), a direct competitor to npm. The folks behind JSR are the same folks behind Deno, a direct competitor to Node.js. While it may not be surprising that a Node.js competitor would also create an npm competitor, Deno actually started with a theory that the JavaScript community didn’t need npm or any other package manager. In fact, in Ryan Dahl’s original talk announcing Deno, he explicitly mentioned npm as a...

about 2 months ago • 5 min read

Thoughts on Decision Documents When you start a new project or significant feature, it's likely that you've written a technical specification. Tech specs often lay out the overall design of a system or feature such that it can be implemented by following the spec. Tech specs answer the question, "how?" Knowing how to build something is useful, but there's an equally important question: “why?” That’s where decision documents come in. A decision document outlines the thought process around a...

4 months ago • 4 min read
Share this post