RDEL #70: What types of friction contribute to bad days for software engineers?
This week we cover what type and how often bad days impact software engineers, as well as their impact.
Welcome back to Research-Driven Engineering Leadership. Each week, we pose an interesting topic in engineering leadership and apply the latest research in the field to drive to an answer.
It’s normal to experience some friction in the day-to-day software engineering experience, but too much of it can lead to a notable decrease in morale in productivity. This week we look at the research to identify: what are the types of friction that contribute to bad days, and how do those experiences impact productivity and morale?
The context
Software engineering is a discipline deeply reliant on tools, processes, and teamwork. A productive day allows engineers to flow seamlessly between writing code, debugging, and collaborating. However, disruptions—whether technical (e.g., broken builds) or interpersonal (e.g., communication breakdowns)—can derail even the most experienced developers. Research has repeatedly shown that positive developer experiences (like happiness) lead to higher productivity, stronger retention, and even measurable business growth.
While it’s tempting to address "bad days" by in a purely technical manner (i.e build times), the root causes often involve deeper, interconnected factors. Developers may face systemic challenges that exacerbate stress, hinder their progress, and even lead to feelings of self-doubt or burnout. For leaders, recognizing and addressing these nuanced contributors is essential to building a resilient and satisfied engineering team.
The research
To explore what constitutes "bad days" for developers, researchers employed a mixed-methods approach that included interviews, surveys, diary studies, and telemetry data. They gathered qualitative insights from 22 developers, surveyed 214 participants for broader patterns, tracked daily experiences from 79 engineers over a month, and validated findings with telemetry data from 131 participants.
First, researchers identified what a “bad day” meant to software engineers. The top answer was “engineering system friction”, followed by “blocked or stuck”.
Next, researchers used the survey responses to rank the most common factors that contribute to a bad day:
Finally, the researchers analyzed the self-reported frequency of bad days and found that 35% of people experience bad days 3-5 times in a month.
In an comprehensive analysis of the data, researchers had the following conclusions:
Bad days go far beyond technical inefficiencies. The three most common categories were tooling and infrastructure, process inefficiencies, and challenges with team dynamic/communication.
Bad days can impact senior vs junior engineers differently. While senior engineers experience more anger, frustration, and disillusionment, junior engineers instead feel guilt or self-doubt. However, bad days are consistently linked to lower productivity.
Telemetry data verifies developer experience. In reviewing telemetry data analysis, researchers found a statistically significant difference in PRs and build process log data between those who said that the respective factors contributed to bad days vs. those who did not.
Developers reporting pull request delays experienced 23.8% longer average review times, and those citing long builds faced a 26.3% increase in build times.
The application
The findings emphasize that "bad days" are influenced by both technical and interpersonal factors, requiring a holistic approach to improvement. By addressing tooling issues, clarifying processes, and fostering a supportive team culture, engineering leaders can significantly reduce the frequency and impact of these challenges.
For engineering leaders looking to apply this data to their day-to-day work, here are some recommendations:
Measure the Prevalence of "Bad Days". In order to make meaningful improvements on the team, there needs to a baseline understanding of how a team is feeling and what bottlenecks are contributing to their challenges. This can be achieved in group discussions, but is best done through a brief survey.
Establish Feedback Loops. Create structured opportunities for developers to share blockers and frustrations, such as in retrospectives or one-on-ones, and prioritize addressing recurring themes. This will become an important channel to prioritizes areas to resolve, and to understand improvement.
Consider both technical and interpersonal factors. It is often tempting to focus on the technical causes for bad days (i.e poor tooling), but this paper highlights that interpersonal factors can be just as impactful of factors on productivity and morale.
By understanding and addressing the factors behind "bad days," leaders can create a healthier, more productive engineering environment.
—
Thanks for reading, and a very happy Thanksgiving for our US-based RDEL readers!
Lizzie