key: cord-0103176-d4wrrdjw authors: Russo, Daniel; Hanel, Paul P.H.; Altnickel, Seraphina; Berkel, Niels van title: The Daily Life of Software Engineers during the COVID-19 Pandemic date: 2021-01-12 journal: nan DOI: nan sha: 09d0c2880257bb9b46e13d90cae86cfc33a833ed doc_id: 103176 cord_uid: d4wrrdjw Following the onset of the COVID-19 pandemic and subsequent lockdowns, software engineers' daily life was disrupted and abruptly forced into remote working from home. This change deeply impacted typical working routines, affecting both well-being and productivity. Moreover, this pandemic will have long-lasting effects in the software industry, with several tech companies allowing their employees to work from home indefinitely if they wish to do so. Therefore, it is crucial to analyze and understand how a typical working day looks like when working from home and how individual activities affect software developers' well-being and productivity. We performed a two-wave longitudinal study involving almost 200 globally carefully selected software professionals, inferring daily activities with perceived well-being, productivity, and other relevant psychological and social variables. Results suggest that the time software engineers spent doing specific activities from home was similar when working in the office. However, we also found some significant mean differences. The amount of time developers spent on each activity was unrelated to their well-being, perceived productivity, and other variables. We conclude that working remotely is not per se a challenge for organizations or developers. The SARS-CoV-2 (or COVID-19) pandemic disrupted abruptly software developers working routines in an unprecedented way. Many software developers were asked to switch their typical office-based working habits to a new working from home (WFH) setting on short notice. This has had a considerable negative impact on developers' well-being and productivity [1] . Nonetheless, research has also shown, using multiple-waives designs, that software engineers seem to adapt over time successfully, which has a positive effect on their wellbeing and productivity [2] , [3] , [4] , [5] . This is encouraging, as 89% of professionals would like to work from home at least one day per month after the pandemic [6] . Thus, there is a positive attitude towards remote working in the future. For this reason, major IT companies (e.g., Twitter, Microsoft, AirBnB, Uber, Facebook) informed their employees that they could work from home indefinitely (e.g., Twitter) or extended the remote work policies providing specific support (e.g., AirBnB) [7] . Remote work (or telework), per se is not a new topic in software engineering. With the rise of the internet in the late 90s, scholars started asking themselves about the challenges and opportunities of working from home [8] . Researchers investigated specific software development practices, such as process [9] , [10] or communication [11] . Also, collaboration and characteristics of remote and asynchronous projects have been extensively studied by the Global Software Engineering community [12] , [13] . Such studies typically focus on the interaction of software development teams co-located in different geographical areas. However, the focus has been on software development teams working together on distributed projects. So far, the research on working from home practices has been quite limited. One reason is that managers are quite skeptical about remote working due to worries concerning employees' reduced focus, productivity, company culture, or team cohesiveness [14] . Nevertheless, the pandemic made many of us realize that some fears are unfounded (such as decreasing productivity) and that we have to face such challenges until a sufficient number of people have been vaccinated, a process that might take several years. Hence, anecdotal evidence driving top managerial decisions due to the lack of specific research [15] should be supplemented with scholarly evidence. Thus, we formulate the following research questions: Research Question 1 : How does the distribution of working activities of software engineers WFH during the pandemic compare to a pre-pandemic distribution of their working activities? Research Question 2 : Do well-being, productivity, and other psychological and social variables relate to developers' work activities while working remotely during the pandemic? Thus, in this paper, we explore how software development activities changed during the pandemic using the activity taxonomy of Meyer et al. [16] , and whether specific activities contribute to software engineers' well-being and productivity. For example, there is countless anecdotal evidence that meetings are a waste of time [17] . Does this imply that software developers' perceived productivity is lower when they have more meetings, and are more meetings also associated with lower well-being and more boredom? We further explore which activities are associated with well-being and stress. This research is also relevant because most previous research investigated predictors of well-being and stress in occupational settings [18] , [19] , [20] has not measured the specific activities that might have contributed to higher stress and lower levels of well-being. However, the type of activity someone is doing might contribute to higher stress levels beyond other factors identified by previous research, such as support by coworkers and supervisors [21] . If we were to identify that specific activities are associated with higher or lower levels of stress or well-being, this would provide valuable information for future research investigating predictors of stress. Over a two-week period, we collected twice information regarding developers' activities and self-reported well-being and productivity measures to assess changes along with the lockdown. We compared wave 1 with wave 2 to assess our test-retest reliability and stability of the data along with the pandemic. In particular, we found that the time software engineers spent doing specific activities from home was overall comparable when working in the office. Indeed, the working activities' rank remained almost the same, e.g., coding > emails > codereview > networking. Nevertheless, we also reported some significant mean differences, such a lesser time dedicated to meetings and breaks and more specification and documentation. Furthermore, the amount of time people spent on each activity was not related to their well-being, perceived productivity, and other variables. In the remainder of this paper, we describe the related work in Section II, followed by a discussion about our research design in Section III. The analysis and related results are described in Section IV. Implications and recommendations for software engineers and organizations are then outlined in Section V. Finally, we conclude this study by outlying future research directions in Section VI. Several large software companies, such as Stack Overflow or Red Hat, have embraced working from home by designing ad hoc schemes [22] , [23] . Organizations do so to increase their employees' job satisfaction and productivity while simultaneously reducing their operating expenses, such as office rent [24] , [25] . However, thus far, the software engineering literature did not primarily investigate working from home challenges, with a few exceptions. To find previous work, we looked into peer-reviewed publications in Scopus. We identified six relevant papers. Considering the vast but recent impact of COVID-19, we also selected non-peer-reviewed pre-prints on arXiv (three in total). Table I summarizes prior studies of remote working issues related to software engineers. Our overview highlights how the subject matter arose with more extensive use of the internet (the late 90s), but it was simultaneously a relatively neglected topic until very recently. Indeed, most of the paper has been published in 2019 onward and are dealing with the COVID-19 pandemic. From a methodological perspective, most studies have been field studies involving a single company (e.g., Fujitsu, Baidu, Microsoft) [4] , [2] , [11] . Such real-world investigations aimed to understand the research phenomena by generating research hypotheses. Two studies were conducted in a neutral setting on the opposite spectrum by asking participants a quantifiable judgment and analyzing such data through statistical techniques. These two sample studies generalize their result on the entire software engineering population [1] , [5] . Content wise, half of the papers are concerned with specific topics related to working from home, such as security [8] , [27] , process [9] , work productivity [11] , and inclusion [26] . The other half mostly investigated well-being and productivity while working from home during the pandemic [2] , [1] , [5] and productivity-related to projects' characteristics [4] . It is evident from the few related work that remote working in software engineering is an under-researched topic. Possibly, one reason might be that businesses in the IT sector, allowing software professionals to work from home in a structured way, are relatively few [28] . Most importantly, to this work, no one so far analyzed specific working activities while working from home and how this influences both the perceived productivity and well-being of software engineers. To answer in a reliable and meaningful way our research questions, we employed a post-positivist epistemological stance, using a longitudinal design. Carefully recruited software professionals were asked to complete the same survey twice, two weeks apart from the others. Unique randomized IDs were assigned to participants to preserve their anonymity and track their individual participation across both waves. Before selecting our participants, we ran a power analysis to be sure to detect a small-to-medium effect size of r = .20, using a power of .80 (for a two-sided test) 1 . As a result, we had to recruit at least 190 participants to obtain meaningful results (i.e., with enough statistical power). Participants were selected from a broader set of 500 software engineers who have been carefully selected through a multistage process in a previous study by Russo & Stol [29] . From this pool, we only selected professionals working from home during the pandemic and live in countries with comparable lockdown measures. Finally, we obtained a sample of 192 software engineers who completed the first survey (M age = 36.65 years, SD = 10.77, range = 19-63; 154 men, 38 women), and 184 of those who participated in the second wave. We provide demographic information on participants' gender, educational attainment, and location in Table II . We collected our data between 20-26 April 2020 (wave 1) and between 4-10 May 2020 (wave 2). To ensure high data quality [30] , we recruited participants from the academic data collection platform Prolific Academic and compensated participants above the US minimum wage. The survey was run using Qualtrics. Several of the measurement values are derived from a related project. For a complete presentation of the used instruments, we directly refer to Russo et al. [5] and the Supplementary Well-being and productivity are related, professionals adapt to the condition over time, improving their well-being and productivity, introverts are disproportionally affected by the lockdown, no predictor variable was significantly able to causally explain the variance in well-being and productivity. Field study. Qualitative study interviewing three transgender software engineers to explore the interplay of gender identity and remote work. Working from home enables the empowerment and identity disclosure of software professionals from marginalized communities. James & Griffiths (2014) [27] Experimental simulation. Within an existing project, relevant working from home problems have been identified and addressed by developing and validating a specific solution. Development of a mobile execution environment to support a secure and portable working from home setting. Field study. Report of two qualitative surveys regarding software process improvement related to the distinctive characteristics of teleworking. Development of the Software Process Improvement approach for Teleworking Environment (SPITE) model. Identification of 25 base practices to improve software processes when working from home. Field study. Mixed-methods study at Fujitsu with 44 software engineers to investigate how the use of E-mail influences telework. To test the hypotheses, three hierarchical regression models were used. An effective use of E-mails by remote workers leads to better work distribution and work productivity. Pounder (1998) [8] Formal theory. Essay about security problems linked to telework. This is the first paper that considers "homeworking" as a distinct working setting. It discusses the main security concerns and makes recommendations for organizations. Materials. The longitudinal design also allowed us to compute test-retest reliabilities, r it (i.e., the stability of responses across two or more time-points), by correlating responses given by participants at time 1 with those at time 2 (we are using time and wave interchangeably), which provides additional information about a scale's reliability to the commonly used Cronbach's alpha [31] . Coefficients close to 0 are undesirable since they indicate a low association between the two timepoints, suggesting, among others, poor data quality. Activities. We measured the same 15 activities that were measured by Meyer et al. [16] . We did this because we believe they covered most activities and to have a pre-pandemic comparison group. We asked participants "During the past week, how much time did you spend on each task percentage-wise (%)?" This was followed by the 15 activities (e.g., "Coding", "Email", "Bugfixing") which were rated on a slider-scale ranging from 0% to 100%. For the activities which might have been more ambiguous, a brief explanation was added in brackets such as "Helping (helping, managing or mentoring people)", "Networking (maintaining relationships)". Well-being. We used the Satisfaction with Life Scale [32] . Our Cronbach's alpha 2 values to measure internal consis-tency for both waves were the following α time1 = .90, α time2 = .90 ( r it = .72, p < .001). Productivity. Measuring productivity in software engineering is a highly debated issue. Some scholars, for example, suggest making the measurement more objective by using function points [34] . Ko has criticized this viewpoint as being detrimental in the long run [35] . On the other hand, other researchers propose a self-reflection measure with developers' self-reporting their daily productivity [36] . In this work, we adopted a similar approach. We did not use a standard measure (e.g., such as Ralph et al. [1] did). Productivity was operationalized as a function of time spent working and efficiency per hour, compared to a typical week. The reason for this choice is that we wanted to investigate the variance in productivity while working remotely as compared to being in the office (r it = .50, p < .001). Stress. We used the Perceived Stress Scale [37] ; α 1 = .80, α 2 = .77 (r it = .73, p < .001). Boredom. We used the Boredom Proneness Scale [38] , [39] ; α 1 = .87, α 2 = .87, (r it = .69, p < .001). Autonomy, competence, and relatedness. To measure the three needs of the self-determination theory [40] , we used the psychological needs scale [41] . Need for autonomy's Cronbach's alpha level were: α 1 = .72, α 2 = .76 (r it = .76, p < .001); for Competence: α 1 = .77, α 2 = .65 (r it = .76, p < .001); and for Relatedness: α 1 = .79, α 2 = .78 (r it = .71, p < .001). Quality and quantity of communication with colleagues and line managers. We used a self-developed three items instrument (α 1 = .88, α 2 = .92; r it = .67, p < .001). Daily Routines. We developed a five items scale (α 1 = .75, α 2 = .78; r it = .73, p < .001). Distractions at home. We developed a two items scale (α 1 = .64, α 2 = .63; r it = .63, p < .001). To test whether software developers' activities have changed during the pandemic, we first compared the time participants reported to have spent on each of the 15 activities with those reported by Meyer et al. [16] (first research question). The results are displayed in Figure 1 , as well as Tables III and IV. To test whether participants in our sample reported spending more or less of their time on certain activities than the software developers surveyed by Meyer et al. [16] , we performed a series of one-sample t-tests. For example, we compared the percentages of participants in our sample at time 1 spend coding was significantly different from 15%, which is the percentage reported by Meyer et al. (see Table III , second column). We performed 15 (activities) × 2 (time points) = 30 t-tests (two-tailed, since we did not have directed hypotheses) 3 . Software engineers in our sample reported on average to have spent less time bugfixing, in meetings, getting interrupted (only at time 2), helping (only at time 2), and taking breaks; but more time on testing, specification, writing documentation, networking (only at time 1), learning, and administrative tasks compared to the participants surveyed by Meyer et al. (Table III) . However, the differences between what our participants and those of Meyer et al. reported differed by only a few percent (see Figure 1 ). This visual inspection of the data is confirmed by correlation analysis. The 15 activities 4 expressing percentages reported by Meyer et al. correlated with r(13) = .84, p < .0001 at time 1 and with r(13) = .83, p = .0001 at time 2. To obtain those correlations, we correlated the mean percentages reported in columns 2-4 of Table III with each other. That is, we tested whether the average percentages spent on each activity reported by the participants in the Meyer et al. sample would align with those reported by the participants in our sample at wave 1 and 2. This suggests that while there are some deviations, the overall order of tasks remains stable. It further supports the quality of our data. If our participants had responded carelessly or even randomly, those two correlation coefficients would be around 0. In a next step, we explored whether participants' activities changed over time. To do this, we performed a series of paired t-tests (Table IV) . The only statistically significant differences were observed for networking and taking breaks. At time 2, participants spent less time networking and taking breaks compared to time 1. Overall, the relative order of the activities remained very stable across time on the group level (i.e., when correlating the group averages of time 1 and 2), r(13) = .99, p < .0001. To test the second research question, we correlated the time participants spent on each activity with the selected variables. This was possible because the activities were mostly uncorrelated in both time points on an individual level. We report Pearson's correlation (r) in our tables since most of the distributions were normally distributed. However, for the sake of completeness, we also ran a non-parametric Spearman's rank correlations test (reported in the Supplementary Material), 3 Because of the large number of comparisons, we adjusted the α-threshold from .05 to .003 to reduce the risk of false-positive results. This means that we considered only p-values of < .003 as statistically significant. This is a standard procedure for studies that involve many variables to ensure reliable results, e.g., [42] . Note that changing the α-threshold impacts the test statistic (e.g., t−value), as the test statistic and p-value are perfectly associated with any given sample size [43] . For example, for an α−threshold of .003 and a sample size of 192 (time 1) or 184 (time 2), the critical t-values are 3.006 and 3.008. In other words, only if the t−value obtained from a t−test is larger than 3.006 (or 3.008), the p-value would be < .003, and we would consider the test result to be statistically significant. Note that a Bonferroni-correction would have resulted in an adjusted alpha-level of .05/30 ≈ .0017, which is overly conservative and does not consider that some of the variables are correlated (e.g., between time 1 and 2). Thus, the adjusted significance threshold of .003 seemed appropriate to us, neither overly conservative nor liberal. 4 For the correlations, the Degrees of Freedom are N − 2 = 13 with N = 15 activities. Note. Activity percentages as per 'typical workday' following Meyer et al. [16] . M t1 : mean at time 1 (see also Table V and Table VI . This analysis did not show substantially significant results. At time 1, only productivity was negatively correlated with time spent on breaks, r = −.30, p = .00002, which can be more considered to validate further our productivity measure rather than a meaningful finding itself. At time 2, none of the correlations was significant at α =.0005. The correlation between productivity and time spent on breaks was again negative but did not reach statistical significance, r = −.16, p = .03. Overall, we conclude that work activities carried out at home are not related to the identified variables. Working from home (WFH) has thus far been poorly considered by the software engineering literature as a contingent research topic. Our investigation addresses the need to provide scholarly evidence concerning how working from home during the COVID-19 pandemic affected software developers' working activities. Further, a deeper understanding of the emergent phenomenon's professional effects for a large number of software professionals working remotely provides relevant insights for both research and practice. To this end, this study makes several contributions. First, we ran a longitudinal analysis of 192 carefully selected software professionals during the COVID-19 lockdown. We assessed developers' working activities and their perceived well-being, productivity, and other relevant psychological and social variables. Our data quality was assured by the testretest reliability of each variable measuring at least .50, and Cronbach's alpha above .60. Second, we compared the time spent on typical office-based working activities with the same activities while working from home. Using the taxonomy and previously collected data of Meyer et al. [16] , we ran 30 onesample t-tests to assess significant differences. Although we reported some differences, they are relatively small, which indicates that the time spent on different activities is almost identical in both working environments. Third, we analyzed whether the time spent on each working activity changed during the pandemic. After performing 15 paired t-tests, we conclude that developers spent their time consistently while working from home. Fourth, we investigated the influence each identified variable had on the working activities, and if such an outcome is stable over time. To do so, we ran 195 correlation analysis. Our results suggest that the measured variables and activities are not correlated. Fifth, we outline practical, evidence-based implications, as summarized in Table VII . On the whole, we did not register significant changes regarding developers' work distribution. Further, we highlight that Meyer et al. 's sample refers only to one software company, whereas we surveyed developers across many companies, globally distributed. Thus, some deviations were expected. Nevertheless, we still report an overall consistency between our WFH data and Meyers et al.'s analysis of a typical office day at Microsoft. Our results, therefore, show that working from home does not affect how software engineers dedicate their time to specific tasks. On a precautionary note, the reader should be aware that we did not monitor developers' effectiveness by executing every task while working remotely. We opted for this choice to be consistent with Meyer et al., and because we collected data from a global sample of software professionals working in 190+ different organizations, making the development of objectively comparable measurements near impossible. Still, we report some differences with the data collected by Meyer et al., although the difference is of only some percentage points. Most notably, software engineers spend less time in bugfixing, meetings, and breaks. Also, they report fewer interruptions and less time on e-mail writing when working from home (although this is the case in only one of the two waves). Contrary, they spend more time on specifications, testing, administration, documentation, and learning. From these results, we notice that meetings are significantly reduced while working remotely, meaning that they are, on average shorter and more time-efficient than in the office. Also, participants invested in improving their skillset, spending more time on learning. Similarly, developers seem to be more focused on their tasks, considering fewer reported breaks and interruptions. However, this does not mean that they are not linked to their organization or their colleagues, since the time spent on networking remained the same. This cautiously suggests that WFH might be more beneficial for both developers and organizations than working in the office, or at least for some group of professionals [26] . Another limitation is that we only measured the time participants spent on each of the 15 activities using percentages rather than absolute time (e.g., in minutes). This implies that the comparisons we made between wave 1 and 2 as well as the sample from Meyer et al. [16] are in relative terms but not absolute terms. For example, while participants in our sample reported to have spent only 8.45% (wave 1) and 9.74% (wave 2) of their time in meetings, and Meyer et al.'s participants reported to had spent 15%, participants in our sample might have worked more and spent in absolute terms the same amount of time in meetings. During the pandemic, we did not register any significant change in the work activities, with only two exceptions: at the first wave, developers spent more time for breaks and networking than the second wave. Nevertheless, we report a correlation close to 1 of the group averages, suggesting a very high consistency of the activity distribution along with the pandemic. The reason software engineers spent less time on breaks and networking during the second measurement point might indicate that they became more used to their new WFH condition. Accordingly, professionals learned to spend their working time more efficiently. Unfortunately, we did not collect any additional data that might support this point. However, similar conclusions are supported by the literature [2] , [5] . Finally, we did not find any significant results from our extensive correlation analysis between working activities and potentially relevant variables (with one exception). This is a generally positive finding, as it shows that important psychological and social variables have no direct influence on developers' working tasks while working remotely. The only significant relation was productivity, which correlated negatively with breaks in wave 1. Despite being intuitive, we are very cautious about concluding that developers should take fewer breaks to be more productive since such a relation was not significant at wave 2 (although still negative). Regarding the other activities, we conclude that the time spend on each task does not affect productivity. Similar considerations can be made with well-being. We did not register any significant effect on how the amount of time dedicated to development activities impacts software engineers' well-being working from home. We consider this evidence supportive of an extensive working from home setting since developers' wellbeing and productivity are not related to individual working tasks, meaning that organizations can plan working schedules as remote workers would still work from the office. Furthermore, the stress in particular, which is an indicator of burnout [21] , seems not to relate with any particular activity, meaning that none of the performed work tasks are per se associated with stress. This is reassuring as it suggests that no activity causes stress, burnout, or lower well-being levels. We can draw similar conclusions for the other identified variables. None of the working activities were related to boredom. This means that while working remotely, developers did not felt any specific task as dull and demotivating. Previous studies showed that during the pandemic, it is essential to have daily routines to improve personal well-being [5] . However, when it comes to individual activities, routines seem not to play a significant role. Regardless of how software engineers organize their day, this does not affect the amount of time they dedicate to one activity or another. Likewise, possible distractions that might happen while working from home (e.g., children at home) does not influence the time spent on work activities. This is also a very relevant result, as the literature suggests that distractions play a significant role when working remotely [1] . Although we do not contradict the conclusion of Ralph et al., we do report that distractions per se are not related to developers' working tasks. Self determination theory measures innate psychological needs [40] , and its three dimensions need for autonomy, competence, and relatedness are associated with work motivation in general [44] . To the best of our knowledge, this study is the first in our community to assess whether specific activities are correlated with autonomy, competence, and relatedness. We found overall that psychological needs were unrelated to people's specific activities. This means that developers were not generally unmotivated (or motivated) with the time spent on the working tasks performed remotely. While working remotely, quality of communication can be challenging, as face-to-face communication has to pass through a medium (e.g., MS Teams, Zoom). Not being directly connected to the organizations can, therefore, become a big issue for remote workers. For example, research suggests that lower support from coworkers and supervisors [20] , perceiving the values of one's organization to be different to one's values [19] , and unfair treatment and lack of appreciation [18] are putting the mental health of remote workers at risk. Interestingly, our results suggest that the quality of communication does not relate to individual working activities. This can also be considered a positive finding, as the time spent by software engineers for each task is not detrimental to the relations with their organization. Prior research has mostly ignored whether activity type plays a role in professionals' psychological and social factors. Typically, scholars only measured whether people are, e.g., stressed overall, as opposed to stressed by specific activities [18] , [19] , [20] . Our research suggests that the type of activity is not a confounding variable, which increases our trust in prior research, which has typically looked at subjective work experience in general rather than actual activities. To conclude, our findings imply that software engineers' psychological and social factors do not matter on what work activity they are performing, but rather how it is done. To conclude this section, we briefly address the most relevant limitations. Reliability. We investigated our subject matter through a two-wave longitudinal study. Notably, over 90% of our initial informants also took part in the second wave. Participants were identified using a multi-stage selection process to ensure (i) they are professionally active software engineers, (ii) data quality, and (iii) that they were working from home during the lockdown. Construct validity. To enhance reproducibility, we used the taxonomy by Meyer et al. [16] to define the daily activities of software developers. Similarly, we used those benchmarks to confront it with working from home setting. Also, we report the Cronbach's alpha across both waves of ten identified variables, as well as their test-retest reliability. Conclusion validity. Our conclusions rely on multiple statistical analyses, such as one-sample t-tests, paired t-tests, and Pearson's correlation. Furthermore, we also ran a nonparametric Spearman's rank correlations test for our conclusion's consistency since not all distributions were perfectly normally distributed. To support Open Science, we made the replication package in R and our raw data and openly available on Zenodo. Internal validity. For this investigation, we used self-reported measures for well-being, productivity, and other psychological and social variables, which might be considered a limitation. However, similar to Meyer et al., our primary focus was to understand the developers' perspective of what makes "a good day" and how individual tasks influence both well-being and productivity while working from home. The research was Working activity distribution WFH compared to a typical office day. Overall, the ranking among work activities remains unchanged. However, when WFH developers spend less time in: Bugfixing (t 1 = −5.31, t 2 = −3.55), Meetings (t 1 = −9.95, t 2 = −6.63), Breaks (t 1 = −7.39, t 2 = −14. WFH does not affect the time spent on working tasks by software developers and the distribution is comparable to a typical office day. The significant time reduction of meetings suggest that online-meetings are more time-efficient than physical ones. Also, professionals seems to be more focused when working remotely, having fewer interruptions. This allows them, among others, to dedicate more time in developing their own skills. Working activity distribution during the pandemic. Very high correlation of the group averages of time 1 and 2: r(13) = .99, p < .0001. Two exceptions were more Breaks (t = 4.71) and Networking (t = 4.33) at time 1 compared to time 2. Developers had a very regular work activity distribution during the pandemic, which was comparable to their office day. Fewer breaks and networking might depend that professionals adapted to the new situations towards the end of the lockdown, being more time-efficient. Effects of well-being and productivity on working activities while working from home. Only the relation between Productivity and Breaks was significant at time 1 (r 1 = −.30, p 1 = .00002); at time 2 the correlation was again negative but not statistical significant (r 2 = −.16, p 2 = .03). The time spent by software engineers on individual tasks while working from home does not affect their productivity or well-being. In the case of WFH, organizations can plan work activities as they have done so far. Influence of psychological and social variables on working activities while working remotely. No significant correlations between any activity and variable (r < .25, p > .0005). We could not associate any indicator of burnout, motivation, disengagement, relation to the organization, and selforganization with the activities performed while working from home. This suggests that WFH is per se, not a burden for developers. performed towards the end of the worldwide lockdown in spring 2020. This enabled our participants to report a more mature and stable assessment of the new working setting. We only considered countries with comparable lockdown measures (e.g., we excluded, among others, Denmark, Germany, and Sweden as these countries did not face a total lockdown or had different measures in place in the country's regions). Thus, we asked both waves about lockdown conditions in their home country and if they were still working from home. Since all selected informants faced comparable conditions, we did not exclude any of the 192 selected software professionals. External validity. We designed this study to maximize internal validity. Therefore, we determined our sample size with an a priori power analysis. So, we did not work with a representative sample of the software engineering population in mind (such as Russo and Stol [29] did, where the research goal was the generalization of results, surveying over 400 software engineers). However, we recognize having submitted our surveys in the middle of a very peculiar period. This limits the extent to which we can generalize our findings in a nonpandemic working from home setting. Notwithstanding, we also realize that we require fast and reliable evidence regarding the COVID-19 crisis we are facing right now, improving the quality of developers' daily lives. This study will also enable a better-informed research design for future remote working studies once this pandemic is over. This research focused on software engineers' work distributions during enforced WFH and the association between single tasks with well-being, productivity, and other social and psychological variables. To do so, we employed a longitudinal study design across two waves. We found that developers still spend proportionally the same amount of time on their different daily activities. For example, the software engineers in our sample still spent most of their working time on coding, bugfixing, meetings, testing, and e-mails, as previously reported by Meyer et al. [16] . Nevertheless, we found some significant mean differences. Our participants reported having spent less time in meetings and breaks, suggesting that both were less common, possibly due to developers' adaption of working remotely. Similarly, no significant relations have been found between productivity, well-being, and relevant social and psychological variables with working activities. Based on our findings, our research suggests that WFH does not per se presents a challenge for either organizations or developers. Future research will focus on exploring moderation effects by investigating whether perceived effectiveness, independence, and meaningfulness of a task moderate the relation between each work activity with well-being and productivity and other relevant variables. Further, more tailored recommendations based on developers' persona would provide a more nuanced understanding of the subject matter since we only considered average effects in this study. The full replication package and additional Tables are openly available under CC BY 4.0 license on Zenodo, DOI: https: //doi.org/10.5281/zenodo.4104390. Pandemic programming: How COVID-19 affects software developers and how their organizations can help A tale of two cities: Software developers working from home during the COVID-19 pandemic Octoverse spotlight: An analysis of developer productivity, work cadence, and collaboration in the early days of COVID-19 at GitHub How does working from home affect developer productivity?-a case study of baidu during COVID-19 pandemic Predictors of well-being and productivity among software professionals during the COVID-19 pandemic-a longitudinal study New Zealanders' attitudes towards working from home 19 Major companies that have announced employees can work remotely long-term Homeworking: No longer an easy option? Special requirements for software process improvement applied in teleworking environments Remote working and collaboration in agile teams Understanding relationships among teleworkers'e-mail usage, E-Mail richness perceptions, and E-Mail productivity perceptions under a software engineering environment Global software engineering: The future of sociotechnical coordination Empirical evidence in global software engineering: a systematic review The 2020 state of remote work 4 actions to be a strong leader during COVID-19 disruption Today was a good day: The daily life of software developers Why most 1:1 meetings are a waste of time, and what to do instead Perceptions of work stress causes and effective interventions in employees working in public, private and non-governmental organisations: a qualitative study The value of value congruence Hardiness and support at work as predictors of work stress and job satisfaction Prediction of life stress on athletes' burnout: the dual role of perceived stress What it means to be a remote-first company: Stack overflow Red hat named a top 100 company for remote jobs by flexjobs Assessing the growth of remote working and its consequences for effort, well-being and work-life balance Benefits and barriers of telework: perception differences of human resources managers according to company's operations strategy How remote work can foster a more inclusive environment for transgender developers A secure portable execution environment to support teleworking 100 top companies with remote jobs in 2015 Gender differences in personality traits of software engineers Prolific.ac--a subject pool for online experiments Test theory: A unified treatment. psychology press The satisfaction with life scale Multivariate data analysis A systematic review of productivity factors in software development Why we should not measure productivity Software developers' perceptions of productivity Perceived stress in a probability sample of the United States Boredom proneness-the development and correlates of a new scale A short boredom proneness scale: Development and psychometric properties Self-determination theory and the facilitation of intrinsic motivation, social development, and well-being The balanced measure of psychological needs (bmpn) scale: An alternative domain general measure of need satisfaction Well-being as a function of person-country fit in human values Self-determination theory and work motivation This work was supported, in part, by the Carlsberg Foundation under grant agreement number CF20-0322 (PanTra -Pandemic Transformation).