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:
1. 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.
2. 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.
3. 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.
[Read: How to Prevent Software Engineers' 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 can 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.
