What Makes Developers Unhappy?
The key to fostering happy developers may be to focus on their unhappiness.
This week I read the paper On the Unhappiness of Software Developers by Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, and Pekka Abrahamsson. This was a large-scale survey study with over 2,000 developers that looked to understand happiness among developers and what the top causes of unhappiness are.
My summary of the paper
This paper builds on prior research on the relationship between developer happiness and performance, productivity, and software quality. The authors remark that Silicon Valley companies are notable for the perks they offer developers to make them happy, and make reference to the “happy-productive worker thesis”, which states that happy workers are more productive.
Happiness is defined as “a sequence of experiential episodes. Being happy corresponds to frequent positive experiences, which lead to experiencing positive emotions. Being unhappy corresponds to the reverse: frequent negative experiences leading to negative emotions. Happiness is the difference or balance between positive and negative experiences.”
To measure happiness, researchers use a validated survey instrument called the Scale of Positive and Negative Experience (SPANE). “Respondents are asked to report on their [emotions and moods], from the past four weeks. This provides a balance between the sampling adequacy of affect and the accuracy of human memory to recall experiences and reduce ambiguity.”
Prior research has found that:
Happy developers perform better than unhappy developers. “We have previously shown that happy developers solve problems better, and that there is a relationship between [happiness] and how developers assess their own productivity.”
Unhappiness has a negative effect both for developers personally and on development outcomes. The eight most significant consequences of developer unhappiness were, in order: low productivity, low code quality, lower motivation, work withdrawal, delay, low focus, inadequate performance, and decreased process adherence.
Managers may benefit from focusing on improving happiness by reducing negative experiences, rather than maximizing positive experiences. "The literature suggests that a cost-effective way to foster happiness and productivity among workers could be to limit unhappiness.”
What makes developers unhappy?
The authors’ study specifically focused on understanding the causes of unhappiness for developers. The most common causes are listed below.
What is notable is that most of the top causes of unhappiness are external causes that managers can influence. (e.g., time pressure, bad code quality and coding practice, an underperforming colleague, or repetitive tasks.)
“We expected that the majority of the causes of unhappiness would come from human related considerations (416 references); however, technical factors from the artifact (788) and the process (544) dominate the unhappiness of developers, highlighting the importance of strategic architecture and workforce coordination.” The authors remarked that, “Since external causes may be easier to influence than internal causes, and since influencing them will impact several developers rather than only one at a time, this suggests that there are plenty of opportunities to improve conditions for developers in practice.”
Final thoughts
This paper provides helpful guidance for leaders who care about developer happiness. It’s worth reiterating that developer happiness isn’t just a feel-good topic. Numerous research studies have shown that improving developer happiness can boost performance and work quality. I’ll conclude with a wonderful quote from a related paper by the same authors:
“To get productive output from a human, we must first invest. As humans, software developers’ productivity depends on their skills and knowledge—but to access those, we need to create favorable conditions that allow the human potential to be realized…. Developer satisfaction is important for productivity because reduced satisfaction can incur future costs; it follows that companies should be interested in the general well-being of their software developers. Furthermore, we believe we should simply strive to create better working environments, teams, processes, and, therefore, products.”
Other recommended reads
Oncall Philosophies | Gergely Orosz, author of The Pragmatic Engineer
“In reality, there are two main ways of thinking about oncall: A) Oncall for software engineers is additional (companies hire or compensate for it), and B) Oncall is part of the job (not hired or compensated for).”
Gergely also shares how much different companies pay for oncall here.
PM + EM: Rules of Engagement | Stephanie Evans and others, Segment
A helpful document for PMs and EMs who are new or otherwise want to build a better partnership. One helpful reminder is in the “How to show up as a great owner” section:
“If you’re an EM, your PM needs you to drive the technical vision for the team to avoid mountains of tech debt. The EM needs to own the active prioritization of stability, scalability, and developer experience work. The PM rarely has a full line of sight into these issues…”
Speaking plainly about technical debt | James Shore, author of The Art of Agile Development
“And that’s how you keep code quality high: refactoring. Refactoring all the time. It’s not something you have to ask permission to do—it’s something you just DO.”
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.
-Abi