83% of software developers feel burnout from work. Almost overnight, the world made the switch to digital for a multitude of processes in 2020 and the increased workload this created for developers was not considered. At the time computer scientist Junade
Ali designed a
study that revealed the high rate of concern developers have for software reliability in their workplaces. Kathryn Koehler, director of developer productivity at Netflix, commented on the findings and said that “you can’t capture the productivity of a team
in one metric,” and that team wellbeing should be measured alongside productivity metrics.
Burnout, as defined by the
World Health Organization, is an “occupational phenomenon” – “a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed. It is characterized by three dimensions: feelings of energy depletion or exhaustion;
increased mental distance from one’s job, or feelings of negativism or cynicism related to one’s job; and reduced professional efficacy.” It is critical to call out burnout in developers because of the nature of their work – whether it be facilitating remote
work for an entire organisation, or suddenly having to adopt a new technology because a competitor is.
However, as a Code Submit article indicates, there is no quick fix for burnout. “The ability to seek professional help, for example going to therapy, is often limited to those who can afford to
pay out of pocket. […] Taking paid vacation (even though a day or two is rarely enough) or long-term unpaid leave is another luxury that only a very few companies offer their employees. Other solutions, like adjusting your scope of work or negotiating for
remote work, can also come with negative consequences, for example with many new mothers facing career setbacks as a result. These types of tips rarely work to actually improve the situation for a majority of employees. Simply put, ‘getting help’ or ‘taking
time off’ are ‘solutions’ that come with their own set of problems, and for a lot of employees on the brink of burning out, they aren't solutions at all.”
I spoke to Samuel Burri, VP of engineering, DFINITY Foundation; Bob Bodily, founder of Bioniq; and Joshua Mills, talent manager, Dariel Software about how developer burnout occurs, what happens when bureaucracies build, technical debt grows and processes
become inefficient, and the risks of forging ahead with a culture where psychological safety is essential to addressing issues of software reliability.
How does developer burnout occur?
In Burri’s view, while “burnout can occur in many different sectors and industries, especially when it comes to such dedicated and enthusiastic people as software developers and engineers […] [they] are the backbone of this sprawling digital revolution,
so they are often faced with nigh-on-impossible challenges and expectations of stellar results on very aggressive schedules.” He goes on to say that this could lead to burnout due to:
- a mismatch of expectations,
- a lack of clarity, focus, and empowerment,
- high levels of stress due to sheer pressure and emotions,
- feelings of being overwhelmed by tasks and requests, and more.
Burri added that when critical issues are discovered in software post go live date, it becomes the software developers or engineers’ responsibility to fix the issue, and being inundated with calls,
bug reports, and alerts would make them feel powerless and would massively contribute to burnout. This aligns with Bodily’s sentiment, as he shares that problems arise when developers “don’t feel like they are part of something bigger, when there is no
cause to rally around, when there is no urgency, when what you are doing doesn’t matter that much, when you are a meaningless cog in a machine, I think it is extremely easy to get burned out. The opposite, then, is also true.
Giving developers purpose, a higher calling, a sense of the bigger company vision, and a chance to see they are making a difference are all ways to counteract developer burnout.”
What happens when bureaucracies build, technical debt grows and processes become inefficient?
Giving developers purpose is easier said than done. Uncertain times lead to processes being completed in quite short order and could lead to unnecessary work. Mills says that this “results in more time spent working, instead of time spent resting and recuperating
for the following day. Also, with the increase in
technical debt, this may lead to changing timelines and increased pressure to deliver, which can heighten the stress levels of the developer.”
Technical debt, according to Burri, is one of the most pressing issues in the IT sector today. “Poorly audited bits of code, sometimes even dating back many years, could severely hinder software development, forcing engineers to context switch and waste
precious time on solving problems that shouldn’t even be there, not to mention losing focus on their ongoing tasks.” He adds that technical debt is more dangerous in the financial services industry because business involves large amounts of funds. Burri states
that “when a big video game, for example, contains pieces of bad code, this usually results in poor performance due to a lack of optimisation or various bugs. But when a platform has millions or even billions of dollars in total value locked and has an exploitable
vulnerability in its code, this could not only lead to inconveniences for users but to massive financial losses as well.”
Vulnerabilities within architecture are harder to spot when developers are overworked, stressed, and burnt out. Further, when
quality dips, the impact of a flawed product is hard to predict. Burri advises that “technical debt should never be downplayed, and companies should strive to nurture a culture that incentivises a comprehensive approach where a certain share of resources is
always reserved to tackle this issue. At the same time, developers’ schedules should also be as reasonable as possible instead of forcing people to cut corners to meet their deadlines.”
To avoid burnout, developers and other employees need to be looked after and their work-life balance must be considered. By fostering a
diverse and inclusive culture that incentivises collaboration, mutual assistance, and acceptance of new ideas, problems can be solved in unison rather than a lone developer.
What are the risks of forging ahead with a culture where psychological safety is essential to addressing issues of software reliability?
What would be the ideal scenario for a developer? According to Mills, “developers ultimately want to build something that works, something that will work independently after they have finished and have minimal work needing to be done afterwards. If developers
have to constantly be on standby and resolving issues, especially after hours, it can feel draining for the developer.” Where does psychological come in? Mills says that “while it may give a sense of comfort, it may be a restricting factor for business. As
they may not take the necessary risks needed and stick to the same old software ideas. Thereafter leading to poor software reliability and thus the knock-on effect of burnout for developers.”
If software is not reliable, this could exacerbate burnout. How can the industry resolve this? Mills adds that for him, “it comes down to collaboration and clear communication between all parties. If each team can operate optimally not only in their own
capacity but together as well, it will go a long way to being more effective in achieving business outcomes. Burnout is prevalent in all job types and developers are sadly not immune. I think what is important is for companies to be aware of the possibilities
of burnout and keep a close eye on staff to ensure that they do not reach that point. Companies need to keep their finger on the pulse because once employees start showing signs of burnout, it may already be too late.”