This week I read Today Was a Good Day: The Daily Life of Software Developers by André N. Meyer, Earl T. Barr, Christian Bird, and Thomas Zimmermann. Their large-scale study at Microsoft looked to understand what makes a developer’s workday “good”, as well as other patterns and characteristics of developer workdays.
My summary of the paper
Research shows that satisfied developers are more productive, and that good workdays increase developer job satisfaction. Therefore, understanding what differentiates good workdays from other days can help increase developer satisfaction and productivity.
To study what good and typical developer workdays look like, researchers collected self-reported data from developers across four months, asking them whether they considered their previous workday to be good or typical, and how their time was spent. The responses were analyzed to understand which factors lead to good workdays as well as other patterns and characteristics of developer workdays.
Here were the key findings:
11 factors contribute to developers having a “good” day
Researchers identified 11 factors impacting developers’ assessment of a good workday. The factors were organized into three high-level factors, (1) value creation, (2) efficient use of time, and (3) sentiment. The paper covers each of these factors in more depth, with positive quotes and descriptions from developers.
On “good” days, developers spend more time developing and less time collaborating
For example, time spent reading and writing code is 30 minutes higher on good workdays (compared to bad ones), and time spent in collaborative activities such as meetings is about a half an hour less.
The six types of developer workdays
The researchers performed a cluster analysis on developers’ time-use data to identify six distinct types of developer workdays: “Testing”, “Bug fixing”, “Coding”, “Collaborating”, “Meeting”, and “Various”. The number of good workdays in each cluster once again confirms that developers feel more positive on work days where they can work alone and focus most of their time on development related activities.
Emails and meetings are not necessarily bad
Developers prefer coding versus meetings, but their attitude toward meetings depends on the development phase. “We should actively work on reducing interruptions and meetings during the development phase (and on development-heavy days), and encourage them at times when collaboration is most crucial, such as phases of planning/specification, testing and release.”
Email activity was found to have little effect on whether a workday is good or not. “Respondents mentioned other factors that make their work more fragmented and divert them away from their main work tasks, including long or topic-unrelated interruptions, and being blocked on a task and having to wait for others.”
Good days go as planned
One of the core differences between good and typical workdays is whether a day goes as expected. Unplanned disruptions that developers feel they don’t have control over frustrate them by fragmenting their workdays. “Being able to freely control how to best organize one’s workday and whether it goes as planned/expected or is disrupted by external factors is important.” The authors add, “the finding of the importance of agency is in line with previous work in psychology, in which increased autonomy in a high-variety task led to increased satisfaction.”
The findings of this study line up with my personal experience as well as our recent research on developer experience. I particularly appreciated this paper’s analysis of the importance of providing developers’ agency over the structure of their workdays. Developers can often end up being treated like cogs in a wheel with a constant stream of unplanned work and requests thrown at them. It’s important to provide autonomy and clear structure in order to maximize developer satisfaction and productivity.
That’s it for this week! If you know someone who would enjoy this newsletter, please consider sharing it with them.
As always, reach out with thoughts about this newsletter on Twitter at @abinoda, or reply to this email.
Thank you, Abi, for greatly summarizing our paper! One thing I want to emphasize is also that developers' perceptions of what a good, typical and productive workday is is highly individual. Thus, solutions and improvements to processes, tools, workflows, offices, etc. should consider these individual differences, for example by regularly collecting each developer's feedback - very similar to what DX and other user-feedback driven approaches are doing.