Well BeingCan deep work solve the problem of developer burnout? 

Madelene Bernard · 2022-02-25
Developer Working

Developers and Deep Work

Cal Newport defined deep work as the practice of working on a single, often cognitively demanding task for an extended period of time, without distractions to facilitate productivity. For software developers, deep work is the time that they spend on writing or improving code. Writing code is the process of developing a solution to the problem or task at hand. Creative thinking, iterative solution-development, and execution are all integral parts of the software development process. In order to successfully execute their solution, developers must spend large portions of their time, fully dedicated to writing and improving code. Such deep work is facilitated by preserving the maker’s schedule, wherein a developer is able to dedicate many uninterrupted hours to a core task, essentially getting into a state of flow and performing at peak productivity.

What causes developer burnout

The WHO defined burnout as chronic workplace stress that has not been successfully managed. Burnout has several expressions, often displayed as a lack of motivation, extreme exhaustion, anxiety, irritability, or professional inefficacy.  

Developer burnout usually manifests as loss in productivity, missed deadlines, and lack of motivation. There has been an alarming increase in instances of developer burnout, with a software developer burnout survey showing that 80% of respondents experienced burnout symptoms. Here are some potential causes of burnout in developers:   

Context switching

One of the biggest detractions to deep work is context switching. Context switching “is the process of stopping work in one project and picking it back up after performing a different task on a different project”, as explained by Todd Waits on the Carnegie Mellon Software Engineering Institute blog. Context switching is a deterrent to deep work because studies have shown that people struggle to transition between tasks, often requiring about 25 minutes to resume their previous task and thus risking under-performance in subsequent tasks.

A software engineer’s role has multiple demands. Although writing and improving code is the engineer’s primary focus, engineers also have to attend to tasks such as code maintenance, testing, and debugging. The evolving distributed and remote workplace also adds meetings and sync collaborations to this list. A study showed that respondents spent less than one-third of their time writing new code or improving existing code while the rest of their time was spent attending to other work tasks that often interfered with focus time and deep work slots. 

Meetings & zoom fatigue 

As the workplace evolves to become more distributed, hybrid, and remote, engineers have had to manage the growing practice of sync meetings and meeting overload. In fact, a study among 300 software engineers showed that the respondents spent 23% of their time in meetings and on management and operational tasks. When meetings are fit in during the work day, it can lead to increased context switching. When they’re fit in post work hours, it  can add to workplace stress. Combined with other impacts of virtual meetings such as lack of mobility, cognitive exhaustion, and psychological stress of virtual conferencing, meeting overload can lead to zoom fatigue and burnout. 

Always on 

The new normal of work has most employees “always-on” and digitally plugged-in, without any real distinction between work and personal life. Research shows that remote workers are working 15 hours longer than co-located employees, and this increased workload has led to increasing stress levels, worsening sleep habits, and declining employee productivity.   

For software engineers, the tendency to always stay plugged in to work is fed by the very nature of their work. Most developer schedules involve doing code reviews in post-work hours in order to preserve work hours for writing their own code. At other times, developers handle incident alerts that can arise even throughout the weekends, when there is no other option but to fix outages. When such critical incidents occur, almost all incidents involve the need to rope in fellow team members who might be off work. 

Burnout, loss of productivity, and the cycle goes on…

Context switching can be detrimental to productivity. Not only do engineers have to constantly jump between code reviews, writing new code, or fixing outages, they have to context switch in and out of meetings, operational tasks, happy hours, and other workplace demands. The cognitive exhaustion brought on by such context switching can cause disengagement in the workplace, stress, and dips in productivity. 

Such loss of productivity and disengagement can result in slower deliveries or lower quality code. Low quality code results in more outages. Slow deliveries result in poor team outcomes. This cascade of negative outcomes becomes a vicious cycle that inevitably leads to dissatisfaction  amongst developers, eventually resulting in burnout. 

Can deep work reduce burnout? 

The answer is a resounding yes!

Developer burnout that stems from practices such as context switching, meeting overload, and the always on culture can be prevented and overcome using focussed deep work.  

Allocating time blocks to work on a single, important task will allow developers to train their focus to get into glow and work effectively in solving the task at hand. Repetitive training of focus time practice and successfully completing at least one critical task at a time cna lead to tremendous improvement in developer satisfaction and engagement. 

Preserving the maker’s schedule by allocating slots for deep work can keep competing distractions at bay, allowing developers to stay in the state of flow which increases creativity and efficiency. The practice can eventually reduce context switching, thereby eliminating a primary cause of burnout.

Deep work slots naturally lead to a calendar that has defined time slots for meetings and other commitments. Scheduling meetings at a time that developers find convenient can improve the quality of a developer’s day. More importantly, when teams adopt async work practices, meeting overload will significantly diminish which can eliminate the possibility of virtual meeting fatigue. 

Deep work inherently involves taking scheduled breaks after the focus time slots. Such breaks are critical to ensuring a better state of mind for the workforce. With async work, reduced context switching, defined time allocation, deep work can impactfully combat the culture of staying always-on. 

How can dev teams solve the problem?

Adopt async standups

Stand up meetings are daily, strategic meetings that dev teams hold in order to take stock of work in progress, work planned, and potential blockers. These meetings are held at one given time in a day and often involve engineers, managers and leaders switching contexts to attend the stand up. The stand up meeting is evolving alongside the future of work to accommodate distributed, global teams that work on different time zones and different time schedules. This has given rise to the async stand up. Asynchronous standups have the added benefit of not cutting into focus time, thereby supporting deep work.

Async check-ins using Hatica Check-ins

Async work

In software development, collaboration is key in the process of code reviews. Although code review is a highly collaborative team process, it can thrive within the async framework. Developers can collaborate on PRs using comments as much as possible to avoid pinging team mates and disrupting their flow, unless they have high priority code changes like hotfixes or if they are attempting to meet last minute deadlines. 

In most teams, long pickup times push developers to ping each other to get the code reviews completed, thus shaping a negative culture that threatens maker’s time and thereby threatens developer productivity. By keeping a close watch on PR pickup times and team involvement in code reviews, dev teams can ensure maker time is preserved.

Preserve maker’s time

Along with improving the quality of meetings (agendas, relevant invite lists, etc!), dev teams can reduce the risk of burnout by managing meeting loads using the concept of maker’s schedule. Clubbing meetings to defined time periods with the aim of reducing fragmentation can greatly aid in facilitating deep work.

Maker time dashboard by Hatica

Work visibility using metrics

Dev teams can utilize work visibility metrics and dashboards to prevent the need to ping. Data-driven visibility can reduce bias, promote async work, and facilitate a culture of productivity-based recognition. Such a practice increases developer motivation and satisfaction, leading to better and sustained productivity. 

Activity log table by Hatica

💡 Hatica’s engineering analytics platform equips dev teams with data about their team’s available makers’ time, meeting and communication load, and provides visibility into factors that cause a risk of burnout. Get a demo → 

Subscribe to Hatica's blog

Get bi-weekly emails with the latest from Hatica's blog

Share this article: