While it is intuitive that happiness is beneficial for productivity and well-being, these ideas are also supported by scientific research. We have previously shown that happy developers solve problems better , that there is a relationship between affect and how developers assess their own productivity , and that software developers themselves are calling for research in this area . We have also presented a theory that provides an explanation of how affect impacts programming performance : events trigger affects in programmers. These affects might earn importance and priority to a developer’s cognitive system, and we call them attractors
. Together with affects, attractors drive or disturb programmers’ focus, which impacts their performance. On a larger scale, our studies show that affect is an important component of performance in software teams and organizations . Affect is linked to group identity—the feeling of belonging to the group—affecting cohesion and social atmosphere, which in turn are key factors for team performance and retention of team members.
We will now consider four important and ambitious questions.
How happy are software developers overall?
What makes them (un)happy?
What happens when they are (un)happy?
Are happy developers more productive?
Answering these questions is challenging. We spent a year designing a comprehensive study [4, 6] to address them. We needed data from as many software developers as possible. We also needed as much diversity as possible in terms of age, gender, geographical location, working status, and other background factors. We designed and piloted a questionnaire in such a way that the results could be generalizable (with a certain error tolerance) to the entire population of software developers. Our questionnaire had demographic questions, SPANE, and open-ended questions asking about developers’ feelings of happiness and unhappiness when developing software. We asked them to describe a concrete recent software development experience, what could have caused them to experience their feelings in that situation, and if their software development was influenced by these feelings in any way, and, if so, how.
We obtained 1,318 complete and valid responses to all our questions.
How Happy Are Software Developers?
In Figure 10-1, you can see how happy our 1,318 participants were.
Our participants had a SPANE-B average score of 9.05, and we estimated the true mean happiness score of software developers to be between 8.69 and 9.43 with a 95 percent confidence interval. In other words, most software developers are moderately happy.
We compared our results with similar studies (Italian workers, U.S. college students, Singapore university students, Chinese employees, South African students, and Japanese college students). All results from other studies reported a mean SPANE-B score higher than 0 but lower than in our study. Software developers are indeed a slightly happy group—and they are happier than what we would expect based on knowledge about various other groups of the human population. This is good news, indeed, but there is room for improvement nonetheless. Some developers have a negative SPANE-B score, and there were many examples in the open responses about episodes of unhappiness that could be avoided.
What Makes Developers Unhappy?
Our analysis of the responses of our 1,318 participants uncovered 219 causes of unhappiness, which were mentioned 2,280 times in the responses . We present here a brief summary of the results and the top three categories of things that make developers unhappy.
The causes of unhappiness that are controllable by managers and team leaders are mentioned four times as often as those being personal and therefore beyond direct managerial control. We also expected the majority of the causes to be related to human aspects and relationships. However, most of them came from technical factors related to the artifact (software product, tests, requirements and design document, architecture, etc.) and the process. This highlights the importance of strategic architecture and workforce coordination.
Being stuck in problem-solving and time pressure are the two most frequent causes of unhappiness, which corroborates the importance of recent research that attempts to understand these issues. We recognize that it is in software development’s nature to be basically problem-solving under deadlines: we cannot avoid problem-solving in software development. However, developers feel bad when they are stuck and under pressure, and several detrimental consequences do happen (see the rest of this chapter). This is where researchers and managers should intervene to reduce the detrimental effects of time pressure and getting stuck. Psychological grit could be an important characteristic to train among software developers. Another could be how to switch your mind-set to get unstuck.
The third most frequent cause of unhappiness is to work with bad code and, more specifically, with bad code practices. Developers are unhappy when they produce bad code, but they suffer tremendously when they meet bad code that could have been avoided in the first place. As our participants stated, bad code can be a result of management decisions aiming to save time and effort in the short term. Similar negative effects were mentioned regarding third persons (such as colleagues, team leaders, or customers) who make developers feel inadequate with their work, forced repetitive mundane tasks, and imposed limitations on development. Many of the negative consequences can be avoided by rotating tasks, by making better decisions, and by actually listening to developers. Several top causes are related to perceptions of inadequacy of the self and others, validating recent research activities related to interventions that improve the affect of developers .
Finally, we see that factors related to information needs in terms of software quality and software construction are strong contributors to unhappiness among developers. Chapter 24 shows an example of how current software tools may overload developers with information and illustrates how problems related to information flow could be solved for individual developers, teams, and organizations. More research is needed on producing tools and methods that make communication and knowledge management in software teams easier and that help effortlessly store, retrieve, and comprehend information in all stages of the software development life cycle.
What Happens When Developers Are Happy (or Unhappy)?
We classified the answers to our open-ended questions and found dozens of causes and consequences of happiness and unhappiness while developing software [4, 6]. Developers in our study reported a variety of consequences of being unhappy. We have summarized these consequences in Figure 10-2. There is a pictogram for each major consequence, and they are divided into internal and external consequences. The internal consequences, pictured inside the mind of the developer, are directed toward developers themselves and have a personal impact. The external consequences are ones that have an effect outside the individual developer. They might impact a project, the development process, or a software artifact.
As you can see, developers reported several productivity-related consequences—and some even explicitly reported experiencing lower productivity. Other consequences include delays, process deviations, low code quality, throwing away code, and breaking the process flow in projects. These external effects are direct impacts on productivity and performance. Internal consequences, such as low motivation and reduced cognitive performance, indirectly affect productivity as well. Work withdrawal and mental unease, or, in the worst case, signs of disorders, are among the gravest consequences mentioned that impact developers personally.
For the purposes of this chapter, it is worth going into more detail on the consequences of happiness and unhappiness, because several of them are productivity-related and productivity was the most populated category of consequences. We are reporting them in an order that favors narrative, not by frequency of occurrence.
We found that being happy or unhappy influences several factors related to cognitive performance, that is, how we efficiently process information in our brain. Happiness and unhappiness influence how we can focus while coding, as put by one participant: “[…] The negative feelings lead to not thinking things through as clearly as I would have if the feeling of frustration was not present.” The opposite also holds true: “My software development is influenced because I can be more focused on my tasks and trying to solve one problem over another.” As the focus can be higher when happy (or lower when unhappy), a natural consequence is that problem-solving abilities are influenced: “I mean, I can write codes and analyze problems quickly and with lesser or no unnecessary errors when I’m not thinking of any negative thoughts.” Being happy while developing software brings higher learning abilities: “It made me want to pursue a master’s in computer science and learn interesting and clever ideas to solve problems.” However, being unhappy causes mental fatigue, and participants reported “getting frustrated and sloppy.”
mentioned how being unhappy caused breaks in their flow. Flow is a state of intense attention and concentration resulting from task-related skills and challenges being in balance (see more about that in Chapter 23). Unhappiness causes interruptions in developers’ flow, resulting in adverse effects on the process. As put by a participant, “Things like that [of unhappiness] often cause long delays or cause one getting out of the flow, making it difficult to pick up the work again where one has left off.” When happy, developers can enter a state of sustained flow. They feel full of energy and with strong focus. In such a state, they are “unaware of time passing.” They can “continue to code without any more errors for the rest of the day” and “just knock out lines of code all day,” with “dancing fingers.” Flow is related to mindfulness, which is discussed in Chapter 25.
Motivation and Withdrawal
Motivation was often mentioned by our participants. They were clear in stating that unhappiness leads to low motivation for developing software: “[The unhappiness] has left me feeling very stupid, and as a result I have no leadership skills, no desire to participate, and feel like I’m being forced to code to live as a kind of punishment.” The participants also stated that increased motivation occurred when they were happy.
Unhappiness and happiness are causes of work withdrawal and work engagement, respectively. Work withdrawal is a destructive consequence of unhappiness, and it emerged often among the responses. Work withdrawal is a family of behaviors that is defined as employees’ attempts to remove themselves, either temporarily or permanently, from daily work tasks. We found varying degrees of work withdrawal, ranging from switching to another task (“[…] You spend like two hours investigating on Google for a similar issue and how it was resolved, you find nothing, and desperation kicks in.”) to considering quitting developing software (“I really start to doubt myself and question whether I’m fit to be a software developer in the first place.”) or even quitting the job. High work engagement and perseverance, on the other hand, were reported to occur when respondents were happy. This means, for example, pushing forward with a task: “I think I was more motivated to work harder the next few hours.” This is slightly different from motivation, which is more about the energy directed to acting toward a goal. Work engagement is committing to the act of moving toward a goal.
Happiness and Unhappiness, and How They Relate to the Productivity of Developers
Finally, participants directly mentioned how unhappiness hinders their productivity. We grouped all responses related to performance and productivity losses. The responses within this category ranged from simple and clear (“productivity drops” and “[Negative experience] definitely makes me work slower”) to more articulated (“[Unhappiness] made it harder or impossible to come up with solutions or with good solutions.”). Unhappiness also causes delays in executing process activities: “In both cases [negative experiences] the emotional toll on me caused delays to the project.” Of course, participants reported that happiness leads to high productivity: “When I have this [happy] feeling, I can just code for hours and hours,” “I felt that my productivity grew while I was happy,” and “The better my mood, the more productive I am.” Here are more details on that by one participant: “I become productive, focused, and enjoy what I’m doing without wasting hours looking here and there in the code to know how things are hooked up together.” An interesting aspect is that, when happy, developers tend to take on undesired tasks: “I think that when I’m in this happy state, I am more productive. The happier I am, the more likely I’ll be able to accomplish tasks that I’ve been avoiding.” On the other hand, unhappy developers could be so unproductive that they become destructive. We found some instances of participants who destroyed the task-related codebase (“I deleted the code that I was writing because I was a bit angry”) up to deleting entire projects (“I have deleted entire projects to start over with code that didn’t seem to be going in a wrong direction.”). Another intriguing aspect is about long-term considerations of being happy: “I find that when I feel [happy], I’m actually more productive going into the next task, and I make better choices in general for the maintenance of the code long-term. […] I’m more likely to comment code thoroughly.”
Are Happy Developers More Productive?
But are happy developers really more productive? Whenever science attempts to show if a factor X causes an outcome Y, researchers design controlled experiments. Controlled experiments attempt to keep every possible factor constant (A, B, C, ...) except for the factors (X) that should cause a change to the outcome Y. You can find more about controlled experiments in Chapter 9. Whenever this control is not possible, we call these studies quasi-experiments.
Here is the issue with research on happiness: it is challenging to control the happiness (or the mood, the emotions) of people. One of the reasons is that a perfectly controlled experiment would need to be quite unethical to make the unhappy control group truly unhappy. The effects of asking participants to remember sad events, or showing depressing photographs, is negligible. Still, we set up two quasi-experiments to observe some correlations.
One of these studies  has received considerable media attention. We tested a hypothesis regarding a difference of intellectual (cognitive-driven) performance in terms of the analytical (logical, mathematical) problem-solving of software engineers according to how happy they were. We also wanted to perform a study where all the tools and measurements came from psychology research and were validated. So, we designed a quasi-experiment in a laboratory, where 42 BSc and MSc students of computer science had their happiness measured and then conducted a task resembling algorithmic design. For measuring happiness, we opted for SPANE (explained previously).
The analytic task was similar to algorithm design and execution. We decided to administer the Tower of London test (also known as Shallice test) to our participants. The Tower of London test resembles the Tower of Hanoi game. The test comprises two boards with stacks and several colored beads. There are usually three stacks per board, and each stack can accommodate only a limited number of beads. The first board presents predefined stacked beads. The participants received the second board, which has the same beads as the first board but stacked in a different configuration. The participants have to re-create the configuration of the first board by unstacking one bead at a time and moving it to another stack. The Psychology Experiment Building Language (PEBL) is an open source language and a suite of neuropsychology tests [13, 14]. The Tower of London test is among them.
PEBL was able to collect the measures that let us calculate a score for the analytic performance. We compared the scores obtained in both tasks with the happiness of developers. The results showed that the happiest software developers outperformed the other developers in terms of analytic performance. We estimated the performance increase to be about 6 percent. The performance increase was not negligible, and we confirmed it by measuring Cohen’s d statistic. Cohen’s d is a number usually ranging from 0 to 2, which represents the magnitude of the effect size of a difference of means. Our Cohen’s d for the difference between the two groups mean was 0.91—a large effect given that we did not obtain extreme cases of happiness and unhappiness. The margins could even be higher than that.
In another study , we did something more esoteric. We aimed to continue using psychology theory and measurement instruments for understanding the linkage between the real-time affect (let’s say happiness) raised by a software development task and the productivity related to the task itself. Eight software developers (four students and four from software companies) worked on their real-world software project. The task length was 90 minutes (as it is about the typical length for a programming task). Each ten minutes, the developers filled a questionnaire formed by the Self-Assessment Manikin (SAM) and an item for self-assessing the productivity.
SAM is a scale for assessing an emotional state or reaction. SAM is peculiar because it is a validated way to measure the affect raised by a stimulus (like an object, or a situation) and it is picture-based (no words). SAM is simply three rows of puppets with different face expressions and body language. Therefore, it is quick for a participant to fill SAM, especially if implemented on a tablet (only three touches). We analyzed how developers felt during the task and how they self-assessed themselves in terms of productivity. Self-assessment is not a very objective way of measuring productivity, but it has been demonstrated that individuals are actually good at self-assessing themselves if they are observed alone . The results have shown that high pleasure with the programming task and the sensation of having adequate skills are positively correlated with the productivity. This correlation holds over time. We also found that there are strong variations of affect in 90 minutes of time. Happy software developers are indeed more productive.