DEV Community

Cover image for I Narrowly Avoided Burnout, What I've Changed and What You Can Learn From It
Simon Barker
Simon Barker

Posted on

I Narrowly Avoided Burnout, What I've Changed and What You Can Learn From It

"How to avoid burn out" must be one of the most Googled work related terms of 2020 and 2021. As we all adjusted to the new world of enforced work from home, economic uncertainty and wide spread heath concerns due to the pandemic people were coming to terms of significant blurring of work and home life.

While some people initially thrived, as the months dragged on it eventually took a toll on all of us, I witnessed many of my friends let work engulf their life to the point where they were signing off WhatsApp messages with "Kind Regards" and suggesting agendas for Saturday Zoom calls with drinks - it would be funny if it weren't so painfully a sign of poor mental health.

I started a new job in October 2020, leaving a wonderful company that was deeply impacted by COVID. I went to a consultancy building a product in arguably the fastest growing area of tech over the past few years. Greenfield project, lots of input on direction and near complete autonomy to implement parts of the system how I wanted in a very small team.

The problem? The business had no idea what they actually wanted us to build and we burned ourselves up in about 8 months flat. Coming out of that experience, thankfully in a new role elsewhere, I can look back and see where I could have done a much better job managing the situation and my mental health.

Clarify expectations

No one knew where their roles and responsibilities started and ended. This meant many product level decisions were pushed down to dev and we spent a lot of time saying no. Saying no is an important skill as a developer but we were making calls on things that really should have been decided at a product level, you can only say no for so long before it wears on your soul and you start saying yes simply to lift your mood a bit. We would oscillate between saying no and then yes and then having to say no again mid feature because we had over committed.

If everyone in the team had a clear understanding of where key decisions should be made we wouldn't have gotten in to this negative feedback loop.

Time box meetings and have an aim

Meetings with no set aim, no idea of what would be needed to make a decision and (as above) no idea who has the final say lead to endless meetings that achieved nothing. Meetings should have a clear purpose, a "what do we want to get out of this time?" to keep it on track and moving toward a conclusion. I would often look at a screen of faces discussing the same feature for the 4th hour that week and be amazed at the amount of wasted time and money having all these people stuck in an endless loop.

Limit your projects

The pressure to learn new technologies is huge, if you are learning masses during your day job working with new things then don't also pile on with extra learning in the evening. If you do want to code for fun in the evening then make sure it really is fun. I have a new rule which is to limit myself to one learning project and one doing project at a time. If work is straightforward because I know the technologies then I will learn something new in my spare time, if work is all new then any coding I do in the evenings should be for fun and low mental effort.

Vary your work types

I got stuck in two modes in that job:

  1. Coding like my life depended on it
  2. Endless calls talking about the product

I should have given myself other ways to work during that time, like listening to documentation with Speechify rather than forcing myself to stare at the screen more. I should have suggested we try more interactive whiteboard sessions for calls rather than just talking endlessly. I should have gone for a walk whilst on morning standup to get some new perspective.

Push back against unreasonable deadlines

We were given a list of features and a deadline that had had no technical input at all. We raised an eye brow at this initially but then just worked to hit it. Product encouraged us to skip writing tests, skip automating repetitive tasks and increase the number of points each sprint to hit the deadline. I used the term "coding for my life" above because that's what it felt like.

We should have stuck to our guns, written tests, automated tasks and gained a real idea of the development velocity instead of simply aiming to deliver features come hell or high water. Development work isn't like manufacturing work, you can't just throw more time, more people and a faster cadence to get more done - things break, tech debt builds and quality suffers.

We should have descoped the project and found a happy medium between getting features out the door and building a reliable and scalable codebase at a sustainable pace.

Pomodoro

I would sometimes work for 5 hours straight without taking a break only to then be basically useless for the rest of the day. Breaking work up in to 50 minutes chunks with 10 minute breaks is a much more sustainable approach to the day and is what I now implement. Mental work doesn't have the same pain and tiredness feedback of physical work and so it's far harder to know when you need a break. On a building site it's far easier to spot someone stagger because they're too tired work more. To make up for that lack of feedback we need to automate our breaks and stick to them.

Turn off notifications

This one is huge, a constant stream of notifications through the day is death by a thousand cuts to your cognitive abilities. If anything is truly important enough your team will find a way to contact you, otherwise those Slack notifications can wait to the top of the hour. Either dedicate some time each day to triage emails and notifications or set a specific point each hour to check in, perhaps just after one of your 10 minute Pomodoro breaks.

Sleep

No matter how engrossed in that feature you are or how much you think scrolling on Instagram or Twitter for 5 more minuets will make you happy, neither will be as good for you as just going to sleep and getting in a solid 7-9 hours on the regular.

Exercise 30-60 minutes a day

Physically tiring yourself out, getting your body moving and releasing the hormones that come from exercise into your body will do wonders for your focus, sleep and overall mental health. It doesn't need to be weights or running, it can be skipping or dancing or kicking a ball against a wall, just something that gets you a bit out of breath and breaks a sweat. If you can break up your work day with exercise even better.

Summary

That project ended in failure, the product was over featured in places that didn't really matter and underserved in actually useful features. 100% of the dev team coincidentally handed their notice in on the same day and so the project was put on pause and the non-dev members repurposed to other projects.

I narrowly avoided burnout, more by luck than judgement but I am at a new place now that clearly promotes sustainable working practices which is much better for my mental health.

Discussion (6)

Collapse
nombrekeff profile image
Keff

Good tips, quite important and often forgotten. For me the last 3 are the most important ones, notifications, sleep and exercice.

Notifications is not usually talked about, but is quite important too. I mute all my channels and take a look at them once or twice a day. My team can also get a hang on me via other channels that I don't mute. But we only use them in case of emergencies.

Collapse
allthecode profile image
Simon Barker Author

Notifications for management is a hard balance (I’ve made an assumption here that your team reports to you, still valid if wrong though). When I managed people I accepted my job was essentially to be interrupted and so didn’t mute anything that could hinder my reports ability to get work done. I think the concept of a manager who also need long blocks of time without interruptions (ie. they are still expected to code) is flawed. As a manager you are there to facilitate and so the trade off for being a available is that coding output will be zero to avoid the burnout scenario

Collapse
nombrekeff profile image
Keff

You've asumed correctly yes, I'm reported my our overall manager. I'm just in charged of managing the technical aspect of both web and mobile front-ends. And I agree and understand everything you said, even though I'm not a manager and don't want to be.

I'm usually not contacted on the daily, though I have ways of doing so for any important things. We usually have 1-2 meetings a week, where we discuss most stuff. Then we comunicate in a async way for the rest of the time (we're mostly all working remote, and with different schedules) either via github or some other channels.

Collapse
now_is_the_time profile image
Now is the time

Thanks for sharing your tips. These periods can be very detrimental and it's nice to see it has a space on this platform

Collapse
nans profile image
Nans Dumortier

What kind of exercise do you practice ? I run, but I can't run everyday, so I'm interested in finding less intense activities 😁

Collapse
allthecode profile image
Simon Barker Author

Mainly weight training and cycling but over the last 10 years I babe been through phases of strength only, body biking, CrossFit and rowing