Discover more from Engineering Enablement
What Happens When Software Developers Are Unhappy?
Unhappy developers are less productive, less motivated, and write lower quality code.
This week I read What Happens When Software Developers Are Unhappy?, a study by Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, and Pekka Abrahamsson. This was a part of a series of studies conducted by Graziotin and his colleagues focused on developer happiness. In a previous issue, I reviewed their research on what causes unhappiness for developers. This study examines what happens as a result of developers being happy or unhappy.
My summary of the paper
In nearly all studies investigating the happiness of developers and its impact on performance, the findings point to a positive relationship. For example, in a controlled experiment where participants were asked to write a trace of algorithm execution, induced happiness was found to be associated with higher debugging performance (Khan et al., 2010). Or in a 2013 survey study, developers assessed that happiness positively influenced their productivity at work (Wrobel, 2013).
Similar to other studies, happiness is defined as “frequent experiences of positive affect.” To measure (un)happiness, researchers used a validated survey instrument called the Scale of Positive and Negative Experience (SPANE).
In this study, developers were asked to recall a situation in which they were happy or unhappy at work, and then provide details on how their software development was affected. This study adds to the growing body of research on developer happiness by providing insights on which the relationships between happiness and performance can be explored in the future.
Consequences of developer happiness and unhappiness
74 consequences of happiness and unhappiness were identified based on the study, which were then divided into two buckets: “internal consequences” which only impact a developer individually, and “external consequences” which impact a project, process, or software artifact.
This study found that unhappiness results in mostly external consequences, while happiness mostly affects developers individually. “Developers more frequently consider their happiness to benefit themselves, and their unhappiness to be detrimental to others."
Productivity, motivation, and code quality surfaced as the top three factors affected by developer (un)happiness. Table 4 below shows the top 10 consequences of unhappiness:
Table 5 below shows the top 10 consequences of happiness:
Here’s a closer look at some of the consequences of (un)happiness discovered in this study:
Unhappiness causes lower mental performance, or how efficiently developers process information. That includes low focus (not being able to think things through as clearly as one otherwise would be able to), cognitive skills dropping off, and general mental fatigue.
Happiness causes developers to feel more focused, have higher problem-solving performance, higher mental energy, and more.
Unhappiness causes breaks in developers’ state of attention and concentration, which researchers note can have adverse effects on the process.
Happiness allows developers to enter a state of sustained flow.
Unhappiness can impact a developer’s work product, too. “Lower code quality represents the consequences of unhappiness of developers that are related to deterioration of the artifacts’ quality.”
Happiness helps developers “make fewer mistakes, see solutions to problems more easily, and make new connections to improve the quality of the code.” Researchers note that “High code quality is the single most significant consequence, in terms of frequency, of happy feelings while developing software.”
As shown in the study, developer (un)happiness can have a major impact on software team outcomes. The researchers note that leaders can “attempt to foster happiness of software development teams by limiting their unhappiness,” and add that “addressing unhappiness will limit the damage in terms of several factors at the individual, artifact, and process level.”
I’ve enjoyed reading research on the positive relationship between developer happiness and productivity. While the "happy-productive worker thesis" may seem obvious on the surface, I see so much still yet to be explored as far as research that can help inform fascinating real-world decisions.
For example, there's frequent discussion about the pitfalls of premature adoption of microservices. But at what point does increased code ownership and autonomy from microservices lead to an increase in developer happiness and productivity that outweighs the overhead costs? This is perhaps a silly question, but one that I pondered this week while on a bicycle ride.
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 LinkedIn, or reply to this email.