ArticlePDF Available


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.
arXiv:1707.00432v1 [cs.SE] 3 Jul 2017
What happens when software developers are (un)happy
Daniel Graziotina, Fabian Fagerholmb, Xiaofeng Wangc, Pekka Abrahamssond
aInstitute of Software Technology, University of Stuttgart, Germany
bDepartment of Computer Science, University of Helsinki, Finland
cFaculty of Computer Science, Free University of Bozen-Bolzano, Italy
dDepartment of Computer and Information Science (IDI), NTNU, Trondheim, Norway
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.
Keywords: behavioural software engineering, developer experience, human aspects, happiness, affect, emotion
1. 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 stake-
holders involved in software development is an essential
element of company success (Denning, 2012). Recent re-
search within the scope of behavioural software engineer-
ing (Lenberg et al., 2015) has highlighted the relationship
between software developer happiness and work-related
constructs such as performance and productivity (Grazi-
otin et al., 2015a, 2014b,a; Fagerholm et al., 2015; M¨uller
and Fritz, 2015; Ortu et al., 2015), quality (Khan et al.,
2010; Destefanis et al., 2016), 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 sub-
jective, research shows that it can be studied ob jectively.
Objective happiness can be construed as the difference be-
tween experienced positive affect and experienced negative
Email addresses: (Daniel
Graziotin), (Fabian Fagerholm), (Xiaofeng Wang), (Pekka
affect (Diener et al., 1999; Kahneman, 1999). Thus, maxi-
mizing 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 de-
velopers share horror stories about their working experi-
ence (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 re-
sponses among employees (Vecchio, 2000). Further under-
standing 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 devel-
opers. We are conducting a series of studies using a large-
scale quantitative and qualitative survey of software de-
velopers. 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 conse-
quences of (un)happiness, i.e., what software developers
consider to happen when they experience happiness or un-
happiness. We have previously reported on other parts
of the study series, first as a poster-preview of results re-
garding the consequences of unhappiness (Graziotin et al.,
2017d) which preceded a workshop paper on the same sub-
ject (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 unhappi-
ness 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.
2. Background and Related Work
What is happiness, and how can it be assessed? In-
tuitively, 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 hap-
piness and related constructs in the area of software engi-
2.1. 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 – dis-
pleasure) and arousal (sleepy – activated) values” (Rus-
sell, 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 emo-
tions 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 object –
an 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 posi-
tive (negative) affect (Diener et al., 2010).1Frequent pos-
itive (negative) experiential episodes lead to feeling fre-
1Alternative views of happiness exist, e.g. Aristoteles’ eudaimo-
quent positive (negative) affect, leading to happiness (un-
happiness) represented by a positive (negative) affect bal-
ance (Diener et al., 2010). Happy individuals are those
who experience positive affect more often than negative,
and unhappy individuals are those who experience nega-
tive affect more often than positive. In summary, happy in-
dividuals have a positive affect balance and unhappy ones
have a negative affect balance (Lyubomirsky et al., 2005;
Diener et al., 2010).
2.2. Affect and Happiness in Software Engineering Research
A considerable increase in the interest of studying af-
fect and happiness among software developers is visible
over the last five years, although the research is in its in-
fancy; many theoretical and methodological issues remain
in software engineering research, as illustrated by Grazi-
otin et al. (2015c,b) and by Novielli et al. (2015).
Several studies have attempted to elucidate the com-
plex relationship between happiness (and more generally,
affect) and performance in the context of software devel-
opment. In a study of the affect associated with elicit-
ing 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 acti-
vation decreased.
Theory-building is an important part of software engi-
neering research, and theories regarding affect can inform
further empirical studies. One such theory is an explana-
tory 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, com-
munications, and observations of two software developers
in the same project. The concept of attractors – affective
experiences that earn importance and priority to a devel-
oper’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 be-
yond the organisational environment that software devel-
opment 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 prac-
titioners 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 be-
coming and being part of a high-performing team with a
strong identity.
Correlational experiments have found a positive rela-
tionship 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¨uller 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 activa-
tion affect were found to be associated with high debugging
performance (Khan et al., 2010).
Further evidence for the link that developers experi-
ence between emotion and performance is provided in a
survey with 49 developers, assessing emotions they per-
ceived to influence their own productivity (Wrobel, 2013).
Positive affective states were perceived to be those that en-
hance 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 soft-
ware engineering through interviews. 67% of 45 partici-
pants 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 re-
sources, perceived lack of programming experience, inabil-
ity 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 devel-
opers 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 af-
fect, emotions, and politeness, and software quality (Ortu
et al., 2015; Destefanis et al., 2016; M¨antyl¨a et al., 2016).
Happiness in terms of frequent positive affect and positive
emotions was found to be associated with shorter issue fix-
ing 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¨antyl¨a et al.,
2016). Politeness in requests for resolving issues was corre-
lated with shorter resolution time (Destefanis et al., 2016).
Finally, the present article is part of a series of arti-
cles 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 well-
being, 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 feel-
ing inadequate with the task.
In sum, the present state of research shows that happi-
ness and affective experiences play an important role for
software developers, and that they are intertwined with
software development performance and quality. Several re-
lationships between individual affects and outcomes have
been demonstrated. Still, the present research leaves sev-
eral questions unanswered. On one hand, there is insuffi-
cient 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 develop-
ers’ 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.
3. Method
The present study is part of a series of inquiries that
we conducted on the data from a large-scale survey of de-
velopers. 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.
3.1. Sampling Strategy
We consider a software developer to be a person con-
cerned with any aspect of the software construction pro-
cess (including but not limited to research, analysis, de-
sign, 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, follow-
ing 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 cod-
ing 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 occur-
ring 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 ad-
dresses, 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, in-
cluding 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 se-
lected e-mail addresses in the contact set.
3.2. Survey Design
We designed a survey consisting of (1) questions re-
garding 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 open-
ended questions asking for experienced causes and conse-
quences 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 situ-
ation 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 ques-
tions 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., hap-
piness and unhappiness) while developing software.
3.3. Analysis
We qualitatively analysed the cleaned data for the open-
ended questions. We developed a coding strategy, apply-
ing open coding, axial coding, and selective coding as de-
fined by Corbin and Strauss’ Grounded Theory (Corbin
and Strauss, 2008) as follows2. We began by coding conse-
quences 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
2For a review and guidelines of Grounded Theory in software
engineering research, see (Stol et al., 2016)
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 construc-
tion 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 pro-
ceeded to open code them. We finally merged the codes
and conducted a last round of selective coding.
Once we had finished coding consequences of unhappi-
ness, we took the resulting coding scheme, omitting the
detailed leaf categories, and created a “reversed” or “mir-
rored” 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 conse-
quences 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 conse-
quences of happiness. One researcher then selectively re-
coded 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 re-
searcher 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 occurrences3.
The end result is thus two coding schemes that are com-
parable 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 il-
lustrating the coding process of the consequences of unhap-
piness 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 moni-
tored 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 Rand a standard spreadsheet and calcu-
3We note that this final adjustment means that the coding scheme
is slightly different from that reported in Graziotin et al. (2017a); this
is intentional.
Table 1: Examples of reversed categories in coding scheme.
Original category (from consequences of unhappiness) Reversed category (to consequences of happiness)
developer’s own being low cognitive perf ormance 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 arte fact low
code quality
external consequenc es artefact and working with artefact high
code quality
external consequences pro cess low productivity external consequences pro cess high productivity
external consequences pro cess decreased process adherence external consequences pro cess increased process adherence
Table 2: Example of coding phases showing the chain of evidence. The first column contains a response fragment. The next three columns
show how three different researchers open coded the fragment. The fourth column shows how the open codes were merged during the
agreement phase. The remaining columns show the higher-level codes of the axial and selective coding phases.
Response fragment Open coding R1 Open Coding R2 Open Coding R3 Open Coding Merged Axial Coding Selective Coding
I am annoyed when
a coworkers lack of
progress limits my
Team member
not progressing
Waiting for
others to finish
their code
Coordination issue
Bad code written by
Code and
Artefact and
working with
I am angry when
when I work on
code for a long time
and it does not
work. [. . . ]
Eventually I have to
walk away to reflect.
Staying on
current broken
Working for a
long time on
code that does
not work
Unexplained broken
Code and
Artefact and
working with
I am anxious when I
am put in charge of
a broken product
and feel that
restructuring is
required. I have to
justify the ma jor
destruction of
’working’ code.
Handling a
broken project
Feeling that
code must be
restructured Having to justify
Working with
Bad code quality and
coding practices
Mental unease
or disorder
Code and
Artefact and
working with
4. Results
In this section, we summarize the results of our inves-
tigation. 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.
4.1. 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 ques-
tion 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%) partici-
pants were professional software developers, 7% were stu-
dents, and 13% were in other roles (such as manager, CEO,
CTO, and academic researcher). The remaining partici-
pants were unemployed and not students. The participants
declared a mean of 8.22 years (sd = 7.83) of software de-
velopment 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 de-
clared their gender as other / prefer not to disclose. The
mean year of birth was 1985 (sd = 9.67), and the me-
dian was 1987. A wide range of nationalities was repre-
sented, 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 me-
dian of 5 years.
What are the Experienced Consequences of Unhappiness
Among Software Developers While Developing Software?
We identified 250 coded instances related to the nega-
tive 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 di-
vided into an internal category, labelled developer’s own
being (113 references), and the external categories process
(102) and artefact (35).
4.2. 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 with-
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 frus-
trated and sloppy”.
The mental unease or disorder category collects all
those consequences that threaten mental health4. 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 rea-
son 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 de-
pression as feeling depressed, e.g., “feels like a black fog
of depression surrounds you and the project” or “I get de-
pressed ”. In addition, feelings of being judged, frustra-
tion, 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 is also an important consequence of
unhappiness for software developers. Motivation is a set
of psychological processes that cause the mental activa-
tion, direction, and persistence of voluntary actions that
are goal directed (Mitchell, 1982). Motivation has been
the subject of study in software engineering literature (e.g,
Fran¸ca et al. (2014)), and we reported that affective ex-
periences are related to motivation even though they are
not the same construct (Graziotin et al., 2015b). The par-
ticipants were clear in stating that unhappiness leads to
4In this study, we report what the participants stated, but we re-
mind readers that only trained psychologists and psychiatrists should
treat or diagnose mental disorders.
Table 3: Descriptive statistics for the data obtained for each research question. N denotes the size of each data set. Percentages are relative
to the size of the data for each question. The data sets partly overlap; 70 data points (22%) are in both data sets.
Gender Year of birth Role Work experience (years)
RQ N Male Female Other Mean Median Std. dev. Countries Professional Student Unemployed Other Mean Median Std. dev.
1 181 172 (95%) 8 (4%) 1 (1%) 1984 1986 8.27 45 141 (78%) 12 (7%) 5 (3%) 23 (13%) 8.22 5 7.83
2 206 195 (95%) 9 (4%) 2 (1%) 1985 1987 9.67 53 153 (74%) 18 (9%) 2 (1%) 33 (16%) 8.23 5 8.9
Consequences of unhappiness (negative outcome) (250)
developer’s own being (113)
low cognitive performance (35)
low focus (16)
inadequate performance (12)
skills dropped off (3)
fatigue (2)
uncertain decision-making (2)
mental unease or disorder (28)
anxiety (7)
stress (7)
self-doubt (4)
lingering negative feelings (3)
sadness, depression (3)
adverse physical reaction (1)
feel being judged (1)
frustration (1)
unconfident in one’s ability (1)
lower motivation (21)
work withdrawal (18)
not being creative (4)
resentful of being in the situation (2)
being cautious (1)
lower reputation (1)
rushing (1)
undervalued (1)
unhealthy coping behaviour (1)
external consequences (137)
process (102)
low productivity (59)
delay (18)
decreased process adherence (12)
taking short cut (6)
missing documentation (2)
bad management (1)
decreased organization (1)
no methodology (1)
tightened-up communication (1)
unspecified consequence (8)
broken flow (5)
artefact and working with artefact (35)
low code quality (30)
discharging code (5)
Figure 1: Categories for consequences of unhappiness. The numbers indicate the amount of coded instances at each level, including sub-
low motivation for developing software, e.g., “[the unhap-
piness] 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 punish-
ment. [. . . ] ”, 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 tem-
porarily 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
Other consequences perceived by the participants in-
clude not being creative, “it is very difficult for me to do
any creative work when angry or unhappy”, resentful of be-
ing in the situation, being cautious, lower reputation, rush-
ing, 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 conse-
quences further here.
4.3. External Consequences—Process
The category of process collects those unhappiness con-
sequences that are related to a software development pro-
cess, 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 conse-
quences of unhappiness related to performance and produc-
tivity losses5. The codes within this category were ranging
from very simple and clear “productivity drops”, “[nega-
tive 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 ex-
ecuting process activities: In both cases [negative experi-
ences] the emotional toll on me caused delays to the project”.
Unhappiness causes glitches to communication activities
and a disorganized process: Miscommunication and dis-
organization 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
5See (Graziotin et al., 2015a) and (Fagerholm et al., 2015) for our
stance on a definition of productivity and performance in software
reported to lead developers to compromise in terms of ac-
tions, 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 com-
promised (Section 4.4) but also decide to take shortcuts
when enacting a software process, compromising method-
ology, 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 suf-
fer 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 de-
viation 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 chal-
lenge being in balance. Flow has been investigated by
uller and Fritz (2015) in the context of software devel-
opment. 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 qu it and take a break”; the feeling of
getting stuck is persistent.
4.4. External Consequences—Artefact-oriented
The category of artefact-oriented consequences groups
all those consequences that are directly related to a devel-
opment product, e.g., software code, requirements, and to
working with it. As expected by the foci of previous re-
search, the most important consequence of unhappiness of
software developers was low software quality.
Low code quality represents the consequences of un-
happiness of developers that are related to deterioration
of the artefacts’ quality. The participants reported that
eventually [due to negative experiences], code quality can-
not 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 fol low
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 con-
sequences of happiness, They are grouped into 32 cate-
gories 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 un-
happiness consequences, we defined an internal category,
developer’s own being (198 coded instances), and two ex-
ternal categories, process (104) and artefact (38).
4.5. 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 con-
sequences 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 prob-
lems quickly and with lesser or no unnecessary errors when
I’m not thinking of any negative thoughts”; higher men-
tal energy: This influenced my work by making me more
alert, concentrated”; higher skills: . . . felt that my skil l
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 emo-
tional aspects of creativity).
High motivation is an important consequence of hap-
piness 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 hap-
pens I also become a bit suspicious. I felt more motivated
to continue writing code at that point”.
Perceived positive atmosphere is an internal eval-
uation 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 suc-
cessfully. With increased happiness during development,
respondents reported that they felt having performed some-
thing successfully: The sense of accomplishment when fin-
ishing something that actually works is very rewarding ”.
High work engagement and perseverance was re-
ported to occur when respondents were happy. This means,
e.g., pushing forward with tasks: I think I was more mo-
tivated to work harder the next few hours ”.
Higher creativity was also a reported result of hap-
piness. 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 gen-
eral self-confidence as well as task-specific self-confidence
(self-efficacy). Participants expressed a shift in self-confi-
dence when they were happy, e.g.: These situations en-
courage 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 to-
wards 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 neg-
ative issues”.
4.6. External Consequences—Process
Being in a happy mood was often associated by the
participants to several positive consequences closely re-
lated to software development processes. Among different
consequences, high productivity is the most frequently
listed one, followed by expediation,sustained flow,in-
creased collaboration and increased process adher-
ence.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 pro-
ductive 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 wast-
ing 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)
Figure 2: Categories for consequences of happiness. The numbers indicate the amount of coded instances at each level, including sub-categories.
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 con-
sideration invoked by the happy state of mind: I find that
when I feel this way [being happy], I’m actually more pro-
ductive going into the next task and I make better choices
in general for t he 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, devel-
opers 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 enjoy-
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 espe-
cially 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”.
4.7. External Consequences—Artefact-oriented
High code quality is the single most significant con-
sequence 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 prob-
lems 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 er-
rors and bugs.
5. Discussion
The main finding of our study is that software devel-
opers 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, devel-
opers 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 implica-
tions of the research questions taken together, discuss the
limitations of the study, and provide recommendations for
practitioners and researchers.
5.1. Addressing the research questions
Consequences of Unhappiness. Our analysis to answer RQ1
resulted in 42 categories of negative consequences that de-
velopers experienced to stem from unhappiness. Many of
these have a detrimental impact on several important soft-
ware 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 re-
lated in-text references deal with productivity and perfor-
mance drops. Those results are in line with and support
the related work in software engineering research (Grazi-
otin et al., 2015a, 2014b,a; M¨uller and Fritz, 2015; Khan
et al., 2010; Wrobel, 2013) which quantified the relation-
ship 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 develop-
ers’ 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 qual-
ity, 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.
(2016); Ortu et al. (2015, 2016)), we encourage further re-
search on the matter.
Slightly less than half of the in-text occurrences (45%)
concern consequences for the developer’s own being (in-
ternal consequences). The most prevalent consequences in
this category are related to the cognitive performance of de-
velopers. Unhappiness takes its toll in terms of low focus,
inadequate performance, reduction of skills, fatigue, and
problems with decision-making. Such consequences hit di-
rectly at the core of the software development activity, as
it is inherently intellectual. The link to the external con-
sequences 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 per-
forming 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 engineer-
ing research on the latter two has started (e.g., antyl¨a
et al. (2016)), but the related work in psychology is com-
prehensive 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 de-
Unhappiness appears to also bring down motivation
among developers, which is a critical force in software en-
gineering activities (Fran¸ca et al., 2014). Negative experi-
ences 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 de-
velopers 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 high-
light reduced creativity as a consequence of unhappiness.
Creativity has been considered beneficial and even required
in software development (see, e.g., Brooks (1975)). Its re-
duction should be considered problematic in many situa-
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 engi-
neering outcomes. Higher productivity and performance
appear as aspects which benefit most from happiness. Ap-
proximately 33% of the related in-text references, cate-
gorised into high cognitive performance and process-related
productivity, deal with increased productivity and perfor-
mance. This strengthens the result obtained for RQ1: de-
velopers experience happiness as a productivity and perfor-
mance booster, and unhappiness has the opposite effect.
More than half of the consequences related to devel-
opers’ 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 problem-
solving, higher mental energy, higher skills, and to learn
better. Again, given the nature of the software develop-
ment task, these consequences are very desirable, and can
result in positive external outcomes.
Another prevalent category of consequences is high mo-
tivation, which participants reported experiencing due to
happiness. This suggests that influencing developers’ hap-
piness 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
Less than half of the consequences related to happi-
ness (42%) were external. As with unhappiness, process-
related outcomes were most prevalent. Participants ex-
perienced high productivity, expediation, sustained flow,
increased collaboration, increased process adherence, and
a more creative process to result from happiness. This in-
dicates 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 ques-
tions, some interesting insights emerge. Many of the con-
sequences 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 ex-
perienced consequences of unhappiness and happiness, cog-
nitive 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 coun-
terpart 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
Lower motivation is the third most prevalent conse-
quence of unhappiness and its opposite, high motivation,
the second most prevalent consequence of happiness. This
highlights its importance in developers’ experience of con-
sequences 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.
The remaining positions in terms of prevalence are cre-
ativity (fifth, unhappiness, sixth, happiness) being cau-
tious – higher self-confidence (both on seventh place); un-
dervalued (tenth, unhappiness) – being valued (eighth, hap-
piness); unhealthy coping behaviour (eleventh, unhappi-
ness) – healthy coping behaviour (tenth, happiness).
Higher self-accomplishment has no direct counterpart
on the unhappiness side. This category pertains solely to
achievement and having reached something. Higher self-
confidence is a related category with no direct counterpart
on the unhappiness side. It is less connected to achieve-
ment, 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 self-
confidence is more specific: feeling safe and courageous to
engage in new or risky actions.
Among the external categories, the similarities in preva-
lence is also visible. Both in experienced consequences
of unhappiness and happiness, consequences for produc-
tivity are the most prevalent within the process category.
The process category on both sides have similar frequen-
cies (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 collabo-
ration. Happiness could lead developers to reach out to
others more.
Artefact and working with artefact have similar fre-
quencies on both sides (38 and 35, or 27% and 26%, respec-
tively). On the happiness side, there is only one strong
sub-category. Software developers’ experiences of conse-
quences 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 con-
sequences 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 ten-
dency among some respondents to recall and report more
on happiness, and among others to report more on unhap-
piness. 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. How-
ever, judging from the overall responses, this does not seem
to be the case, as most respondents who provided an an-
swer 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 express-
ing a consequence of happiness or unhappiness. We there-
fore suggest that personality should be taken into account
when studying and considering (un)happiness among soft-
ware developers.
5.2. Limitations
We elicited the experienced consequences of unhappi-
ness 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¨aser and Laudel, 2013). However, several authors,
e.g., Gl¨aser and Laudel (2013), take the stance that quali-
tative 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 methodol-
ogy (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 gen-
eral relationship between any specific consequences; only
experienced consequences of (un)happiness are claimed.
Our sample of software developers using GitHub is lim-
ited in size and with respect to representativeness of de-
velopers 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. Replica-
tion 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 ei-
ther direction. GitHub is a reliable source for obtaining
software engineering research data, as it allows replica-
tion 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. Unfortu-
nately, it is a known problem that software engineering
roles are predominantly filled by males (Ortu et al., 2016;
Terrell et al., 2016; Ford et al., 2016), although recent re-
search is attempting to tackle the issue. Data from some
sources indicate between 7.6%6and 20%7females, with
numbers possibly depending on the definition of developer
and the countries or cultures represented.
5.3. Recommendations for Practitioners
We believe that our discovered consequences of happi-
ness 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 hap-
piness of software development teams by limiting their un-
happiness 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 develop-
ment 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, arte-
fact, and process level. We also add that addressing hap-
piness can impact the very core prerequisites for software
development: cognitive performance, motivation, and a
positive atmosphere at the workplace. We note that pre-
vious research (Graziotin et al., 2015a) has suggested that
intervening on the affect of developers might have rela-
tively low costs and astonishing benefits.
5.4. 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 soft-
ware 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 expe-
rienced 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 fre-
quently consider their happiness to benefit themselves, and
their unhappiness to be detrimental to others. The lat-
ter 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
6StackOverflow Developer Survey 2017,
7Bureau of Labor Statistics Current Population Survey: Annual
averages, Software developers, applications and systems software,
bias among developers or if there are different underlying
Finally, as we have demonstrated, software developers
experience a multitude of consequences arising from hap-
piness and unhappiness. The consequences touch upon
several issues that are of traditional interest in software
engineering research, such as productivity in software pro-
cesses, process adherence, and software quality. Our work
indicates that (un)happiness, and, more generally, affect,
should be taken into account in empirical studies inves-
tigating developers conducting activities related to such
outcomes. This applies on the individual level, but also
on aggregated levels of analysis, such as teams and organ-
isations. 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 develop-
ers volunteering their time as research subjects. We call
for software engineering researchers to take (un)happiness
into account in their studies.
6. Conclusion
In this paper, we presented the results of an analysis
of the experienced consequences of unhappiness and hap-
piness among software developers while developing soft-
ware. 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 ex-
perienced to be on development productivity and quality
as expressed by cognitive performance, including creativ-
ity and flow, and process-related performance. We found
several instances of job-related adverse effects of unhappi-
ness and even indications of mental disorders: work with-
drawal, stress, anxiety, burnout, and depression4. We also
found instances of effects beneficial to well-being, such
as a perceived positive atmosphere at work, higher self-
accomplishment, work engagement, perseverance, creativ-
ity, and self-confidence. Overall, our results indicate that
developers experience happiness more as benefiting them-
selves, and unhappiness more as being detrimental to oth-
Our recommendation to practitioners, including man-
agers 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 soft-
ware 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 ap-
plication in future academic work. The results set the-
oretical foundations for causality studies and inspiration
for novel research activities in software engineering. Our
own aims for future research include work towards com-
pleting the picture of (un)happiness among software devel-
opers in terms of causes, links between causes and conse-
quences, and separating positive and negative causes and
consequences of both happiness and unhappiness.
The present study enforces the stance that many as-
pects 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 con-
ditions 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.
The authors would like to thank all those who partici-
pated in this study. Daniel Graziotin has been supported
by the Alexander von Humboldt (AvH) Foundation.
Baas, M., De Dreu, C.K.W., Nijstad, B.A., 2008. A Meta-Analysis of
25 Years of Mood-Creativity Research: Hedonic Tone, Activation,
or Regulatory Focus? Psychological Bulletin 134, 779–806.
Brooks, F.P., 1975. The Mythical Man-Month. Addison-Wesley.
Colomo-Palacios, R., Casado-Lumbreras, C., 2011. Using the Affect
Grid to Measure Emotions in Software Requirements Engineering.
Journal of Universal Computer Science 17, 1281–1298.
Corbin, J.M., Strauss, A.L., 2008. Basics of Qualitative Research:
Techniques and Procedures for Developing Grounded Theory. vol-
ume 2. 3 ed., Sage Publications, London.
Creswell, J.W., 2009. Research design: qualitative, quantitative, and
mixed method approaches. volume 2. 3 ed., Sage Publications,
Thousand Oaks, California.
Csikszentmihalyi, M., 1997. Finding flow: The psychology of en-
gagement with everyday life. volume 30 of Personnel. 1 ed., Basic
Books, New York, New York, USA.
Curtis, B., Krasner, H., Iscoe, N., 1988. A Field Study of the Soft-
ware Design Process for Large Systems. Communications of the
ACM 31, 1268–1287.
Davis, M.A., 2009. Understanding the relationship between mood
and creativity: A meta-analysis. Organizational Behavior and
Human Decision Processes 108, 25–38.
Denning, P.J., 2012. Moods. Communications of the ACM 55, 33.
Destefanis, G., Ortu, M., Counsell, S., Swift, S., Marchesi, M.,
Tonelli, R., 2016. Software development: do good manners mat-
ter? PeerJ Computer Science 2, e73.
Diener, E., Suh, E.M., Lucas, R.E., Smith, H.L., 1999. Subjective
well-being: Three decades of progress. Psychological Bulletin 125,
Diener, E., Wirtz, D., Tov, W., Kim-Prieto, C., Choi, D.w., Oishi, S.,
Biswas-Diener, R., 2010. New Well-being Measures: Short Scales
to Assess Flourishing and Positive and Negative Feelings. Social
Indicators Research 97, 143–156.
Djamba, Y.K., Neuman, W.L., 2002. Social Research Methods: Qual-
itative and Quantitative Approaches. Teaching Sociology 30, 380.
Doll, B., 2015. A closer look at Europe. URL: look-at- europe.
Fagerholm, F., Ikonen, M., Kettunen, P., M¨unch, J., Roto, V., Abra-
hamsson, P., 2015. Performance Alignment Work: How software
developers experience the continuous adaptation of team perfor-
mance in Lean and Agile environments. Information and Software
Technology 64, 132–147.
Fisher, C.D., 2000. Mood and emotions while working: missing
pieces of job satisfaction? Journal of Organizational Behavior 21,
Ford, D., Parnin, C., 2015. Exploring causes of frustration for soft-
ware developers, in: Proceedings of the Eighth International Work-
shop on Cooperative and Human Aspects of Software Engineering,
IEEE Press. pp. 115–116.
Ford, D., Smith, J., Guo, P.J., Parnin, C., 2016. Paradise Unplugged:
Identifying Barriers for Female Participation on Stack Overflow,
in: In Proc. 24th ACM SIGSOFT International Symposium on
Foundations of Software Engineering, ACM, New York, NY, USA.
pp. 846–857. doi:10.1145/2950290.2950331.
Fran¸ca, C., Sharp, H., da Silva, F., 2014. Motivated software engi-
neers are engaged and focused, while satisfied ones are happy, in:
Proceedings of the 8th ACM/IEEE International Symposium on
Empirical Software Engineering and Measurement, ACM Press,
New York, New York, USA. pp. 1–8.
Gl¨aser, J., Laudel, G., 2013. Life With and Without Coding: Two
Methods for Early-Stage Data Analysis in Qualitative Research
Aiming at Causal Explanations. Forum: Qualitative Social Re-
search .
Gousios, G., Storey, M.a., Bacchelli, A., 2016. Work practices and
challenges in pull-based development, in: Proc. 38th International
Conference on Software Engineering - ICSE ’16, pp. 285–296.
Graziotin, D., Fagerholm, F., Wang, X., Abrahamsson, P., 2017a.
Consequences of Unhappiness While Developing Software, in: Pro-
ceedings of the 2nd International Workshop on Emotion Aware-
ness in Software Engineering, IEEE Press, Piscataway, NJ, USA.
pp. 42–47.
Graziotin, D., Fagerholm, F., Wang, X., Abrahamsson, P., 2017b.
On the Unhappiness of Software Developers, in: Proceedings of
the 21st International Conference on Evaluation and Assessment
in Software Engineering, ACM, New York, NY, USA. pp. 324–333.
Graziotin, D., Fagerholm, F., Wang, X., Abrahamsson, P., 2017c.
Online appendix: the happiness of software developers. figshare
Graziotin, D., Fagerholm, F., Wang, X., Abrahamsson, P., 2017d.
Unhappy Developers: Bad for Themselves, Bad for Process, and
Bad for Software Product, in: Proc. 2017 IEEE/ACM 39th Inter-
national Conference on Software Engineering Companion (ICSE-
C), ACM.
Graziotin, D., Wang, X., Abrahamsson, P., 2014a. Do feelings mat-
ter? On the correlation of affects and the self-assessed productiv-
ity in software engineering. Journal of Software: Evolution and
Process 27, 467–487.
Graziotin, D., Wang, X., Abrahamsson, P., 2014b. Happy software
developers solve problems better: psychological measurements in
empirical software engineering. PeerJ 2, e289.
Graziotin, D., Wang, X., Abrahamsson, P., 2014c. Software Devel-
opers, Moods, Emotions, and Performance. IEEE Software 31,
Graziotin, D., Wang, X., Abrahamsson, P., 2015a. How do you feel,
developer? An explanatory theory of the impact of affects on
programming performance. PeerJ Computer Science 1, e18.
Graziotin, D., Wang, X., Abrahamsson, P., 2015b. The Affect of Soft-
ware Developers: Common Misconceptions and Measurements.
Proceedings of the Eighth International Workshop on Coopera-
tive and Human Aspects of Software Engineering , 123–124.
Graziotin, D., Wang, X., Abrahamsson, P., 2015c. Understanding
the affect of developers: theoretical background and guidelines for
psychoempirical software engineering, in: SSE 2015: Proceedings
of the 7th International Workshop on Social Software Engineering,
ACM. pp. 25–32.
Grigorik, I., 2012. GitHub Archive. URL:
Haybron, D.M., 2001. Happiness and Pleasure. Philosophy and
Phenomenological Research 62, 501–528.
Haybron, D.M., 2005. On Being Happy or Unhappy. Philosophy and
Phenomenological Research 71, 287–317.
Kahneman, D., 1999. Objective Happiness, in: Kahneman, D., Di-
ener, E., Schwarz, N. (Eds.), Well-Being: Foundations of Hedonic
Psychology. Utilitas, New York, NY, USA, pp. 3–25.
Khan, I.A., Brinkman, W.P., Hierons, R.M., 2010. Do moods af-
fect programmers’ debug performance? Cognition, Technology &
Work 13, 245–258.
Lenberg, P., Feldt, R., Wallgren, L.G., 2015. Behavioral software
engineering. Journal of Systems and Software 107, 15–37.
Lyubomirsky, S., King, L., Diener, E., 2005. The benefits of frequent
positive affect: does happiness lead to success? Psychological
bulletin 131, 803–855.
antyl¨a, M., Adams, B., Destefanis, G., Graziotin, D., Ortu, M.,
2016. Mining valence, arousal, and dominance: possibilities for
detecting burnout and productivity?, in: MSR ’16: Proceedings
of the 13th International Conference on Mining Software Reposi-
tories, Brunel University. ACM, New York, New York, USA. pp.
Miner, A.G., Glomb, T.M., 2010. State mood, task performance,
and behavior at work: A within-persons approach. Organizational
Behavior and Human Decision Processes 112, 43–57.
Mitchell, T.R., 1982. Motivation: New Directions for Theory, Re-
search, and Practice. The Academy of Management Review 7,
uller, S.C., Fritz, T., 2015. Stuck and Frustrated or in Flow and
Happy: Sensing Developers’ Emotions and Progress, in: Proc.
37th IEEE International Conference on Software Engineering,
IEEE. pp. 688–699.
Novielli, N., Calefato, F., Lanubile, F., 2015. The challenges of senti-
ment detection in the social programmer ecosystem, in: SSE 2015
Proceedings of the 7th International Workshop on Social Software
Engineering, ACM, New York, New York, USA.
Ortu, M., Adams, B., Destefanis, G., Tourani, P., Marchesi, M.,
Tonelli, R., 2015. Are Bullies More Productive? Empirical Study
of Affectiveness vs. Issue Fixing Time, in: 2015 IEEE/ACM
12th Working Conference on Mining Software Repositories (MSR),
IEEE. pp. 303–313.
Ortu, M., Destefanis, G., Counsell, S., Swift, S., Marchesi, M.,
Tonelli, R., 2016. How diverse is your team? Investigating gen-
der and nationality diversity in GitHub teams. Peerj Preprints ,
Russell, J.A., 2003. Core affect and the psychological construction
of emotion. Psychological review 110, 145–172.
Stol, K.J., Ralph, P., Fitzgerald, B., 2016. Grounded Theory in
Software Engineering Research: A Critical Review and Guide-
lines, in: Proceedings of the 38th International Conference on
Software Engineering, ACM, New York, NY, USA. pp. 120–131.
Terrell, J., Kofink, A., Middleton, J., Rainear, C., Murphy-Hill, E.,
Parnin, C., Stallings, J., 2016. Gender differences and bias in
open source: Pull request acceptance of women versus men. Peerj
Preprints , e1733v2.
Vecchio, R.P., 2000. Negative Emotion in the Workplace: Employee
Jealousy and Envy. International Journal of Stress Management
7, 161–179.
Wrobel, M.R., 2013. Emotions in the software development process.
2013 6th International Conference on Human System Interactions
(HSI) , 518–523.
Zelenski, J.M., Murphy, S.A., Jenkins, D.A., 2008. The Happy-
Productive Worker Thesis Revisited. Journal of Happiness Studies
9, 521–537.
... On the other hand, negative emotions (e.g., Frustration) can cause developers to lose motivation and exhibit lower participation, ultimately leading to team attrition [29]. Negative emotions, which are known to impact cognitive processes, could also serve as an obstacle to learning a new programming language, code comprehension, etc. [59]. ...
... Thus, for quite a while, software engineering researchers have studied developer emotions and how they impact software development activities [60,75,79]. The goals of the research have been to empirically understand the causes and the impact of different emotional states on the productivity of an individual developer or a team [28,29,31,50] and to design techniques that automatically detect developer emotion and provide recommendations to developers [11,21,26,35,39,59,70]. Success in achieving these goals is predicated on the ability to detect emotions with high accuracy. ...
Full-text available
Emotions (e.g., Joy, Anger) are prevalent in daily software engineering (SE) activities, and are known to be significant indicators of work productivity (e.g., bug fixing efficiency). Recent studies have shown that directly applying general purpose emotion classification tools to SE corpora is not effective. Even within the SE domain, tool performance degrades significantly when trained on one communication channel and evaluated on another (e.g, StackOverflow vs. GitHub comments). Retraining a tool with channel-specific data takes significant effort since manually annotating large datasets of ground truth data is expensive. In this paper, we address this data scarcity problem by automatically creating new training data using a data augmentation technique. Based on an analysis of the types of errors made by popular SE-specific emotion recognition tools, we specifically target our data augmentation strategy in order to improve the performance of emotion recognition. Our results show an average improvement of 9.3% in micro F1-Score for three existing emotion classification tools (ESEM-E, EMTk, SEntiMoji) when trained with our best augmentation strategy.
... Yet, software developers (and other computer workers) tend to live high-paced work lives and this comes with long-term consequences for their health (Ostberg et al. 2020) and happiness (Graziotin et al. 2018). Sleep deprivation is often worn as a badge of honor (Fucci et al. 2018). ...
... The authors pointed out that specifically introverts may benefit, and the software field is dominated by introverts (Capretz 2003). Graziotin et al. (2018) investigate the happiness of developers and found consequences of unhappiness that are detrimental for developers' mental well-being, the software development process, and the produced artifacts. They use the SPANE instrument (Diener et al. 2009) to measure differences in the perception of positive and negative affect in experiential episodes, which is also used in the study at hand. ...
Full-text available
Context Computer workers in general, and software developers specifically, are under a high amount of stress due to continuous deadlines and, often, over-commitment. Objective This study investigates the effects of a neuroplasticity practice, a specific breathing practice, on the attention awareness, well-being, perceived productivity, and self-efficacy of computer workers. Method The intervention was a 12-week program with a weekly live session that included a talk on a well-being topic and a facilitated group breathing session. During the intervention period, we solicited one daily journal note and one weekly well-being rating. We created a questionnaire mainly from existing, validated scales as entry and exit survey for data points for comparison before and after the intervention. We replicated the intervention in a similarly structured 8-week program. The data was analyzed using Bayesian multi-level models for the quantitative part and thematic analysis for the qualitative part. Results The intervention showed improvements in participants’ experienced inner states despite an ongoing pandemic and intense outer circumstances for most. Over the course of the study, we found an improvement in the participants’ ratings of how often they found themselves in good spirits as well as in a calm and relaxed state. We also aggregate a large number of deep inner reflections and growth processes that may not have surfaced for the participants without deliberate engagement in such a program. Conclusion The data indicates usefulness and effectiveness of an intervention for computer workers in terms of increasing well-being and resilience. Everyone needs a way to deliberately relax, unplug, and recover. A breathing practice is a simple way to do so, and the results call for establishing a larger body of work to make this common practice.
... 44 In Japan and India, it was found that higher levels of teachers' JS were related to better MH (JS→MH). 28,42 Based on the findings from previous research that HW affects JS, [15][16][17]39 and that JS affects MH, 28 suggest that these three variables are correlated. This study seeks to examine the positive effects of HW on MH through the mediation of JS. ...
... The first hypothesis test showed that HW positively and significantly affected teachers' MH, which can be generalized to the entire teacher population in the Special Capital Region of Jakarta province. Thus, improvements that evoke happiness in the workplace (school) will improve teachers' MH. [15][16][17]39 Based on the descriptive statistics from the questionnaire items, the teachers felt enthusiastic when conducting remote teaching activities during the pandemic. This suggests that teachers' happiness is related to their work. ...
Full-text available
Purpose: The role of happiness at work (HW) on mental health (MH) in the education sector in Indonesia has not been widely examined. Additionally, the inconsistent results of previous studies on the relationship between job satisfaction (JS) and MH have led to the uncertainty of JS being a mediator. This study aims to fill the gap in knowledge by examining the effect of HW and perceived organizational support (POS) on teachers' MH, with JS as a mediator. Methods: This research employed a quantitative approach with a cross-sectional study design, using partial least squares structural equation modeling with SmartPLS software. The research participants included 490 teachers in the Special Capital Region of Jakarta province. Results: The results indicate that HW is the highest predictor of teachers' MH, and POS is the highest predictor of JS. Another notable finding is that JS was found to have a positive but not significant effect on teachers' MH. However, it did impact the failure of the mediation relationship of this research model, which did not align with previous studies' findings. Conclusion: Schools must pay attention to HW to improve teachers' MH. Additionally, they should provide support to teachers to increase their JS, especially during the COVID-19 pandemic.
... As developers, we work not only with the artifacts (code, design, test cases, requirements, etc...) we create, but also with artifacts created by other developers across teams. In order to increase comprehension [1], happiness [2] and productivity [3] in dealing with such artifacts, it is important that they are written in a way that is intuitive to produce and consume. In order to better serve developers and related stakeholders, it is crucial to conduct empirical studies in specific contexts, to better understand cause and effect in certain situations and tasks when developers work with artifacts. ...
... The performance on any work task may be affected by motivation, interest, and mood: happy developers are more productive and create better-quality code (Graziotin et al. 2014;2015;Graziotin et al. 2018). Personality also has an effect (Hannay 2011). ...
Full-text available
Understanding program code is a complicated endeavor. As a result, studying code comprehension is also hard. The prevailing approach for such studies is to use controlled experiments, where the difference between treatments sheds light on factors which affect comprehension. But it is hard to conduct controlled experiments with human developers, and we also need to find a way to operationalize what “comprehension” actually means. In addition, myriad different factors can influence the outcome, and seemingly small nuances may be detrimental to the study’s validity. In order to promote the development and use of sound experimental methodology, we discuss both considerations which need to be applied and potential problems that might occur, with regard to the experimental subjects, the code they work on, the tasks they are asked to perform, and the metrics for their performance. A common thread is that decisions that were taken in an effort to avoid one threat to validity may pose a larger threat than the one they removed.
... However, to the best of my knowledge, there are no multidimensional models or theories of well-being that describe and explain what makes software developers flourish in their personal and professional lives. As a consequence, many studies seem to reduce the software developers' well-being to the absence of negative affective states, such as distress and burnout [48][49][50][51][52][53][54][55][56][57], or the presence of positive affective states, such as positive affect, job satisfaction, or intrinsic motivation [58][59][60][61][62][63][64][65]. Despite several recent attempts [35,66], the bias towards unidimensional affective/motivational states is a serious conceptual issue. ...
Full-text available
Context: Organizational studies show that well-being contributes to various work outcomes, including creativity, performance, and productivity. However, the multidimensional well-being of software developers is still an underresearched topic due to the limited focus, demography, methodology, theory, and results of software engineering studies. Objective: This paper encourages more advanced quantitative studies on the well-being of professional software developers by reviewing the present literature on the topic and providing a theoretical model based on the systematically reviewed empirical studies. Method: A systematic literature review was adopted to review 31 quantitative survey studies published between 2000 and 2021, while the analytical part of the grounded theory literature review was used to construct the theoretical model. Results: 10,652 professional software developers from at least 830 companies, 588 teams/projects, and 34 countries constitute the total sample. The studies were mostly published in IT-related journals between 2015 and 2019, mainly by American and German authors. Cross-sectional designs, SEM and regression techniques, and original measures were mostly used to study various constructs and indicators of well-being. The quality is good to very good. Conclusion: The well-being of software developers emerged as a meta-construct of hedonic, eudaimonic, and multidimensional well-being predicted by different individual and organizational factors and impacting the health of software developers and their organizations. The review confirmed the need for more advanced quantitative studies of software developers' well-being.
... Um funcionário comprometido com a organização reduz os níveis de absenteísmo e rotatividade, dado que são menos propensos ao estresse e transtornos mentais que causam os afastamentos do trabalho (GRAZIOTIN et al, 2018). ...
Conference Paper
Full-text available
Introdução/Problematização: As organizações estão percebendo a importância de manter seus funcionários felizes no trabalho, pois assim são mais produtivos e, consequentemente, aumentam a competitividade organizacional. Por um lado, os instrumentos para a mensuração da felicidade no trabalho consistem em ferramentas indispensáveis para a gestão de recursos humanos. Por outro lado, o conceito de Felicidade no Trabalho ainda é recente e indefinido, dificultando, portanto, de se encontrar um instrumento amplamente aceito entre os estudiosos que atenda as necessidades organizacionais, o que freia os avanços desse campo científico. Objetivo/proposta: Apresentar, via revisão sistemática de literatura, o estado da arte sobre os instrumentos de medição do nível de Felicidade no Trabalho, particularmente sobre os instrumentos e escalas de medição adotadas em estudos anteriores. Procedimentos Metodológicos: A revisão sistemática de literatura baseou-se em buscas de artigos que citaram em seu título, resumo e palavras-chave sobre Felicidade no Trabalho, escalas e mensuração. Depois, o conteúdo dos artigos e as obras citadas sobre escalas já existentes e validadas foram analisados minuciosamente. Principais Resultados: Foram encontradas 23 escalas diferentes, das quais apenas duas delas se repetiam em mais de um estudo. Além disso, constatou-se que a grande parte dos pesquisadores utilizam escalas já validadas por outros autores, pois apenas três artigos analisados pretenderam construir instrumentos próprios. Considerações Finais/Conclusão: Ainda não existe um instrumento uniforme e amplamente aceito pela comunidade científica para a medição da Felicidade no Trabalho, haja vista que foram encontrados instrumentos distintos na maioria dos estudos analisados, predominantemente oriundos da Psicologia. Contribuições do Trabalho: Este estudo mostra o estado-da-arte sobre os instrumentos e escalas de medição da Felicidade no Trabalho, cuja ausência de consenso na literatura sobre esses instrumentos e escalas motivem a realização de pesquisas futuras que construam e validem escalas que melhor atendam a mensuração da Felicidade no Trabalho e, consequentemente, sejam amplamente aceitas. Palavras-Chave: Felicidade no Trabalho; Escalas de medição; Revisão Sistemática de Literatura.
Literature is scarce on culture and its impact on the behavioural patterns within software development communities. However, globalization in software development has intensified the need for software development teams to navigate culture issues to ensure the successful implementation of projects. Therefore, the current study examines whether the effects of culture on software developers conform to Hofstede’s individualism cultural dimension. Individualism is studied because of its established negative impacts on teamwork, which is central to software development. Data comprised artefacts from Stack Overflow, a popular online programming community. Developers were from the United States (US), China, and Russia, three countries that differ in terms of their individualistic or collectivistic cultures. Data mining techniques, as well as statistical, linguistic, and content analysis were used to compare the orientation, attitudes, interaction, and knowledge sharing patterns of the three groups of developers. Differences revealed among the three groups were consistent with their cultural backgrounds. US developers, who are from a more individualistic culture, had higher average reputations, used the pronoun “I” more frequently, and were more task-focused. Conversely, Chinese developers, who are from a more collectivistic culture, used the pronouns “we” and “you” more frequently, and were more likely to engage in information exchange. Russian developers had been using Stack Overflow the longest and were the most reflective. The cultural patterns identified in this study have implications for enhancing in-group interactions and team behaviour management during software development, especially when global teams assemble.
This research aims to know if software engineering professionals consider that social and human factors (SHF) influence the productivity of a work team. A survey-based study was conducted among 112 members of software development teams. Empirical results show professionals agree with the SHF in the context of software development influence in the productivity of work teams. It was identified that the 13 SHFs have a weak or moderate correlation with each other. Additionally, the results of the exploratory factorial analysis suggest categorizing the factors into those associated with the individual, those associated with team interaction, and those related to capabilities and experience. This categorization reduced the number of items in the original questionnaire while preserving the variability explained in the latent variables, which will require a shorter response time. Our results broaden the understanding of the SHFs that influence software development team productivity and open up new research opportunities. Measuring the perception of these factors can be used to identify which SHFs should be prioritized in a strategy to improve productivity. In addition, this knowledge can help software organizations appropriately manage their development teams and propose innovative work approaches that have a positive impact on the success of their projects.
Full-text available
The complexity of software projects and inherent customer demands is becoming increasingly challenging for developers and managers. Human factors in the development process are growing in importance. Consequently, understanding team dynamics is a central aspect of steady development planning and execution. Despite the many available management systems and development tools that are being continuously improved to support teams and managers with practical process information, the equally crucial sociological aspects have typically been addressed insufficiently or not at all. In people-focused agile software processes, a first socio-technical understanding can also be promoted by sharing positive and negative development experiences during specific team meetings (e.g., sprint Retrospectives). Nevertheless, there is still a lack of systematically recorded and processed socio-technical information in software projects, making it difficult for subsequent reviews by teams and managers to characterize and understand the sometimes volatile and complex team dynamics during the process. This thesis strives to support teams and managers in understanding and improving awareness of the team dynamics that occur in their agile software projects by introducing computer-aided sprint feedback. The concept builds on four information assets: (1) socio-technical data monitoring, (2) descriptive sprint feedback, (3) predictive sprint feedback, and (4) exploratory sprint planning. These assets unify interdisciplinary fundamentals, practical methods from software engineering, data science, organizational and social psychology. Using a design science research process for information systems, observations in several conducted studies (32 in academic project environments and three in industry) resulted in the foundations and methods for a practical feedback concept on the socio-technical aspects in sprint, prototypically realized for Jira. A practical evaluation involved two industry projects in an action research methodology that helped improve the concept’s usability and utility through practitioner reflections. The collaboration between industry and research resolved practical issues that did not arise during the design science process. Several beneficial outcomes based on the provided sprint feedback are reported and described in this study (e.g., the effect of team structures on development performance). Moreover, the reflections underscored the practical relevance of systematic feedback and the need to better understand human factors in the software development process.
Full-text available
Software forges like GitHub host millions of repositories. Software engineering researchers have been able to take advantage of such a large corpora of potential study subjects with the help of tools like GHTorrent and Boa. However, the simplicity in querying comes with a caveat: there are limited means of separating the signal (e.g. repositories containing engineered software projects) from the noise (e.g. repositories containing home work assignments). The proportion of noise in a random sample of repositories could skew the study and may lead to researchers reaching unrealistic, potentially inaccurate, conclusions. We argue that it is imperative to have the ability to sieve out the noise in such large repository forges. We propose a framework, and present a reference implementation of the framework as a tool called reaper, to enable researchers to select GitHub repositories that contain evidence of an engineered software project. We identify software engineering practices (called dimensions) and propose means for validating their existence in a GitHub repository. We used reaper to measure the dimensions of 1,857,423 GitHub repositories. We then used manually classified data sets of repositories to train classifiers capable of predicting if a given GitHub repository contains an engineered software project. The performance of the classifiers was evaluated using a set of 200 repositories with known ground truth classification. We also compared the performance of the classifiers to other approaches to classification (e.g. number of GitHub Stargazers) and found our classifiers to outperform existing approaches. We found stargazers-based classifier (with 10 as the threshold for number of stargazers) to exhibit high precision (97%) but an inversely proportional recall (32%). On the other hand, our best classifier exhibited a high precision (82%) and a high recall (86%). The stargazer-based criteria offers precision but fails to recall a significant portion of the population.
Conference Paper
Full-text available
The happy-productive worker thesis states that happy workers are more productive. Recent research in software engineering supports the thesis, and the ideal of flourishing happiness among software developers is often expressed among industry practitioners. However, the literature suggests that a cost-effective way to foster happiness and productivity among workers could be to limit unhappiness. Psychological disorders such as job burnout and anxiety could also be reduced by limiting the negative experiences of software developers. Simultaneously, a baseline assessment of (un)happiness and knowledge about how developers experience it are missing. In this paper, we broaden the understanding of unhappiness among software developers in terms of (1) the software developer population distribution of (un)happiness, and (2) the causes of unhappiness while developing software. We conducted a large-scale quantitative and qualitative survey, incorporating a psychometrically validated instrument for measuring (un)happiness, with 2,220 developers, yielding a rich and balanced sample of 1,318 complete responses. Our results indicate that software developers are a slightly happy population, but the need for limiting the unhappiness of developers remains. We also identified 219 factors representing causes of unhappiness while developing software. Our results, which are available as open data, can act as guidelines for practitioners in management positions and developers in general for fostering happiness on the job. We suggest future research in software engineering should consider happiness in studies of human aspects and even in seemingly unrelated technical areas.
Conference Paper
Full-text available
It is no secret that females engage less in programming fields than males. However, in online communities, such as Stack Overflow, this gender gap is even more extreme: only 5.8% of contributors are female. In this paper, we use a mixed-methods approach to identify contribution barriers females face in online communities. Through 22 semi-structured interviews with a spectrum of female users ranging from non-contributors to a top 100 ranked user of all time, we identified 14 barriers preventing them from contributing to Stack Overflow. We then conducted a survey with 1470 female and male developers to confirm which barriers are gender related or general problems for everyone. Females ranked five barriers significantly higher than males. A few of these include doubts in the level of expertise needed to contribute, feeling overwhelmed when competing with a large number of users, and limited awareness of site features. Still, there were other barriers that equally impacted all Stack Overflow users or affected particular groups, such as industry programmers. Finally, we describe several implications that may encourage increased participation in the Stack Overflow community across genders and other demographics.
Full-text available
Building an effective team of developers is a complex task faced by both software companies and open source communities. The problem of forming a " dream " team involves many variables, including consideration of human factors, and it is not a dilemma solvable in a mathematical way. Empirical studies might provide interesting insights to explain which factors need to be taken into account in building a team of developers and which levers act to optimise collaboration and productivity among developers. In this paper, we present the results of an empirical study aimed at investigating the link between team diversity (i.e., gender, nationality) and productivity (issue fixing time). We consider issues solved from the GHTorrent dataset inferring gender and nationality of each team's members. We also evaluate the politeness of all comments involved in issue resolution. Results show that higher gender diversity is linked with a lower team average issue fixing time and that nationality diversity is linked with lower team politeness.
Job satisfaction is often described as an affective response to one's job, but is usually measured largely as a cognitive evaluation of job features. This paper explores several hypothesized relationships between real time affect while working and standard measures of job satisfaction. Experience sampling methodology was used to obtain up to 50 reports of immediate mood and emotions from 121 employed persons over a two week period. As expected, real time affect is related to overall satisfaction but is not identical to satisfaction. Moment to moment affect is more strongly related to a faces measure of satisfaction than to more verbal measures of satisfaction. Positive and negative emotions both make unique contributions to predicting overall satisfaction, and affect accounts for variance in overall satisfaction above and beyond facet satisfactions. Frequency of net positive emotion is a stronger predictor of overall satisfaction than is intensity of positive emotion. It is concluded that affect while working is a missing piece of overall job attitude, as well as a phenomenon worthy of investigation in its own right. Implications for further research and for improving the conceptualization and measurement of job satisfaction are discussed. Copyright © 2000 John Wiley & Sons, Ltd.
At the heart of emotion, mood, and any other emotionally charged event are states experienced as simply feeling good or bad, energized or enervated. These states - called core affect - influence reflexes, perception, cognition, and behavior and are influenced by many causes internal and external, but people have no direct access to these causal connections. Core affect can therefore be experienced as free-floating (mood) or can be attributed to some cause (and thereby begin an emotional episode). These basic processes spawn a broad framework that includes perception of the core-affect-altering properties of stimuli, motives, empathy, emotional meta-experience, and affect versus emotion regulation; it accounts for prototypical emotional episodes, such as fear and anger, as core affect attributed to something plus various nonemotional processes.
Biases against women in the workplace have been documented in a variety of studies. This paper presents a large scale study on gender bias, where we compare acceptance rates of contributions from men versus women in an open source software community. Surprisingly, our results show that women’s contributions tend to be accepted more often than men’s. However, for contributors who are outsiders to a project and their gender is identifiable, men’s acceptance rates are higher. Our results suggest that although women on GitHub may be more competent overall, bias against them exists nonetheless.