Happiness and the productivity of software engineers

Software companies and startups often follow the idea of flourishing happiness among developers. Perks, playground rooms, free breakfast, remote office options, sports facilities near the companies, company retreats, you name it. The rationale is that happy developers should be more productive and also retained. But is it the case that happy software engineers are more productive? Moreover, are perks the way to go to make developers happy? Are developers happy at all? What are the consequences of unhappiness among software engineers? These questions are important to ask both from the perspective of productivity and from the perspective of sustainable software development and well-being in the workplace. Managers, team leaders, as well as team members should be interested in these concerns. This chapter provides an overview of our studies on the happiness of software developers. You will learn why it is important to make software developers happy, how happy they really are, what makes them unhappy, and what is expected regarding happiness and productivity while developing software.Comment: 12 pages, 2 figures. To appear in Rethinking Productivity in Software Engineering, edited by Caitlin Sadowski and Thomas Zimmermann. arXiv admin note: text overlap with arXiv:1707.0043

Teaching psychology to computing students

The aim of this paper is twofold. The first aim is to discuss some observations gained from teaching Psychology to Computing students, highlighting both the wide range of areas where Psychology is relevant to Computing education and the topics that are relevant at different stages of students’ education. The second aim is to consider findings from research investigating the characteristics of Computing and Psychology students. It is proposed that this information could be considered in the design and use of Psychology materials for Computing students. The format for the paper is as follows. Section one will illustrate the many links between the disciplines of Psychology & Computing; highlighting these links helps to answer the question that many Computing students ask, what can Psychology offer to Computing? Section two will then review some of the ways that I have been involved in teaching Psychology to Computing students, from A/AS level to undergraduate and postgraduate level. Section three will compare the profiles of Computing and Psychology students (e.g. on age, gender and motivation to study), to highlight how an understanding of these factors can be used to adapt Psychology teaching materials for Computing students. The conclusions which cover some practical suggestions are presented in section four

Towards a Theory of Software Development Expertise

Software development includes diverse tasks such as implementing new features, analyzing requirements, and fixing bugs. Being an expert in those tasks requires a certain set of skills, knowledge, and experience. Several studies investigated individual aspects of software development expertise, but what is missing is a comprehensive theory. We present a first conceptual theory of software development expertise that is grounded in data from a mixed-methods survey with 335 software developers and in literature on expertise and expert performance. Our theory currently focuses on programming, but already provides valuable insights for researchers, developers, and employers. The theory describes important properties of software development expertise and which factors foster or hinder its formation, including how developers' performance may decline over time. Moreover, our quantitative results show that developers' expertise self-assessments are context-dependent and that experience is not necessarily related to expertise.Comment: 14 pages, 5 figures, 26th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2018), ACM, 201

Choreographic and Somatic Approaches for the Development of Expressive Robotic Systems

As robotic systems are moved out of factory work cells into human-facing environments questions of choreography become central to their design, placement, and application. With a human viewer or counterpart present, a system will automatically be interpreted within context, style of movement, and form factor by human beings as animate elements of their environment. The interpretation by this human counterpart is critical to the success of the system's integration: knobs on the system need to make sense to a human counterpart; an artificial agent should have a way of notifying a human counterpart of a change in system state, possibly through motion profiles; and the motion of a human counterpart may have important contextual clues for task completion. Thus, professional choreographers, dance practitioners, and movement analysts are critical to research in robotics. They have design methods for movement that align with human audience perception, can identify simplified features of movement for human-robot interaction goals, and have detailed knowledge of the capacity of human movement. This article provides approaches employed by one research lab, specific impacts on technical and artistic projects within, and principles that may guide future such work. The background section reports on choreography, somatic perspectives, improvisation, the Laban/Bartenieff Movement System, and robotics. From this context methods including embodied exercises, writing prompts, and community building activities have been developed to facilitate interdisciplinary research. The results of this work is presented as an overview of a smattering of projects in areas like high-level motion planning, software development for rapid prototyping of movement, artistic output, and user studies that help understand how people interpret movement. Finally, guiding principles for other groups to adopt are posited.Comment: Under review at MDPI Arts Special Issue "The Machine as Artist (for the 21st Century)" http://www.mdpi.com/journal/arts/special_issues/Machine_Artis

Happy software developers solve problems better: psychological measurements in empirical software engineering

For more than 30 years, it has been claimed that a way to improve software developers' productivity and software quality is to focus on people and to provide incentives to make developers satisfied and happy. This claim has rarely been verified in software engineering research, which faces an additional challenge in comparison to more traditional engineering fields: software development is an intellectual activity and is dominated by often-neglected human aspects. Among the skills required for software development, developers must possess high analytical problem-solving skills and creativity for the software construction process. According to psychology research, affects-emotions and moods-deeply influence the cognitive processing abilities and performance of workers, including creativity and analytical problem solving. Nonetheless, little research has investigated the correlation between the affective states, creativity, and analytical problem-solving performance of programmers. This article echoes the call to employ psychological measurements in software engineering research. We report a study with 42 participants to investigate the relationship between the affective states, creativity, and analytical problem-solving skills of software developers. The results offer support for the claim that happy developers are indeed better problem solvers in terms of their analytical abilities. The following contributions are made by this study: (1) providing a better understanding of the impact of affective states on the creativity and analytical problem-solving capacities of developers, (2) introducing and validating psychological measurements, theories, and concepts of affective states, creativity, and analytical-problem-solving skills in empirical software engineering, and (3) raising the need for studying the human factors of software engineering by employing a multidisciplinary viewpoint.Comment: 33 pages, 11 figures, published at Peer