Flow Experience in Software Engineering

This is a self-archived version of an original article. This version may differ from the original in pagination and typographic details. Author(s): Title: Year: Version: Copyright: Rights: Rights url: Please cite the original version: CC BY 4.0 https://creativecommons.org/licenses/by/4.0/ Flow Experience in Software Engineering © 2023 the Authors Published version Ritonummi, Saima; Siitonen, Valtteri; Salo, Markus; Pirkkalainen, Henri; Sivunen, Anu Ritonummi, S., Siitonen, V., Salo, M., Pirkkalainen, H., & Sivunen, A. (2023). Flow Experience in Software Engineering. In S. Chandra, K. Blincoe, & P. Tonella (Eds.), ESEC/FSE 2023 : Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (pp. 618-630). ACM. https://doi.org/10.1145/3611643.3616263 2023 Flow Experience in Software Engineering ABSTRACT Soware engineering (SE) requires high analytical skills and creativity, which makes it an excellent context for experiencing flow. Although previous work in the SE context has identified how positive affect and development tools can support the flow experience, there is still much to uncover about the characteristics of soware developers’ flow experiences. To address this gap in knowledge, we conducted a qualitative critical incident technique (CIT) questionnaire (n = 401) on the flow-facilitating factors and characteristics of flow in the SE context. e most important flowfacilitating factors in developers’ work included optimal challenge, high motivation, positive developer experience (DX), and no distractions or interruptions. e flow experiences were characterized by absorption, effortless control, intrinsic reward, and high performance. Our study identifies the features of flow commonly addressed in flow research; however, it also highlights how IT use, especially development tools that provide positive DX, as well as being able to work without excessive distractions and interruptions are important facilitators of developers’ flow. CCS CONCEPTS • Human-centered computing → Human computer interaction → Empirical studies in HCI • Soware and its engineering → Soware creation and management KEYWORDS Soware engineering, soware development, flow experience ACM Reference Format: Saima Ritonummi, Valeri Siitonen, Markus Salo, Henri Pirkkalainen, and Anu Sivunen. 2023. Flow Experience in Soware Engineering. In Proceedings of the 31st ACM Joint European Soware Engineering Conference and Symposium on the Foundations of Soware Engineering (ESEC/FSE ’23) December 3–9, 2023, San Francisco, CA, USA. ACM, New York, NY, USA, 13 pages. hps://doi.org/10.1145/3611643.3616263 1 INTRODUCTION Flow is defined as enjoyment and absorption in an activity that requires high levels of skills, provides increasing levels of challenges, and is intrinsically motivating for an individual. An essential element of flow is an autotelic experience; that is, engaging in an activity that is rewarding in and of itself [1]. As working in software engineering (SE) requires high analytical skills [2], deep involvement in problem-solving [3], and creativity [4], developers’ work can be expected to be a great source of flow. However, the technology-driven nature of the industry also has its unique characteristics, including continuous learning (e.g., updating individual skills to keep pace with constantly evolving tools) [5][6] and the importance of developer experience (DX) of the tools developers work with [4][7], which can affect workrelated flow. Moreover, flow is important for work motivation. Motivated employees are more engaged in their tasks and perform better [8]. Motivated developers have been found to be more productive and remain in the organization, while demotivated software engineers are more likely to have turnover intentions and take sick leave [9]. Because the software industry is a substantial segment of the global economy [10], the motivation and productivity of those working in it impact not only individual well-being but also the performance of the sector. For decades, flow has been a widely researched topic in psychology. More recently, it has been explored in SE. However, more research needs to be conducted in this field. Previous studies of flow in the SE context have examined how emotions can indicate being in flow [11], the barriers to experiencing flow [12][13], and, regarding information technology (IT) use, how DX affects flow (e.g., [7][14]). Scholars have also investigated how flow relates to developers’ productivity [15] and the overall Saima Ritonummi Faculty of Information Technology University of Jyvaskyla Jyvaskyla, Finland [email protected] Valtteri Siitonen Faculty of Information Technology University of Jyvaskyla Jyvaskyla, Finland valtteri.m.e.[email protected] Markus Salo Faculty of Information Technology University of Jyvaskyla Jyvaskyla, Finland [email protected] Henri Pirkkalainen Unit of Information and Knowledge Management Tampere University Tampere, Finland henri.pirkkal[email protected] Anu Sivunen Department of Language and Communication Studies University of Jyvaskyla Jyvaskyla, Finland [email protected] ESEC/FSE ’23, December 3–9, 2023, San Francisco, CA, USA © 2023 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-0327-0/23/12. https://doi.org/10.1145/3611643.3616263 This work is licensed under a Creative Commons Attribution 4.0 International License. 618 ESEC/FSE ’23, December 3–9, 2023, San Francisco, CA, USA S. Ritonummi, V. Siitonen, M. Salo, H. Pirkkalainen, A. Sivunen assessment of their work performance and satisfaction [16]. While some aspects of developers’ work that influence the experience of flow have received attention in recent years, developers’ flow still requires a more holistic examination to gain a deeper understanding of its different dimensions in SE [2][4]. Furthermore, research addressing flow in this field has usually focused on students (e.g., college students participating in programming courses) [2][17] or part-time developers (e.g., scholars) [14], which calls for more studies on professional developers. In addition, although flow has been studied in the human–computer interaction (HCI) context since the 1990s [18][19][20], it can be argued that our understanding of the human-centric aspects of SE (e.g., how developers interact with IT and each other) [21] and of the patterns in employees’ IT use that can facilitate flow [22] has been limited. Therefore, this study aims to comprehend flow in SE and, given the technology-intensive nature of developers’ work, in the context of HCI. We address the abovementioned research gaps by using a qualitative critical incident technique (CIT) approach. We ask the following questions: What are the characteristics of software developers’ flow experiences? How can software developers’ flow experiences be facilitated? We are also interested in which stages of the development process flow experiences occurred in most often and which technologies were involved in these experiences. To answer these questions, this study used a qualitative CIT questionnaire that included open- and closed-ended questions about an outstandingly strong flow experience in the respondent’s work. The CIT is a useful method for collecting detailed descriptions of critical incidents that have significantly influenced an individual’s activities—either positively or negatively [23]. Primary data collection was conducted via Prolific, an online panel that facilitates the collection of high-quality questionnaire responses [24][25]. We obtained 401 responses from individuals working in SE, who described their flow experiences. The findings highlighted that antecedents of flow, especially optimal challenge, and context-specific/situational factors, such as positive DX with integrated development environments (IDEs), help make work smoother and more enjoyable, facilitating flow. This study contributes to research on the human aspects of SE (e.g., [26][27]) and the contextual understanding of flow [28] in SE. To the best of our knowledge, this is among the first empirical attempts to holistically examine flow experiences among professional software developers. The study’s findings increase our knowledge of flow in SE and provide a foundation for further research on the topic. The practical implications for management and developers include the benefits of identifying flow-facilitating practices and tools. Applying these can provide opportunities to experience more frequent flow experiences in SE. Also, more flow can improve developers’ performance, self-actualization [22], work motivation, and work engagement [8]. 2 BACKGROUND AND RELATED WORK In psychology, flow is defined as an optimal experience and a state of enjoyment and deep concentration associated with intrinsically motivated activities [1]. The characteristics of developers’ work (e.g., complex problem-solving that requires a specific set of skills) enable assigning intrinsic rewards to work, which makes software development an excellent flow activity [2]. In this study, flow experiences refer to Csikszentmihalyi’s conceptualization of flow [1][29][30]. Therefore, other concepts often used in the SE context (e.g., control flow and workflow) are not discussed here. These concepts describe processes, whereas flow experience describes an individual’s inner state. 2.1 The Flow Experience The concept of flow originates from positive psychology and studies on autotelic activities [30]. Autotelic activities are enjoyable and intrinsically rewarding—that is, they are rewarding in and of themselves and are not done for extrinsic rewards, such as money. In the literature, flow is often considered as having three conditions under which it can occur: 1) when the perceived challenges presented by the activity correspond to one’s skills, 2) when there are clear proximal goals for what is being done, and 3) when the activity provides immediate feedback about the progress being made. The characteristics of being in flow include deep involvement in the activity (often described as intense and focused concentration), a merging of action and awareness, loss of reflective self-consciousness, a sense of control, an altered sense of time, and autotelic experience [29][30][31]. Together, the conditions and characteristics of flow constitute the dimensions of flow (see Figure 1) [29]. Some researchers have adopted a threedimensional view in which flow is characterized by absorption, enjoyment, and intrinsic interest (e.g., [32][33]). In their review, Norsworthy et al. [28] suggest that most conceptualizations of flow conditions (or flow antecedents) seem to fall under optimal challenge (e.g., clear goals and immediate feedback) and high motivation, while the experiential dimensions of flow fall under absorption (e.g., intense concentration, merging of action and awareness, altered sense of time, and loss of reflective selfconsciousness), effortless control (e.g., sense of control), and intrinsic reward (e.g., autotelic experience). Figure 1: Dimensions of Flow Flow is associated with goal-directed activities that provide increasing challenges [34]. Thus, flow usually occurs when the mind or the body (or both) is stretched to its limits, and something challenging and worthwhile is accomplished as a result [1]. In Conditions of Flow Perceived challenge–skill balance Clear goals Immediate feedback Characteristics of Flow Intense concentration Merging of action & awareness Loss of reflective selfconsciousness Altered sense of time Sense of control Autotelic experience 619 Flow Experience in Software Engineering ESEC/FSE ’23, December 3–9, 2023, San Francisco, CA, USA addition to intrinsic motivation, the motivational aspect of flow is also linked to a sense of achievement [35][36][37] and creativity, as creative thinking typically requires the use of a considerable amount of psychic energy and perseverance (i.e., the ability to discover and formulate new problems) [37]. Although flow is often regarded as a motivational state, there are differences in how different personalities experience situations. Individuals with an autotelic personality are motivated by intrinsic rewards; they are more likely to feel in control of their actions and be motivated in situations that involve high challenges and require a high level of skills (for non-autotelics, these conditions can be demotivating) [1][29][38]. Since software development involves creativity and complex problem-solving [2], many of those working in the field likely have autotelic personalities. This study focuses on the participants’ descriptions of their experiences and the facilitators of their flow. Although flow conditions share commonalities with flow facilitators, they are not entirely synonymous. While the conditions of flow describe the interaction between the individual and the activity, facilitators include other circumstances, such as other people and situational factors, which can be context-specific (e.g., related to one’s job characteristics) [39][40][41][42]. 2.2 Flow and Related Concepts in HCI Intrinsically motivated, goal-directed activities make IT use a great potential source of flow experiences. As is the case with any flow activity, the conditions of flow in the HCI context include tasks that provide enjoyable challenges [43]. Though there are different streams of flow research in this context, one common approach is the association of four dimensions to flow in IT use: control, curiosity, intrinsic interest, and attention [18][19]. These four dimensions have also been conceptualized as technoflow [22]; the last three have been termed cognitive engagement [44]. Similarly, Agarwal and Karahanna [45] introduced the concept of cognitive absorption, a state of deep involvement with software characterized by temporal dissociation, focused immersion, heightened enjoyment, control, and curiosity. The association of positive appraisals with IT use (e.g., being able to work faster or make fewer errors) has been described as techno-eustress [46]. Although they share similarities with flow dimensions, these concepts highlight the interaction between the user and IT. At the same time, as there are multiple streams of flow research in the HCI field, it has been suggested that a unified conceptualization of flow is needed to design better and more engaging artifacts as well as user experiences (UX) [47] that satisfy both functional and hedonic needs (e.g., fun, excitement, immersion, and flow) for interaction [48][49]. One challenge in examining flow in the HCI context has been viewing flow experience and technology as ontologically separate entities, even though the properties of individuals and technology are not separate but entangled (i.e., they both possess relational attributes that shape the activities that the individual and the artifact can perform) [22]. Furthermore, examining the flow enabled by IT use in the work context provides an opportunity to identify patterns in work practices that support employees’ ability to experience flow [8]. Research has identified various outcomes of work-related IT use, including techno-work engagement [50], the positive and negative effects of technology-mediated interruptions [51], the autonomy paradox [52], and either increased or decreased job performance [53]. Although the overall effects of IT use at work seem to be paradoxical [54][55], this study addresses the positive outcomes of IT use for developers, especially how the use of different tools and other work characteristics are related to their flow experiences. 2.3 Flow in SE Flow has received considerable attention in the work context (e.g., [8][32][33]) and the IT work context (e.g., [56]). In contrast, only a few empirical studies have focused on the psychological phenomenon of flow experience [57] in SE (e.g., [58]). There are even fewer studies on professional, full-time developers. Scholars have suggested that developers’ emotions can correlate with their perceived progress in their tasks and indicate whether they are in flow [11][26]. Moreover, feeling creative has been attributed to being more productive and experiencing more flow during the workday [59][60]. Studies of developers’ productivity have found that developers tend to feel productive when they have attainable, clearly defined goals or requirements and the possibility of working without excessive distractions, interruptions, or context switches, which can help reach flow (e.g., [15][61][62][63][64]). In addition to the opportunities to experience flow, there are many flow-inhibiting factors in developers’ work. These include a mismatch between the perceived challenge and skills, working with insufficient requirements (i.e., lack of clear goals), and interruptions [12], especially during immersive tasks [13]. Moreover, having problems with technology is a considerable flow barrier in developers’ work [12]. An example is weaknesses in development tools’ UX, which can be costly for work productivity and even prevent the adoption of tools [4]. However, it has been suggested that development tools that can provide positive DX support flow and intrinsic motivation in developers’ work [65][66]. Much like the concept of UX, DX comprises the cognitive, affective, and intentional aspects of HCI, such as intrinsic motivation and flow [7]. Studies exploring DX have increased our understanding of developers’ interactions with development tools [4], such as IDEs [66]; they have also provided concrete design guidelines for facilitating good DX for these tools (e.g., [7][58]). 3 METHOD Qualitative studies of flow experiences are important for gaining a context-specific understanding of the phenomenon because they allow participants to describe these experiences in their own words [67]. To investigate flow in the context of SE, we used a CIT-based qualitative questionnaire. The CIT is an established qualitative method for collecting self-reports of critical incidents [23][68], such as outstandingly negative or positive experiences. This technique is especially suitable for capturing human behavior in contexts that are episodic in nature (e.g., work tasks) [69]. In addition to being widely used in the work context, this 620 ESEC/FSE ’23, December 3–9, 2023, San Francisco, CA, USA S. Ritonummi, V. Siitonen, M. Salo, H. Pirkkalainen, A. Sivunen method has been utilized in IT use research (e.g., [70][71]) and SE research [72]. CIT studies can be conducted either by making direct observations or by collecting retrospective critical incident reports [69]. Retrospective self-reporting is also common in flow studies (e.g., [8]). Because the flow state is characterized by deep absorption in an activity, retrospection is argued to be the most effective way to access this state [29]. Another important consideration in flow studies is determining which experiences count as flow and which do not. Doing so with predetermined measurements (e.g., the balance between perceived challenge and skills) can be challenging. Hence, one strategy that has been suggested is to provide respondents with a description of flow and ask them whether they have experienced it. If they have, they are asked to describe their experience in detail [34], which is similar to the CIT approach. In this study, we collected retrospective reports of critical incidents (i.e., flow experiences). 3.1 Data Collection We designed a qualitative online questionnaire1 in LimeSurvey to gain context-specific insights into flow experiences in developers’ work. The questionnaire included open- and closed-ended questions based on established phrasings used in CIT research (e.g., [71]) and flow questionnaires (e.g., [8][32]). Initially, we provided a brief definition of flow to ensure that the respondents were familiar with the concept. This paper focuses on the openended questions, in which the participants were asked to recall and describe an outstanding flow experience they had had in as much detail as possible (Q2), the factors that facilitated the flow (Q3), and the technologies involved in the experience (Q1). The questionnaire included other questions not discussed in this study (e.g., queries regarding what prevented the respondent from experiencing more flow in their work). The questionnaire also comprised closed-ended questions designed to collect additional information on the experiences, such as the duration of the experience (Q5), how long ago the experience occurred (Q6), how often the respondent experienced similar flow at work (Q8), and which stage(s) of the development process was the experience related to (Q4). The participants were allowed to choose all applicable stages (planning, development/programming, testing, implementation, and maintenance), in addition to an open field for other stages. It was important to allow this freedom because the stages can vary among different development methodologies (e.g., Agile, DevOps). Furthermore, the closed-ended questions included an assessment of the positive effect of the experience on the respondent’s work (i.e., how critical the incident was perceived to be) (Q7) as well as statements about work-related flow (Q9) based on flow operationalizations in the work context [8][32]. These statements were used in the data analysis phase to help determine whether the experiences described in the responses counted as flow or not [73]. 1 http://r.jyu.fi/writing-task-about-flow. The questionnaire was created in Finnish and translated into English. The translation was proofread by an English language professional to ensure that the central concepts had been accurately translated. Before carrying out the study, the questionnaire was pretested by three developers to make sure that the questions were understandable. The data were collected in two phases between December 2021 and April 2022. The pilot study was conducted by contacting international software companies, and 55 responses were obtained. After the pilot data were found to be of sufficient quality, primary data collection was conducted using the Prolific online panel, a useful service for collecting high-quality data (see e.g., [24][25]). We employed the same questionnaire design in both phases, but to target developers in Prolific, we applied prescreening criteria for people working in software-intensive industries.2 We also added attention check questions, as suggested by the Prolific guidelines, and we only accepted responses from participants with a minimum of 20 previous submissions, with an approval rate of 97% or higher. This resulted in 437 responses, of which 401 were included in the final sample. See Table 1 for demographic information of the sample. Table 1: Final Sample Demographics (n = 401) Gender % Employment Status % Male Female Other Not disclosed 76.6 22.2 1.0 0.2 Full-timer Part-timer Freelancer Other Entrepreneur Not disclosed 77.6 8.7 4.7 4.7 4.0 0.1 Age % Education % ≤ 25 26–35 36–45 ≥ 46 Not disclosed 32.2 41.4 17.0 7.2 2.2 Doctoral degree Master’s degree Bachelor’s degree High school or equivalent Below high school Not disclosed 1.5 31.2 49.6 16.5 0.7 0.5 The weighted average of the respondents’ ages was 31 years. The sample comprised 38 nationalities; the most common were Portuguese (15.2%), Finnish (14.0%), British (9.2%), Polish (8.0%), and Italian (7.5%). The most frequently mentioned job titles were software developer, software engineer, full-stack developer, web developer, front-end developer, and programmer. 3.2 Data Analysis First, we established exclusion criteria for the responses. Following the CIT criteria [69] and suggestions made for research on flow [34][73], we excluded responses that did not describe an outstandingly strong flow experience. This included responses to 2 Software-intensive industries in Prolific include “information services and data processing,” “software,” and “video games.” 621 Flow Experience in Software Engineering ESEC/FSE ’23, December 3–9, 2023, San Francisco, CA, USA the flow statements with an average of < 3.0 (Q9) (i.e., the characteristics of flow were not clearly present [73] in the description of the experience), experiences that did not have a particularly positive or effective outcome (Q7) [69], and respondents who could not declare how long ago the experience occurred (Q6) (i.e., “I don’t know” responses). Participants who failed at least one attention check question or misunderstood the assignment were also excluded. Misunderstanding the assignment included describing a stressful experience or workflow, for example. While being in an intense flow is not always only a positive experience (flow can easily result in strain), the taxing experiences we excluded did not include any element of flow but rather described a particularly demanding experience. Descriptions about workflow depicted what happened in terms of process (e.g., “a continuous flow of tickets to the team”), but they did not describe a flow experience. We also excluded responses from fulltime students whose experiences were unrelated to work. In total, we eliminated 36 questionnaires, which resulted in a final sample of 401. The selected responses were analyzed following the content analysis approach and guidelines by Berg [74]. Content analysis is commonly used in CIT studies because it is useful for identifying, classifying, and categorizing the relevant factors that underlie the phenomenon of interest [23]. We started with open coding, and we labeled the emergent themes in a preliminary manner [75][76] to understand the characteristics of developers’ flow experiences (Q2) and the facilitating factors of those experiences (Q3). Open coding was done primarily by the first author, and the preliminary codes were discussed among all authors. The responses that mentioned similar themes were coded with a descriptive label. Both new themes specific to flow in SE and categories consistent with flow research emerged from the data and the preliminary codes. Context-specific findings revealed in particular the importance of positive DX. The codes consistent with flow research included various dimensions of flow, such as optimal challenge (flow antecedent) and deep absorption in the activity (flow characteristic) (e.g., [1][28][29]). Most responses comprised many themes, and each response was coded with all the themes that were mentioned in it. After coding the data and checking for frequency and patterns [23][74], the preliminary codes and their contents were discussed among all the authors and refined if needed. In establishing the refined codes (i.e., final categories), we maintained the data-driven nature of the findings and referred to flow research when applicable. Flow facilitators were grouped into two main categories—flow antecedents and context-specific and situational facilitators—while flow characteristics were grouped into flow experience dimensions and flow outcomes (although we did not specifically ask about outcomes, many participants described them; one example was being highly productive). In naming the categories that clearly referred to the antecedents, experiential dimensions, or outcomes of flow, we adopted the overarching constructs identified by Norsworthy et al. [28] in their scoping review of flow studies. This categorization helped us to create mutually exclusive categories and avoid possible overlaps between the constructs (e.g., intense concentration and merging of action and awareness), as opposed to using the ninedimensional flow model. Table 2 summarizes the coding process of one respondent’s response. Table 2: Coding Process Transcript Unit (Q2): While developing software for some motors at work, I ended up being very involved, and I really enjoyed coding in what seemed like a similar language to Assembly. During that phase, I was extremely excited to go to work. Flow Experience Characteristics: Preliminary Code Refined Code Main Category Concentration Absorption Flow experience Excitement Intrinsic reward Flow experience Transcript Unit (Q3): The software and programming language combined with a challenge that I knew I was capable of solving. Flow-facilitating Factors: Preliminary Code Refined Code Main Category Challenge–skill balance Optimal challenge Flow antecedent Good DX Positive DX Context-specific facilitator In addition to coding the descriptions with the respondents’ thoughts about the experience, we also looked at the activity being performed when the flow occurred [77] (i.e., the stage[s] of the development process related to the experience) (Q4) and at the technologies and/or software involved in the experience (Q1). 4 RESULTS This study identified the characteristics of developers’ flow and the flow-facilitating factors in their work. First, we briefly examined the circumstances of the experiences, including the development process stage (i.e., the activity) and the technologies involved. As expected, development/programming was mentioned in the majority (83.3%) of the responses of the final sample (N = 401), followed by the rewarding feelings of implementation, testing, debugging, and conducting maintenance activities, such as code refactoring and updating legacy code (see Table 3). Table 3: Flow and the Stages of the Development Process Activity n % Development/programming Implementation Testing Planning Maintenance Other 335 138 116 102 52 7 83.5 34.4 28.9 25.4 13.0 1.7 622 ESEC/FSE ’23, December 3–9, 2023, San Francisco, CA, USA S. Ritonummi, V. Siitonen, M. Salo, H. Pirkkalainen, A. Sivunen Similarly, the technologies mentioned most often included tools used especially during the development stage, such as programming languages (mentioned by 41.9% of the respondents), IDEs (20.9%), frameworks (18.5%), platforms (12.5%), and DevOps tools (9.2%). The tools quoted most often included Visual Studio Code, Python, Java, JavaScript, and React. Hardware, mostly computers, was mentioned by 5.0% of the participants. In contrast, 1.5% stated that their flow was not related to the use of technology but to being able to use their creative and problem-solving skills, for example. Over one-third (37.7%) of the respondents declared that their flow lasted for 1–12 hours, and 7.0% reported 13–24 hours, which means that the experience was over after the workday or within 24 hours. Surprisingly, many participants mentioned even longer flows of 1–7 days (19.5%), 1–4 weeks (14.2%), and even more than one month (15.7%), when they worked on projects that constantly provided opportunities to experience flow. However, the respondents also mentioned shorter micro flows that lasted less than an hour (4.2%). Regarding frequency, the majority reported experiencing flows sometimes (43.0%) or often (30.0%). Experiencing flow very often (12.5%), rarely (12.8%), or very rarely (1.8%) was less common. 4.1 Flow-facilitating Factors in Developers’ Work Flow-facilitating factors were grouped into two main categories, flow antecedents and context-specific and situational facilitators. Flow antecedents included optimal challenge (51.1%) and high motivation (26.9%). Context-specific and situational facilitators included positive DX (31.7%), no distractions or interruptions (13.2%), social support (12.7%), timetables (8.7%), other resources (3.7%), and positive mood and energy level (2.7%). The most significant flow-facilitating factors in developers’ work were optimal challenge, high motivation, positive DX, and no distractions or interruptions (see Table 4). Table 4: Flow-facilitating Factors in Developers’ Work Flow Antecedents n % Optimal challenge - Challenge–skill balance - Clear goals - Immediate feedback 205 51.1 High motivation - Intrinsic motivation - Achievement motive 108 26.9 Context-specific and Situational Facilitators n % Positive DX 127 31.7 No distractions or interruptions 53 13.2 Social support 51 12.7 Timetables - No time pressure - Sense of urgency 35 8.7 Other resources 15 3.7 Positive mood and energy level 11 2.7 The most prominent flow facilitator was optimal challenge, which included, most importantly, appropriate challenge–skill balance. This was characterized by working on a task that offered the right amount of challenge (e.g., a good learning curve) and being able to reach flow because of one’s skills, experience or expertise. The right proportion of challenge, skill, and passion (or excitement) about the topic. I may have challenges that are adequate to my skills, but they mean almost nothing without passion. For me, this is the key that enables a true feeling of flow. (Unity developer) For some, optimal challenge meant very challenging tasks, problem-solving, and even being out of their comfort zone. Further, learning new skills and applying new knowledge (e.g., learning to use a new technology or acquiring skills needed for a task) was viewed as intriguing and flow-inducing. I was developing an AWS-based microservice architecture. It was a new topic for me and required a lot of learning. Still, I experienced strong moments of flow because I felt I had enough time and freedom to implement and explore the technology and its potential. (Senior software engineer) Optimal challenges also included having clear goals and receiving immediate feedback about the progress being made. Although clear goals are important for any flow activity, for developers, this could mean, among other things, working on a project with welldefined requirements. Immediate feedback entailed getting into an efficient loop of positive feedback either with people or the technology and seeing the expected results emerge (i.e., receiving timely feedback). We got into a positive feedback loop with the tweaks we were making, which motivated everyone to stay focused until the end of the workday. People were able to clearly see the impacts of the decisions we made with each deployment. High motivation was also an important flow facilitator for developers. This state was described as feeling motivated, dedicated, or passionate about a topic or having a strong curiosity about a topic. Intrinsic motivation could arise from doing something one enjoyed or felt was meaningful, working on an intriguing task, or being good at something right from the start. Some participants mentioned that they felt intrinsically motivated because they were contributing to a cause (e.g., national security or public health) or simply because they knew they were creating something useful for end-users. I was excited and interested in the subject. I worked furiously because I thought it was the best thing in the world at the time. (Software developer) Achievement motive arose from wanting to reach high-standard results, making an impression, or showing off one’s skills. 623 Flow Experience in Software Engineering ESEC/FSE ’23, December 3–9, 2023, San Francisco, CA, USA It was my first task for that job, and I wanted to impress my boss. Also, I really enjoyed working on the assignment. (Software developer) Although intrinsic motivation suggests that one experiences flow doing an activity they find intrinsically rewarding, intrinsic reward will be discussed in 24.2 as a characteristic of the flow experience (i.e., being in flow), whereas motivation is the reason to engage in the activity. The most important context-specific/situational facilitator in developers’ work was positive DX. This included descriptions of development tools (e.g., IDEs and frameworks) that were easy to use/a joy to use, intuitive, helpful, and powerful, as well as tools that made work easier and/or faster (i.e., more efficient) by offering flexible and customizable features. I knew what I was doing, and everything worked out as I had planned. Unity and Visual Studio worked together as expected, and I felt I really knew how to use these technologies. (Software specialist) It [VS Code] works perfectly every time. It allows me to concentrate on my work and never lets me down. (Front-end developer) It [AWS] is simple, fast, and predictable. Everything worked like a charm. (Developer) In some cases, positive DX was associated with immediate feedback, effortless control, and high performance (e.g., increased productivity) (more about effortless control and high performance in 4.2). Good and correctly configured tools. Short feedback loop (i.e., the effects of the changes made could be quickly verified; a comprehensive test set to ensure that the changes were very unlikely to break any existing functionality). (Senior software developer) The features of the IDE were just what I needed to be able to focus on getting the code out quickly. It didn’t get in the way and only enhanced my productivity. The keyboard shortcuts and all the built-in tools made it an easy one-stop shop for getting all the information I needed to be productive. (Software developer) Another important situational facilitator was no distractions or interruptions, which involved having distraction-free moments for focused work in a calm environment (e.g., a break from meetings, instant messages, or questions from colleagues, or not having too frequent context switches). One way to achieve interruption-free work and mitigate any possible distraction was to isolate oneself by using noise-canceling headphones and/or listening to music. I think that the over-ear noise-canceling headphones and the good playlist enabled the flow experience. Social support was also a facilitator of many respondents’ flow experiences. This entailed working in a supportive team where members were receptive to ideas, helped each other, worked together toward a shared goal, communicated efficiently, and had mutual respect for each other. A few participants mentioned that their flow occurred when they were pair programming. My colleague and I shared the work fairly equally and kept communicating regularly and constantly. We shared ideas and praised each other. The work was fun as it was difficult but rewarding. [Software engineer] Social support also involved receiving encouragement from colleagues and online communities. A sense of pride in having colleagues over your back cheering you on (Senior software specialist) Interestingly, timetables (8.7%) were shown to facilitate flow in two ways. In some circumstances, there was no time pressure, and it was possible to work with reasonable timetables or at one’s own pace with the opportunity to get absorbed into the task (“Do it till it works”). I was working with a colleague, and we were given enough time to be calm and focused and research the work properly. (Developer) In other cases, there was a tight schedule or pressure due to being behind schedule, which created a sense of urgency that enabled the flow experience. My previous experience, the relative mix of easiness and things yet to learn… And I also was being pressured into doing this task quite fast. (Software developer) Interestingly, working without time pressure and a sense of urgency enabled absorption in their own way; no time pressure provided the opportunity to explore and discover, and urgency forced the respondents to focus fully on the pressing issue. Other resources included having the right kinds of tools (e.g., hardware, software, stable connections, and server resources), sufficient human resources, and budget. Positive mood and energy level were perceived as affecting the ability to get into flow. Being in the right kind of mood or having a “good mindset” (i.e., not being anxious or stressed), as well as being well rested, were experienced as helpful in reaching flow. 4.2 Characteristics of Developers’ Flow Based on the responses, we identified the topics that characterized the experiences the most. These were grouped into flow experience and flow outcomes (see Table 5). The dimensions of the flow experience were classified under absorption (38.4%), effortless control (37.9%), and intrinsic reward (33.7%). Many respondents also described high performance (25.9%) as an outcome of their flow. 624 ESEC/FSE ’23, December 3–9, 2023, San Francisco, CA, USA S. Ritonummi, V. Siitonen, M. Salo, H. Pirkkalainen, A. Sivunen Table 5: Characteristics of Developers’ Flow Flow Experience n % Absorption - Intense concentration - Time distortion - Merging of action and awareness 154 38.4 Effortless control - Effortless involvement - Sense of control 152 37.9 Intrinsic reward - Enjoyment - Satisfaction 135 33.7 Flow Outcomes n % High performance - Increased productivity - Increased creativity 104 25.9 Absorption was characterized by intense concentration, time distortion (e.g., losing track of time), and merging of action and awareness. Intense concentration was described as a full focus on the task, immersion or engagement in an activity, and complete absorption leading one not to hear or see anything around them. Many stated that this intensely focused state resulted in not wanting to take breaks and, in some cases, in being able to continue flowing even after a break. Intense concentration was often described as occurring when coding or programming. When I program automatic tests, I am completely absorbed in my work and very focused. I do not take breaks from work when I am thinking about a specific programming problem. (Junior test engineer) Some respondents said that focus was achieved by being in an environment where one could concentrate in peace and quiet (e.g., isolating oneself or listening to music to block out distractions). However, for others, this intense involvement was not seen as entirely positive, as it is possible to get “too absorbed” in programming. Absorption also included descriptions of time distortion, meaning an altered sense of time. This was explained as losing track of time, time flying, days passing fast, and time standing still. I was able to move through the code with speed and finesse, losing track of time. (Senior software engineer) Furthermore, some participants felt a merging of action and awareness in the state of absorption, which was described as forgetting everything around oneself, the environment becoming blurred or disappearing, “everything blending in,” being “in the zone,” or getting lost in coding. An interesting point put forward by one programmer was having no fear of making mistakes along the way as long as there was an interesting task that provided the right amount of challenge: The focus is just at the right level. The time and environment are nicely blurred, and things happen—not necessarily only the right things, but when you have a nice challenge, it doesn’t matter. (Senior game programmer) Developers’ flow was also characterized by effortless control, which included both effortless involvement in the activity and having a sense of control over one’s actions. In some cases, this resulted in having increased willpower to accomplish the goal or feeling proud of being able to solve problems independently: I felt really good when I didn’t have to ask for help and could solve the problems I encountered myself. I like my team members, and there is no shame in asking for help, but I just felt particularly good and was in a flow. (Backend developer) Effortless involvement was described as everything going smoothly, things working out as expected, tasks solving themselves, or “work flowing like water running through a tap.” When you’re in the flow of development, everything works as expected, and all is fine. (Software developer) Interestingly, effortless control was often associated with positive DX. This heightened sense of control over one’s actions and a feeling of effortless involvement in the activity resulted from tools that provide positive DX, which enabled smooth, effortless, and efficient working. The respondents also reported another central aspect of flow, the autotelic experience (i.e., experiencing the activity as intrinsically rewarding). Intrinsic reward entailed enjoyment and satisfaction. Enjoyment was described as having a euphoric experience, a great rush, joy, being excited, having fun, and feeling energetic, among other things. Satisfaction entailed getting a rewarding feeling from certain tasks that induced flow. Many participants disclosed that they loved what they did for a living and could not get enough of coding. I lose track of time, hunger, and thirst, and my focus is completely on the task at hand. I do not think about anything else. This is quite a euphoric experience. It’s one of the best feelings anyone can feel, in my opinion. I can spend hours at a time just lost in the moment. Nothing matters except my creation. I think this feeling is one of the best things about programming. (Unity developer) Things went exceptionally well; I felt motivated and ready for any challenge. I enjoyed my work more than usual, and I was eager to see the finished results. (Fullstack software engineer) Satisfaction could also emerge from doing something because it was helpful in one way or another, such as re-platforming a legacy system, developing something useful for end-users, and working 625