What happens when software developers are (un)happy

The growing literature on affect among software developers mostly reports on the linkage between happiness, software quality, and developer productivity. Understanding happiness and unhappiness in all its components -- positive and negative emotions and moods -- is an attractive and important endeavour. Scholars in industrial and organizational psychology have suggested that understanding happiness and unhappiness could lead to cost-effective ways of enhancing working conditions, job performance, and to limiting the occurrence of psychological disorders. Our comprehension of the consequences of (un)happiness among developers is still too shallow, being mainly expressed in terms of development productivity and software quality. In this paper, we study what happens when developers are happy and not happy. Qualitative data analysis of responses given by 317 questionnaire participants identified 42 consequences of unhappiness and 32 of happiness. We found consequences of happiness and unhappiness that are beneficial and detrimental for developers' mental well-being, the software development process, and the produced artefacts. Our classification scheme, available as open data enables new happiness research opportunities of cause-effect type, and it can act as a guideline for practitioners for identifying damaging effects of unhappiness and for fostering happiness on the job.


Introduction
The idea of flourishing happiness among developers is often promoted by software companies, which knowingly or accidentally attempt to enact the happy-productive worker thesis (Zelenski et al., 2008). The happiness of all stakeholders involved in software development is an essential element of company success (Denning, 2012). Recent research within the scope of behavioural software engineering (Lenberg et al., 2015) has highlighted the relationship between software developer happiness and work-related constructs such as performance and productivity (Graziotin et al., 2015a(Graziotin et al., , 2014bFagerholm et al., 2015;Müller and Fritz, 2015;Ortu et al., 2015), quality (Khan et al., 2010;, and the social interactions between developers (Novielli et al., 2015;Fagerholm et al., 2015). Most of the studies to date have investigated the positive side of happiness.
While happiness, for the individual, is inherently subjective, research shows that it can be studied objectively. Objective happiness can be construed as the difference between experienced positive affect and experienced negative Email addresses: daniel.graziotin@informatik.uni-stuttgart.de (Daniel Graziotin), fabian.fagerholm@helsinki.fi (Fabian Fagerholm), xiaofeng.wang@unibz.it (Xiaofeng Wang), pekkaa@ntnu.no (Pekka Abrahamsson) affect (Diener et al., 1999;Kahneman, 1999). Thus, maximizing happiness may be achieved by either maximizing positive experiences or minimizing negative experiences (or both). Studying both happiness and unhappiness is needed to more thoroughly understand the options and opportunities for increasing net happiness.
Focusing on the negative may already be intuitive to many developers. It is a common occurrence that developers share horror stories about their working experience (Graziotin et al., 2014c). Managers in the software profession would benefit from greater understanding of the nature and dynamics of unhappiness among developers, and they could take action to prevent dysfunctional responses among employees (Vecchio, 2000). Further understanding of the benefits of limiting negative experiences on the job in general has been called for (Diener et al., 1999).
We aim to contribute to improved working conditions and quality of life for software developers by broadening the understanding of the (un)happiness of software developers. We are conducting a series of studies using a largescale quantitative and qualitative survey of software developers. Through those studies, we seek to assess the distribution of (un)happiness in the developer population, the causes of (un)happiness, and what the consequences of those experiences are. The study described in the present article is part of that series, and focuses on the consequences of (un)happiness, i.e., what software developers consider to happen when they experience happiness or unhappiness. We have previously reported on other parts of the study series, first as a poster-preview of results regarding the consequences of unhappiness (Graziotin et al., 2017d) which preceded a workshop paper on the same subject (Graziotin et al., 2017a). The present article is an extension of the workshop paper. We have reported on the (un)happiness distribution among software developers and the experienced causes of unhappiness in a separate paper (Graziotin et al., 2017b).
The present article extends the previously reported findings on the consequences of unhappiness (Graziotin et al., 2017a) by including consequences of happiness and considering the two together. Specifically, we investigate the following research questions: RQ1: What are the experienced consequences of unhappiness among software developers while developing software? RQ2: What are the experienced consequences of happiness among software developers while developing software?
We report 42 experienced consequences of unhappiness and 32 of happiness that we identified. The consequences concern developers themselves in the form of cognitive and behavioural changes, and external outcomes related to the software development process and artefacts.

Background and Related Work
What is happiness, and how can it be assessed? Intuitively, happiness is related to an individual's sensing of their own affect. In this section, we give a brief overview of the concepts and theory related to affect, emotions, moods, and happiness. We also discuss previous research on happiness and related constructs in the area of software engineering.

Theory of Affect and Happiness
Affect is widely agreed to be "a neurophysiological state that is consciously accessible as a simple, non-reflective feeling that is an integral blend of hedonic (pleasure -displeasure) and arousal (sleepy -activated) values" (Russell, 2003, p. 147). For the purposes of this paper, we use the theory by Russell (2003), and we thus consider affect to be the atomic unit upon which moods and emotions are constructed. Following several other authors, e.g. Fisher (2000) and Khan et al. (2010), we consider moods to be prolonged, unattributed affect, while emotions are interrelated events concerning a psychological objectan episodic process, clearly bounded in time, where an individual perceives their own affect.
From a hedonistic viewpoint, happiness is a sequence of experiential episodes (Haybron, 2001) and being happy (unhappy) is associated with frequent experiences of positive (negative) affect (Diener et al., 2010). 1 Frequent positive (negative) experiential episodes lead to feeling fre-1 Alternative views of happiness exist, e.g. Aristoteles' eudaimo-quent positive (negative) affect, leading to happiness (unhappiness) represented by a positive (negative) affect balance (Diener et al., 2010). Happy individuals are those who experience positive affect more often than negative, and unhappy individuals are those who experience negative affect more often than positive. In summary, happy individuals have a positive affect balance and unhappy ones have a negative affect balance (Lyubomirsky et al., 2005;Diener et al., 2010).

Affect and Happiness in Software Engineering Research
A considerable increase in the interest of studying affect and happiness among software developers is visible over the last five years, although the research is in its infancy; many theoretical and methodological issues remain in software engineering research, as illustrated by Graziotin et al. (2015c,b) and by Novielli et al. (2015).
Several studies have attempted to elucidate the complex relationship between happiness (and more generally, affect) and performance in the context of software development. In a study of the affect associated with eliciting requirements, investigating 65 user requirements from two projects, high activation and low pleasure levels were shown to be predictors of high versioning requirements (Colomo-Palacios and Casado-Lumbreras, 2011). Pleasure was increased over time with each new version, while activation decreased.
Theory-building is an important part of software engineering research, and theories regarding affect can inform further empirical studies. One such theory is an explanatory process theory of the impact of affect on development performance (Graziotin et al., 2015a). The theory was formed by a qualitative analysis of the interview data, communications, and observations of two software developers in the same project. The concept of attractors -affective experiences that earn importance and priority to a developer's cognitive system -was theorized to have the biggest impact on development performance.
Another theory that relates affective experiences to development performance is the Performance Alignment Work theory (Fagerholm et al., 2015), which explains a continuous cycle of becoming aware of, interpreting, and adjusting to changing performance demands in and beyond the organisational environment that software development teams are situated in. The theory also explains the ingredients that practitioners consider necessary to form and maintain high-performing teams, which are especially adept at carrying out the cycle. The theory was formed by a qualitative analysis of the interviews with 16 practitioners in five companies. Affective factors are found throughout the theory, especially in relation to motivators nia: a person is happy because (s)he conducts a satisfactory life full of quality (Haybron, 2005). A review of affect theories is given in (Graziotin et al., 2015c) and the role of the centrality of affect and happiness is discussed in (Graziotin et al., 2015a). for high performance, and in the social processes of becoming and being part of a high-performing team with a strong identity.
Correlational experiments have found a positive relationship between happiness and positive emotions arising from a development task (Graziotin et al., 2014b,a), and between problem-solving performance and development task productivity (Müller and Fritz, 2015). Affect has also been shown to impact debugging performance: in a controlled experiment where participants were asked to write a trace of algorithm execution, induced high pleasure and activation affect were found to be associated with high debugging performance (Khan et al., 2010).
Further evidence for the link that developers experience between emotion and performance is provided in a survey with 49 developers, assessing emotions they perceived to influence their own productivity (Wrobel, 2013). Positive affective states were perceived to be those that enhance development productivity. The negative affect most prevalently perceived was frustration, which was also the one perceived to deteriorate productivity the most. Ford and Parnin (2015) have further explored frustration in software engineering through interviews. 67% of 45 participants in their study reported frustration being a severe issue. Some of the causes for frustration were found to be related to a lack of a good mental model of the code, learning curves of programming tools, too large task sizes, the time required to adjust to new projects, lack of resources, perceived lack of programming experience, inability to complete problems perceived as simple within the bounds of estimated effort, fear of failure, internal hurdles and personal issues, limited time, and issues with peers.
In all the studies investigating the happiness of developers in different forms and its impact on performance, the findings point to a positive relationship. It is similar when software quality is concerned. A series of studies using software repository mining found links between affect, emotions, and politeness, and software quality (Ortu et al., 2015;Mäntylä et al., 2016). Happiness in terms of frequent positive affect and positive emotions was found to be associated with shorter issue fixing time (Ortu et al., 2015). The level of arousal, which, when high, is associated with anxiety and burnout, was found to be associated with issue priority (Mäntylä et al., 2016). Politeness in requests for resolving issues was correlated with shorter resolution time .
Finally, the present article is part of a series of articles examining a large data set concerning happiness and unhappiness among software developers. We have given a preview of the consequences of unhappiness in a poster paper (Graziotin et al., 2017d) and expanded on the same topic in a workshop paper (Graziotin et al., 2017a). We found a set of experienced consequences of unhappiness, including detrimental effects on developers' mental wellbeing, the software development process, and the produced artefacts. The present paper expands on these results. In addition, we have investigated the experienced causes of unhappiness (Graziotin et al., 2017b). We found that the distribution of (un)happiness among software developers, in terms of a quantitative, well established instrument for assessing happiness, pointed towards developers being a slightly happy population, with happiness scores higher than those reported for many other parts of the general human population. Furthermore, we found more than 200 factors representing causes of unhappiness, including being stuck in problem solving, time pressure, bad code quality and coding practice, under-performing colleagues, and feeling inadequate with the task.
In sum, the present state of research shows that happiness and affective experiences play an important role for software developers, and that they are intertwined with software development performance and quality. Several relationships between individual affects and outcomes have been demonstrated. Still, the present research leaves several questions unanswered. On one hand, there is insufficient empirically grounded theory to warrant inquiry into larger sets of causational relationships. On the other hand, the voice of software developers could be expressed more clearly and fully; the understanding of software developers' everyday experiences with the development activity is incomplete. We extend the picture in this paper with further perspectives on happiness and unhappiness among software developers.

Method
The present study is part of a series of inquiries that we conducted on the data from a large-scale survey of developers. The overall research project employs a mixed research method, with elements of both quantitative and qualitative research (Creswell, 2009). The present study, however, is purely qualitative. In this section, we describe both the overall research design as well as methodological details relevant to the present article.

Sampling Strategy
We consider a software developer to be a person concerned with any aspect of the software construction process (including but not limited to research, analysis, design, programming, testing, and management activities), for any purpose such as work, hobby, or passion. Since we do not accurately know the number of software developers in the world, nor how to reach them, finding a sample that would generalise to the population of software developers is a challenge. We used the GitHub social coding community as an avenue for reaching software developers that would represent the population of developers well enough, following several previous studies (e.g., Gousios et al. (2016)). GitHub has more than 30 million visitors each month (Doll, 2015) and is, as far as we can tell, the largest social coding community in the world. Software developers using GitHub work on a wide variety of projects, ranging from open source to proprietary software and from solo work to work done in companies and communities.
We extracted a set of developer contacts from the GitHub Archive (Grigorik, 2012), which stores public events occurring in GitHub. We retrieved event data for a period of six months, since we intended to reach developers who were active at the time of our study, meanwhile the amount of events during 6 months is sufficiently large to include as many developers as we desired. We extracted email addresses, given names, company names, developer locations, and the repository name associated with each event. We extracted unique entries that provided an e-mail address, resulting in a total of 456 283 entries of contact data, including e-mail addresses, given names, company names, and locations of the developers, as well as the repository name related to the public activity. Considering expected response rates, we sent invitations to 33 200 randomly selected e-mail addresses in the contact set.

Survey Design
We designed a survey consisting of (1) questions regarding demographics, (2) one question with the Scale of Positive and Negative Experience (SPANE) (Diener et al., 2010) with 12 items assessing happiness, and (3) two openended questions asking for experienced causes and consequences of positive and negative affect when developing software. The two open-ended questions asked developers to recall a time when they were developing software and were experiencing affects described by adjectives in the SPANE instrument (separately for positive and negative affects). Participants were then asked to describe the situation and provide details on what they believed could have caused them to experience the feelings, as well as whether and how their software development was influenced. The questionnaire is described in an online appendix (Graziotin et al., 2017c).
We piloted the questionnaire three times, each with 100 participants from our contact set. The pilots allowed us to estimate and improve response rates by refining the questions and invitation email. No data from the pilots were retained in the final data set and pilot participants did not participate in the final round. The present article covers the results related to the open-ended questions regarding the consequences of positive and negative affect (i.e., happiness and unhappiness) while developing software.

Analysis
We qualitatively analysed the cleaned data for the openended questions. We developed a coding strategy, applying open coding, axial coding, and selective coding as defined by Corbin and Strauss' Grounded Theory (Corbin and Strauss, 2008) as follows 2 . We began by coding consequences of unhappiness. The first three authors each coded the same set of 50 responses using a line-by-line strategy. We then compared the coding structure and strategy and reached an agreement, i.e., a shared axial coding scheme. We took the individual developer as the starting point and unit of observation and analysis, and based the construction of theoretical categories on a model (Curtis et al., 1988) of constructs that are internal or external to the developer. The internal category concerns the developer's own being, while the external category contains artefacts, processes, and people as subcategories. We then divided the data evenly among the first three researchers and proceeded to open code them. We finally merged the codes and conducted a last round of selective coding.
Once we had finished coding consequences of unhappiness, we took the resulting coding scheme, omitting the detailed leaf categories, and created a "reversed" or "mirrored" set of categories (examples are shown in Table 1). Using this as an initial coding scheme, we again divided the data evenly among the first three researchers, and open coded the entire data set, this time looking for consequences of happiness. Each researcher inserted sub-categories into the coding scheme as required. We then revisited the coding scheme together, and reached an agreement, producing a second shared axial coding scheme for consequences of happiness. One researcher then selectively recoded the data that did not fit this coding scheme (only a small number of instances needed re-coding), and the two other researchers verified the coding. Another researcher then made an additional coding pass to add some detail at the leaf level of the coding scheme. Finally, the same researcher revisited both coding schemes and recoded small parts in order to keep categories at similar levels so that the schemes would be comparable in terms of structure and prevalence of in-text occurrences 3 .
The end result is thus two coding schemes that are comparable at the top levels and in terms of structure, while still allowing for differing detailed categories on the more granular level. The coding process also allowed us to keep track of the chain of evidence at all times. An example illustrating the coding process of the consequences of unhappiness is given in Table 2, also available online (Graziotin et al., 2017c).
We note that we only included positive consequences for the happiness part and negative consequences for the unhappiness part. The reverse directions are not explored in this paper. Throughout the process of coding, we monitored our progress and further discussed the coding scheme and strategy in frequent meetings. All qualitative coding and analysis was done using NVIVO 11 ; some calculations were made using R and a standard spreadsheet and calculator. developer's own being → low cognitive performance developer's own being → high cognitive performance developer's own being → low motivation developer's own being → high motivation developer's own being → work withdrawal developer's own being → high work engagement and perseverance external consequences → artefact and working with artefact → low code quality external consequences → artefact and working with artefact → high code quality external consequences → process → low productivity external consequences → process → high productivity external consequences → process → decreased process adherence external consequences → process → increased process adherence

Results
In this section, we summarize the results of our investigation. We first show descriptive statistics describing the demographics of the participants. We then proceed to the qualitative data related to our RQs. We summarise the elicited consequences of unhappiness while developing software first, then move to the consequences of happiness, reflecting the order in which the analysis was performed.

Descriptive Statistics
A total of 2 220 individuals participated in the study. 1 318 provided data for the open questions. Out of these, 317 provided answers pertaining to positive consequences of happiness or negative consequences of unhappiness.
Since we treated the response data for the two research questions separately, the set of respondents for each question is different. In total, there are 317 respondents in the two data sets combined, counting each respondent only once. 70 of the respondents (22%) occur in both data sets, while 247 respondents (78%) occur only in one of the data sets. The descriptive statistics for the the data is shown in Table 3 and discussed below.
We obtained 181 valid and complete responses related to RQ1, which resulted in 172 male participants (95%) and 8 female (4%). The remaining participant indicated other / prefer not to disclose for gender. The mean year of birth was 1984 (standard deviation, sd = 8.27), while the median was 1986. A wide range of nationalities was represented, comprising 45 countries. 141 (78%) participants were professional software developers, 7% were students, and 13% were in other roles (such as manager, CEO, CTO, and academic researcher). The remaining participants were unemployed and not students. The participants declared a mean of 8.22 years (sd = 7.83) of software development working experience; the median was 5 years.
We obtained 206 valid and complete responses related to RQ2. In that set, 195 participants were male (95%) and 9 were female (4%). The remaining two participants declared their gender as other / prefer not to disclose. The mean year of birth was 1985 (sd = 9.67), and the median was 1987. A wide range of nationalities was represented, with 53 countries. 153 (74%) participants were professional software developers, 9% were students, and 16% had other roles (defined as above). The remaining two participants (1%) were unemployed and not students. The participants reported a mean of 8.23 years (sd = 8.9) of software development working experience, with a median of 5 years.
What are the Experienced Consequences of Unhappiness Among Software Developers While Developing Software?
We identified 250 coded instances related to the negative consequences of unhappiness. They were grouped into a scheme with 42 categories. The structure of the scheme is shown in Figure 1, which is also available as archived open data (Graziotin et al., 2017c). The material was divided into an internal category, labelled developer's own being (113 references), and the external categories process (102) and artefact (35).

Internal Consequences-Developer's Own Being
The factors related to the developer's own being do not demonstrate a clear structure. This to some extent reflects the versatile states of mind of developers and the feelings they could have while they develop software.
The most significant consequences of unhappiness for the developers' own being are: low cognitive performance, mental unease or disorder, low motivation and work withdrawal.
Low cognitive performance is a category to group all those consequences related to low or inadequate mental performance. Specific symptoms include low focus: "[. . . ] the negative feelings lead to not thinking things through as clearly as I would have if the feeling of frustration was not present "; cognitive skills dropping off: "My software dev skills dropped off as I became more and more frustrated until I eventually closed it off and came back the next day to work on it "; and general mental fatigue: "Getting frustrated and sloppy".
The mental unease or disorder category collects all those consequences that threaten mental health 4 . Apart from general lingering negative feelings, the participants reported that unhappiness while developing software is a cause of, in order of frequency, anxiety: "These kinds of situations make me feel panicky"; stress: "[. . . ] only reason of my failure due of burnout "; self-doubt: "If I feel particularly lost on a certain task, I may sometimes begin to question my overall ability to be a good programmer "; and sadness and depression. Participants mentioned depression as feeling depressed, e.g., "feels like a black fog of depression surrounds you and the project " or "I get depressed ". In addition, feelings of being judged, frustration, lack of confidence in one's ability, and (even) adverse physical reaction, although mentioned only once as the perceived consequences of unhappiness, do appear, and manifest the extent of mental unease or disorder caused by unhappy feelings.
low motivation for developing software, e.g., "[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. [. . . ] ", or "Also, I'm working at a really slow pace [. . . ] because I'm just not as engaged with the work ". Work withdrawal is a very destructive consequence of unhappiness, and it emerged often among the responses. Work withdrawal is a family of behaviours that is defined as employees' attempts to remove themselves, either temporarily or permanently, from quotidian work tasks (Miner and Glomb, 2010). The gravity of this consequence ranged from switching to another task, e.g., "[. . . ] you spend like 2 hours investigating on Google for a similar issue and how it was resolved, you find nothing, desperation kicks in. It clouds your mind and need to do other things to clear it ", 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, "I left the company".
Other consequences perceived by the participants include not being creative, "it is very difficult for me to do any creative work when angry or unhappy", resentful of being in the situation, being cautious, lower reputation, rushing, undervalued, and unhealthy coping behaviour, such as smoking excessively. Because of the low frequency of mentions in the data, we do not elaborate on these consequences further here.

External Consequences-Process
The category of process collects those unhappiness consequences that are related to a software development process, endeavour, or set of practices that is not explicitly tied up to an artefact (see Section 4.4).
Low productivity is a category for grouping all consequences of unhappiness related to performance and productivity losses 5 . The codes within this category were ranging from very simple and clear "productivity drops", "[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", "[. . . ], and [the negative experience] slowed my progress because of the negative feeling toward the feature".
Unhappiness was reported to be causing delay in executing process activities: "In both cases [negative experiences] the emotional toll on me caused delays to the project ". Unhappiness causes glitches to communication activities and a disorganized process: "Miscommunication and disorganization made it very difficult to meet deadlines".
Developers declared that unhappiness caused them to have decreased process adherence, i.e., deviating from the agreed set of practices. Specifically, unhappiness was reported to lead developers to compromise in terms of actions, in order to just get rid of the job: "In these instances my development tended towards immediate and quick 'ugly' solutions". Developers see the quality of their code compromised (Section 4.4) but also decide to take shortcuts when enacting a software process, compromising methodology, good management, and the quality of the process itself: "[. . . ] can lead to working long hours and trying to find shortcuts. I'm sure this does not lead to the best solution, just a quick one". The process adherence can suffer due to communication aspects, too: "my development was influenced by [negative affect] in that it caused me to tighten up communications and attempt to force resolution of the difficulties".
The broken flow category is related to the process deviation in terms of process unevenness and wasted time in restarting tasks. The concept of flow has been defined by Csikszentmihalyi (1997) as a state of intense attention and concentration resulting from task-related skill and challenge being in balance. Flow has been investigated by Müller and Fritz (2015) in the context of software development. 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. ". Unhappiness and broken flow make developers stand up and "[. . . ] make me quit and take a break "; the feeling of getting stuck is persistent.

External Consequences-Artefact-oriented
The category of artefact-oriented consequences groups all those consequences that are directly related to a development product, e.g., software code, requirements, and to working with it. As expected by the foci of previous research, the most important consequence of unhappiness of software developers was low software quality.
Low code quality represents the consequences of unhappiness of developers that are related to deterioration of the artefacts' quality. The participants reported that "eventually [due to negative experiences], code quality cannot be assured. So this will make my code messy and more bug can be found in it ", but also mentioned making the code less performant, or "As a result my code becomes sloppier ". Moreover, participants also felt that they could discharge quality practices, e.g., "[. . . ] so I cannot follow the standard design pattern", as a way to cope with the negative experiences.
Discharging code could be seen as an extreme case of productivity and quality drop. We found some instances of participants who destroyed the task-related codebase, e.g., "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".

What are the Experienced Consequences of Happiness Among Software Developers While Developing Software?
We now provide a summary of the elicited positive consequences of happiness while developing software. We identified a total of 340 coded instances related to the consequences of happiness, They are grouped into 32 categories and sub-categories. The structure of the categories is shown in Figure 2, and is available as archived open data (Graziotin et al., 2017c). Consistent with the unhappiness consequences, we defined an internal category, developer's own being (198 coded instances), and two external categories, process (104) and artefact (38).

Internal Consequences-Developer's Own Being
Similar to those of unhappiness consequences, the set of factors related to the developer's own being is varied and displays no clear structure. The most significant consequences of happiness for the developer's own being are: high cognitive performance, high motivation, perceived positive atmosphere, higher self-accomplishment, high work engagement and perseverance, higher creativity and higher self-confidence. Other less mentioned consequences include being valued, being proud, and healthy coping behaviour.
High cognitive performance is a category grouping all consequences related to high mental performance, such as being focused: "My software development is influenced because I can be more focused on my tasks and trying to solve one problem over another "; higher problem-solving performance: "I mean, I can write codes and analyse problems quickly and with lesser or no unnecessary errors when I'm not thinking of any negative thoughts"; higher mental energy: "This influenced my work by making me more alert, concentrated "; higher skills: ". . . felt that my skill has improved tremendously"; and higher learning abilities: "It made me want to pursue a masters in Computer science and learn interesting and clever ideas to solve problems". We excluded creativity from this category; while cognitive performance is an important component of creativity, the latter also requires divergent thinking and emotion plays a different role than in more logical tasks (see, e.g., Baas et al. (2008) and Davis (2009) for discussions on the emotional aspects of creativity).
High motivation is an important consequence of happiness for software developers. The participants stated that increased motivation occurred as they were happy, e.g., "When I write a bunch of code and compile/run it and it works without any errors. Though, when that happens I also become a bit suspicious. I felt more motivated to continue writing code at that point ".
Perceived positive atmosphere is an internal evaluation of the surrounding social context that participants reported occurring with happiness. Participants reported greater peace of mind: "it's very comforting"; as well as simply enjoying the moment: ". . . gives you the sense of achievement and joy".
Higher self-accomplishment refers to stronger or more frequent feelings of having achieved something successfully. With increased happiness during development, respondents reported that they felt having performed something successfully: "The sense of accomplishment when finishing something that actually works is very rewarding".
High work engagement and perseverance was reported to occur when respondents were happy. This means, e.g., pushing forward with tasks: "I think I was more motivated to work harder the next few hours".
Higher creativity was also a reported result of happiness. Participants reported finding it easier to come up with new ideas and to think divergently: "This give you energy [which] feed your creativity and you come up [with] more crazy and wonderful ideas".
Higher self-confidence means greater trust in one's personal abilities. This category includes both higher general self-confidence as well as task-specific self-confidence (self-efficacy). Participants expressed a shift in self-confidence when they were happy, e.g.: "These situations encourage me to pick up tasks that I was afraid of before, because they seemed to be too difficult ".
Being valued is another social evaluation experienced by participants when being happy: "My boss said 'You're the best' and then gave me a hug and I said 'nuh uh your tha best' ".
Participants also reported being proud when they were happy, both directed towards their work -"great pride in the work I've just completed " -and directed towards themselves -"I get more proud of myself ".
Finally, one participant reported on another developer's happiness encouraging healthy coping behaviour: "[He] has a definite positive effect on development, not just the production side but also my attitude when dealing with negative issues".

External Consequences-Process
Being in a happy mood was often associated by the participants to several positive consequences closely related to software development processes. Among different consequences, high productivity is the most frequently listed one, followed by expediation, sustained flow, increased collaboration and increased process adherence. Creative process is also a perceived consequence of happiness, though with one occurrence only.
The most noticeable positive consequence related to process by far is high productivity, as put by several participants, "When I have this [happy] feeling I can just code for hours and hours", "I felt that my productivity grew while I was happy", "The better my mood, the more productive I am". One participant described in more detail such high productivity caused by happy mood: "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 ". One interesting aspect of this high productivity caused by being in a happy state is Consequences of happiness (positive outcome) (340) developer's own being (198) high cognitive performance (51) being more focused (20) higher problem-solving performance (12) higher mental energy (11) higher skills (6) higher learning abilities (2) high motivation (42) perceived positive atmosphere (24) peace of mind (13) enjoying the moment (11) higher self-accomplishment (23) high work engagement and perseverance (20) higher creativity (15) higher self-confidence (13) being valued (6) being proud (3) healthy coping behaviour (1) external consequences (142) process (104) high productivity (61) expediation (12) sustained flow (12) increased collaboration (12) increased process adherence (6) do things right (2) write documentation (2) follow best practice (1) write tests (1) creative process (1) artefact and working with artefact (38) high code quality (38) that the developers tend to take on undesired tasks. As one participant admitted: "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". Another intriguing aspect is the long-term consideration invoked by the happy state of mind: "I find that when I feel this way [being 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". However, a few participants expressed the counter opinion, ether not perceiving any productivity increase when they feel happy, or perceiving it to a certain extent but cautioning that it is "not for long".
Expediation as a perceived consequence emphasises that when developers feel good during development, tasks can be sped up without sacrificing quality, and "it seems more likely to reach my goals faster ". Meantime, developers can enter a state of a sustained flow. Developers feel being in a state of flow, full of energy and with strong focus. In such a state, they are "unaware of time passing". They can "continue to code without anymore errors for the rest of the day", and "just knock out lines of code all day", with "dancing fingers, my code is like a rainbow ".
Happy developers can also mean more collaborative team members, leading to increased collaboration. As one participant put it, "when I feel good, I speak more with my mate so better communication". Positive feelings could influence the practices that a team uses and promote good manners where team members work with each other, in turn making the interactions among team members enjoyable.
Being more self-disciplined, as indicated by increased process adherence, is also perceived by the participants as a consequence of being happy, as demonstrated by this response: "when I am happy to work, I usually try new things and follow best practices and standards as much as possible". The adherence to process is manifested especially when testing and documentation are concerned: "the better I feel, I'm more likely to produce elegant code, with tests and documentation".
Creative process can also be a positive consequence of developers being happy, as stated in this response: "if [. . . ] I have a general good mood, the software process gets to be creative and very good ".

External Consequences-Artefact-oriented
High code quality is the single most significant consequence of happy feelings while developing software, as perceived by the participants. A participant told a small story about their work: "I was building an interface to make two applicaitons talk. It was an exciting challenge and my happy and positive feelings made me go above and beyond to not only make it functional but I made the UX nice too. I wanted the whole package to look polished and not just functional ". Higher quality of code is generally realized when the mood of developers is positive, because they tend to make less mistakes, see solutions to problems more easily, and make new connections to improve the quality of the code. A participant argued: "When I'm in a good mood and I feel somehow positive, the codes I write seems to be very neat and clean. I mean, I can write codes and analyse problems quickly and with lesser or no unnecessary errors". As a result, the code is cleaner, more readable, better commented and tested, and with less errors and bugs.

Discussion
The main finding of our study is that software developers experience several consequences of unhappiness and happiness, with most of the consequences of unhappiness being external (55%) and most consequences of happiness pertaining to the developer's own being (58%) (internal consequences). We may say that broadly speaking, developers more frequently consider their happiness to benefit themselves, and their unhappiness to be detrimental to others. However, this applies on the most general level of our results, and examining the details reveals several important findings. In this section, we first consider the answers to our research questions, examine the implications of the research questions taken together, discuss the limitations of the study, and provide recommendations for practitioners and researchers.

Addressing the research questions
Consequences of Unhappiness. Our analysis to answer RQ1 resulted in 42 categories of negative consequences that developers experienced to stem from unhappiness. Many of these have a detrimental impact on several important software engineering outcomes. Productivity and performance are the aspects which suffer most from unhappy developers. When grouping codes for low cognitive performance and process-related productivity, approximately 55% of the related in-text references deal with productivity and performance drops. Those results are in line with and support the related work in software engineering research (Graziotin et al., 2015a(Graziotin et al., , 2014bMüller and Fritz, 2015;Khan et al., 2010;Wrobel, 2013) which quantified the relationship or attempted to explain the link.
Slightly more than half of the in-text occurrences (55%) concern external consequences. Most of these relate to the process of developing software. Unhappiness is reported to result in unevenness in the process: low productivity, delays, and broken flow. Unhappiness decreases developers' adherence to the agreed process, resulting in taking process-related shortcuts (i.e., to "cut corners"). These deviations are often mentioned to cause issues in terms of software quality. External consequences were also reported on software artefacts, where, in addition to low code quality, discharging code was mentioned. While a few studies have been conducted on the impact of developers' affect on software quality (e.g, Khan et al. (2010); Destefanis et al.
Slightly less than half of the in-text occurrences (45%) concern consequences for the developer's own being (internal consequences). The most prevalent consequences in this category are related to the cognitive performance of developers. Unhappiness takes its toll in terms of low focus, inadequate performance, reduction of skills, fatigue, and problems with decision-making. Such consequences hit directly at the core of the software development activity, as it is inherently intellectual. The link to the external consequences related to low productivity, decreased process adherence, broken flow, and low quality appears obvious, but would have to be confirmed in further studies.
Our results further show that unhappiness while performing software development may be a source of several mental-related issues that are known to be of detrimental effect to the individual and the work environment. We found situations of mental unease, e.g., low self-esteem, high anxiety, burnout, and stress. Initial software engineering research on the latter two has started (e.g., Mäntylä et al. (2016)), but the related work in psychology is comprehensive and alarming in regards to how disruptive these issues are on well-being. Furthermore, our data has also shown mentions of possible mental disorders such as depression 4 .
Unhappiness appears to also bring down motivation among developers, which is a critical force in software engineering activities (França et al., 2014). Negative experiences and negative affect are also perceived to be causes of work withdrawal. Psychology research has recently started to investigate the role of affect in work withdrawal (e.g., Miner and Glomb (2010)), but we are not aware of related software engineering research. Our analysis shows that developers may distance themselves from the task to which their unhappiness relates, up to the point of quitting jobs.
Among the least mentioned categories, we wish to highlight reduced creativity as a consequence of unhappiness. Creativity has been considered beneficial and even required in software development (see, e.g., Brooks (1975)). Its reduction should be considered problematic in many situations.
Consequences of Happiness. In our analysis for RQ2, we found 32 categories of positive consequences of happiness. Many of these have a positive impact on software engineering outcomes. Higher productivity and performance appear as aspects which benefit most from happiness. Approximately 33% of the related in-text references, categorised into high cognitive performance and process-related productivity, deal with increased productivity and performance. This strengthens the result obtained for RQ1: developers experience happiness as a productivity and performance booster, and unhappiness has the opposite effect.
More than half of the consequences related to developers' experiences of happiness (58%) had to do with the developer's own being. The most prevalent category is high cognitive performance. Happy developers appear to be more focused, have higher performance on problemsolving, higher mental energy, higher skills, and to learn better. Again, given the nature of the software development task, these consequences are very desirable, and can result in positive external outcomes.
Another prevalent category of consequences is high motivation, which participants reported experiencing due to happiness. This suggests that influencing developers' happiness should be considered when the goal is to influence their motivation. A perceived positive atmosphere, with peace of mind and opportunities to enjoy the moment, are factors contingent on the social environment. Fagerholm et al. (2015) has previously linked a positive atmosphere to high performance.
Other positive outcomes reported by our participants include high work engagement and perseverance, higher creativity, higher self-confidence, and being valued and proud.
Less than half of the consequences related to happiness (42%) were external. As with unhappiness, processrelated outcomes were most prevalent. Participants experienced high productivity, expediation, sustained flow, increased collaboration, increased process adherence, and a more creative process to result from happiness. This indicates a more speedy, even process with more social ties to other developers, and a stronger commitment to follow the agreed process, including "doing things right", writing documentation, following best practice, and writing tests.
A smaller but still meaningful portion of the external consequences had to do with the software artefact under development. Here, participants exclusively discussed high code quality as a consequence of happiness.

Comparing Consequences of Unhappiness and Happiness.
When comparing the results for the two research questions, some interesting insights emerge. Many of the consequences have similar prevalence on both the happiness and unhappiness side.
Categories in the developer's own being have similar prevalence across unhappiness and happiness. Both in experienced consequences of unhappiness and happiness, cognitive performance is the most prevalent category, with unhappiness reducing it and happiness increasing it. The structure within those categories is also very similar for both sides, e.g. low focus is first on the unhappiness side, while being more focused is first on the happiness side. Higher problem-solving performance does not have a counterpart on the unhappiness side. This category could be related to being stuck in problem-solving, which we have previously reported as an important cause of unhappiness (Graziotin et al., 2017b).
The second most prevalent consequence of unhappiness is mental unease or disorder, with no direct counterpart on the happiness side. Several other consequences might be construed as mental well-being or positive mental health, but no single consequence can be said to be the mirror category.
Lower motivation is the third most prevalent consequence of unhappiness and its opposite, high motivation, the second most prevalent consequence of happiness. This highlights its importance in developers' experience of consequences of both happiness and unhappiness.
The fourth most prevalent consequence of unhappiness, and the fifth of happiness, are work withdrawal and high work engagement and perseverance. These categories are related to motivation, but the latter is more general.
Higher self-accomplishment has no direct counterpart on the unhappiness side. This category pertains solely to achievement and having reached something. Higher selfconfidence is a related category with no direct counterpart on the unhappiness side. It is less connected to achievement, and although the two may influence each other, they are separate. On the unhappiness side, self-doubt and being cautious are similar categories, but higher selfconfidence is more specific: feeling safe and courageous to engage in new or risky actions.
Among the external categories, the similarities in prevalence is also visible. Both in experienced consequences of unhappiness and happiness, consequences for productivity are the most prevalent within the process category. The process category on both sides have similar frequencies (102 and 104, or 75% and 73% for unhappiness and happiness, respectively) and the top codes have a similar structure. One category on the happiness side without a counterpart on the unhappiness side is increased collaboration. Happiness could lead developers to reach out to others more.
Artefact and working with artefact have similar frequencies on both sides (38 and 35, or 27% and 26%, respectively). On the happiness side, there is only one strong sub-category. Software developers' experiences of consequences of (un)happiness related to the software artefact appears to be largely connected to code quality.
Finally, we observe that only 22% of the respondents in this study are in both the data set for experienced consequences of happiness and unhappiness. This means that the responses on happiness are, to a large extent, distinct from the responses on unhappiness. There may be a tendency among some respondents to recall and report more on happiness, and among others to report more on unhappiness. If this is the case, personality may explain why some respondents would focus more on one or the other. Another possible explanation is respondent fatigue. However, judging from the overall responses, this does not seem to be the case, as most respondents who provided an answer to the first displayed open question also provided one for the second. The content of the answers is the largest determinant for whether a response was coded as expressing a consequence of happiness or unhappiness. We therefore suggest that personality should be taken into account when studying and considering (un)happiness among software developers.

Limitations
We elicited the experienced consequences of unhappiness and happiness of software developers using a survey approach and qualitative data analysis techniques. Whether causality can be inferred from research approaches other than controlled experiments, e.g., eliciting experiences from introspection in the context of qualitative research, is a matter of debate (Creswell, 2009;Djamba and Neuman, 2002;Gläser and Laudel, 2013). However, several authors, e.g., Gläser and Laudel (2013), take the stance that qualitative data analysis can be used to infer causality from the experience of human participants, provided that there is a strong methodology for data gathering and analysis. In our case, we followed Grounded Theory coding methodology (Corbin and Strauss, 2008) in order to strengthen the validity of our results. Furthermore, our research goal was to elicit the consequences of unhappiness as experienced by developers themselves. As the consequences come from first-hand reports, we argue that they accurately represent the respondents' views. Our study does not imply any general relationship between any specific consequences; only experienced consequences of (un)happiness are claimed.
Our sample of software developers using GitHub is limited in size and with respect to representativeness of developers at large. Our dataset (see Section 3.1) contains accounts with public activity during a six-month period. This may result in a bias as developers who prefer not to display their work in public would not be present in the data set; nor would developers whose work is done in companies' internal systems. The six-month time period, however, is less of an issue as very inactive developers are of less interest to our study -but they may differ in terms of how they view consequences of (un)happiness. Replication using different data sources and collection methods is needed to validate our results in these scenarios.
It might be the case that the "GitHub population of developers" is slightly younger than developers in general, but to our knowledge no empirical evidence exists in either direction. GitHub is a reliable source for obtaining software engineering research data, as it allows replication of this study on the same or different populations. The GitHub community is large (30 million visitors per month (Doll, 2015)) and diverse in terms terms of team size, type of software, and several other characteristics. Our sample is similarly diverse and is balanced in terms of demographic characteristics, including participant role, age, experience, work type, company size, and students versus workers. One exception is gender: our sample is strongly biased towards males. The direction of the bias may be the same as in the general population. Unfortunately, it is a known problem that software engineering roles are predominantly filled by males Terrell et al., 2016;Ford et al., 2016), although recent research is attempting to tackle the issue. Data from some sources indicate between 7.6% 6 and 20% 7 females, with numbers possibly depending on the definition of developer and the countries or cultures represented.

Recommendations for Practitioners
We believe that our discovered consequences of happiness and unhappiness of developers should be of interest to practitioners working as managers, team leaders, but also team members and solo software developers. To facilitate such use, we have made the category schemes available as archived open data (Graziotin et al., 2017c). Practitioners in leadership positions should attempt to foster overall happiness of software development teams by limiting their unhappiness and promoting factors that contribute to happy experiential episodes. The benefits of fostering happiness among developers were empirically demonstrated in past research, and they especially highlight software development productivity and software quality boosts. With our results, we add that addressing unhappiness will limit the damage in terms of several factors at the individual, artefact, and process level. We also add that addressing happiness can impact the very core prerequisites for software development: cognitive performance, motivation, and a positive atmosphere at the workplace. We note that previous research (Graziotin et al., 2015a) has suggested that intervening on the affect of developers might have relatively low costs and astonishing benefits.

Implications for Researchers
We believe that the results of the present work could be adopted as the basis of several research directions. Our study has the potential to open up new avenues in software engineering research based on the discovered factors (e.g., work withdrawal and affect of developers). Also, all the factors we have reported are the end part of an experienced causality chain with unhappiness or happiness as the antecedent. Future studies should attempt to seek a quantification of the chain.
We found that broadly speaking, developers more frequently consider their happiness to benefit themselves, and their unhappiness to be detrimental to others. The latter part of this observation was weaker than the former. Future research could attempt to uncover whether this finding holds in other samples of the software developer population, and, if so, investigate whether this is due to a 6 StackOverflow Developer Survey 2017, https://stackoverflow.com/insights/survey/2017 7 Bureau of Labor Statistics Current Population Survey: Annual averages, Software developers, applications and systems software, https://www.bls.gov/cps/cpsaat11.htm bias among developers or if there are different underlying reasons.
Finally, as we have demonstrated, software developers experience a multitude of consequences arising from happiness and unhappiness. The consequences touch upon several issues that are of traditional interest in software engineering research, such as productivity in software processes, process adherence, and software quality. Our work indicates that (un)happiness, and, more generally, affect, should be taken into account in empirical studies investigating developers conducting activities related to such outcomes. This applies on the individual level, but also on aggregated levels of analysis, such as teams and organisations. We argue that ignoring the factors reported in this article can lead to incorrect inferences, or, at the very least, lead to omitting important confounding variables. Considering them could at best lead to novel insights and solution proposals for improving the practice of software engineering, and at least would give a voice to developers volunteering their time as research subjects. We call for software engineering researchers to take (un)happiness into account in their studies.

Conclusion
In this paper, we presented the results of an analysis of the experienced consequences of unhappiness and happiness among software developers while developing software. The complete results are archived and available as open data (Graziotin et al., 2017c). The consequences are grouped into the main categories of internal -developer's own being -and external -process and artefact. The highest impact of both happiness and unhappiness is experienced to be on development productivity and quality as expressed by cognitive performance, including creativity and flow, and process-related performance. We found several instances of job-related adverse effects of unhappiness and even indications of mental disorders: work withdrawal, stress, anxiety, burnout, and depression 4 . We also found instances of effects beneficial to well-being, such as a perceived positive atmosphere at work, higher selfaccomplishment, work engagement, perseverance, creativity, and self-confidence. Overall, our results indicate that developers experience happiness more as benefiting themselves, and unhappiness more as being detrimental to others.
Our recommendation to practitioners, including managers and team leaders, is to utilize our list of consequences and the explanations offered by the present paper to start their quest for enhancing the working conditions of software developers. The consequences, in particular, offer interesting angles which managers should reflect on and look out for in their workforce.
We believe that our study results are of immediate application in future academic work. The results set theoretical foundations for causality studies and inspiration for novel research activities in software engineering. Our own aims for future research include work towards completing the picture of (un)happiness among software developers in terms of causes, links between causes and consequences, and separating positive and negative causes and consequences of both happiness and unhappiness.
The present study enforces the stance that many aspects of software engineering research require approaches from the behavioural and social sciences; we believe there is a need in future academic discussions to reflect on how software engineering research can be characterized in such terms. Developers are prone to share work-related horror stories on a daily basis, and we believe that their job conditions are often overlooked. With our past and present research activities, we hope we can contribute towards higher well-being of software engineers, while enhancing the amount and quality of their job outputs.