What is developer burnout and how to avoid it with James Q Quick

Developer burnout is real; it’s not just you! Or a couple of loud, disillusioned developers on Twitter proclaiming they are fed up with tech and dream of quitting everything and starting a farm. According to data from a StackOverflow survey, 2 in 5 tech workers show a high risk of burnout.

We spoke to James Q Quick about what developer burnout actually means, how it does not necessarily correlate with long working hours and what can companies and individual developers do to prevent burnout.

James considers himself to be a JavaScript developer, a speaker, and a teacher and has done some combination of that professionally for 12 years. He also says he is a firm believer in work-life balance, the ongoing pursuit of personal happiness, and empowering others to take control of their career. After being a software developer and a developer advocate at several big companies, James is now a full-time content creator, impacting developer communities all over the world by creating YouTube videos and speaking at conferences. You can catch him at Infobip’s Shift conference in Zadar, where he will speak on the inevitable topic of AI and its impact on developer experience.

Although working long hours is just one of the causes of burnout, as a believer in work-life balance, James says having a work schedule that leaves time for other joys in life is a must:

Working long hours

It’s really sad that a lot of companies have expectations of people working more and specifically in the context of how it is in America. The typical work week is ideally 40 hours a week but at a lot of companies, people are expected to work nights and weekends and they’re not compensated for that, it’s just looked at by their management as the requirement of the job.

That just makes me really sad. Work-life balance and working a limited number of work hours are really important. I enjoy my work, but I do so many things outside of work that I enjoy and it’s not healthy to have to sacrifice all the other things in life that I enjoy for work.

Working on non-exciting or unchallenging projects

You could be working a healthy amount of hours but still feel burned out. It happens when you work on projects that are not particularly exciting or challenging to you and do so for a longer period of time. What developers enjoy in their work is solving fun and challenging projects, and when you don’t do that, it can result in burnout manifested in a lack of motivation.

I have experienced this, but with content creation. When I start recording a video and realize I am not that excited about it, it’s so much harder for me to do it. I push it off, then things start to build up, and it becomes harder and harder. That’s one of the biggest indicators for me of potentially getting burned out, the stress of working on something I’m not 100% excited about, it takes a lot out of me.

If you find yourself in a similar situation as a developer, you can think of what you have in control and try to change it. You could either find another team or find another project or a different aspect of the project to do something new. If you typically do the front end and you’re looking for a challenge, you can try the back end or mobile or just something to kind of branch out a little bit and break up the monotony of the day. It’s really easy, especially at bigger companies, to work on one particular thing with one particular skill set and never really be challenged beyond.

Sometimes we just have to be intentional about actively looking for and pursuing either different aspects of what we’re doing or just something new to work on completely.

Why are developers so burned out?

I don’t have any research to support this but I think that the developer audience is just very loud and outspoken. Other industries probably suffer a similar amount of burnout potentially, but it’s just not as vocalized and addressed as much in other industries as it is in the developer communities.

The effect of estimates and arbitrary deadlines

It’s really easy for management to look at software as something that should have a finite timeline. When you’re not a developer and you ask a team to build something, and they say they think they’ll have it done by Friday, it’s really hard for someone who’s not a developer to understand why that may not happen.

That is one of my biggest pet peeves as a professional. Developers are held accountable for these arbitrary estimates as if it’s a do-or-die situation. And it’s really just never that serious.

Sometimes, things take longer. Ideally, they don’t, and ideally, we have a really good sense of how much work we can produce with X number of people hours, but it’s just not perfect. So often, developers are asked to work nights and weekends, and that’s because people have arbitrary deadlines in mind that they think are the most important thing, more important than the mental and physical health of the developer building the thing.

Being on-call

The other challenge is the idea of being on call. Yes, your company is probably losing money while that thing is broken, whatever it is, whether it’s physical or software, so you certainly want to have people who are available at any given time to be able to solve that problem. But that also then becomes this really big challenge, and I’ve done on-call rotations in my career, none of which were “that bad”. I didn’t get many calls, but if I got a call, it was in the middle of the night, which is a challenge because that means you’re never sleeping very well because you’re always a little bit on the edge if the phone rings that you have to be available to wake up.

But I’ve heard so many horror stories of people in worse situations where they were on call and they were getting called three, four, five times a week in the middle of the night and think about how disruptive that is for mental and physical health.

Depending on the company and the culture, sometimes they would not be compensated for that, not necessarily with dollars but with just the expectation that they don’t need to work the next day or they work half a day the next day. I’m extremely dependent upon getting a normal amount of sleep or I’m just not nearly as productive. Being disrupted by on-call can serve as a significant challenge for developer teams.

How to fix developer burnout

We should be talking about it, and we should be talking about it from a productivity standpoint of how do we get better and solve this thing. The first thing is to be accountable to yourself.

If you feel like you’re burned out, first of all, have a conversation with yourself and ask yourself – Am I as happy as I was a month ago or two months ago, do I enjoy what I’m doing, do I really enjoy the people that I’m working with.

If that answer changes, that’s a kind of a red flag. It’s at least something to sit and think about and ponder ways to potentially improve.

But I think that there should also be a transparent conversation with management as well, and this also varies with good and or bad management. A good manager or management should be receptive to the fact that you’re burnt out, they should be willing to listen to the reasons why and then consider and discuss opportunities to help fix that.

If, for example, you’re essentially burnt out because you only do front end and you’ve done as much as you want to and you want to learn something new and get a new challenge, that’s the conversation that you should be able to have with the manager.

That’s the first level of conversation with management, and again, this goes multiple different ways, depending on if you have good management that’s receptive to that and willing to work for you or if you have bad management who tells you this is the way it is and there’s no way around it.

Sometimes, you can’t just fix things overnight, but if you’re not working towards making changes and you feel like people around you, specifically management, aren’t working towards that may be the reason to go look for a different team or a different company that has a different culture.

Also, when you’re looking for a job, the ownership is on you to do your research as best as you can going into a job. To ask if you have on-call rotations, how often people are on call, how often people get called, or if you’re a junior, what sort of support system will you have, will you have a direct mentor, will you have a direct line of communication to one or multiple people that you can ask questions to and get feedback from.

Communicate to management

I see a lot of people complaining about stuff that they’ve never had a formal conversation with management to see if they’d give them the opportunity to make changes. A lot of people just think negatively about their job, but it is what it is, and they kind of accept it. You have to be able to communicate your concerns to the management. If they’re not receptive, then it’s somewhere for you to start considering other opportunities, but ideally, you’re in a situation where people are receptive, and maybe there are some small changes you can make to start getting a little bit more excitement and/or balance in what you’re doing on a day to day basis.

Be a part of the developer community

At a higher level, my biggest recommendation for developers is to just get involved in the community. It can be just going to a local meet-up or a virtual meet-up, joining a Slack community or a Discord community, or going to conferences and even speaking at some. Being involved in the community is an absolute game changer, from increasing your skill set as a developer to broadening your awareness of the industry and exposure to the industry to networking opportunities.