As universities transitioned in-person classrooms to virtual classrooms, instructors faced challenges and changes in how they conduct their classes and teaching style trying to keep virtual classrooms as similar to in-person as much as possible through the use of group work in breakout sessions. Within these breakout sessions, students are expected to work together to complete an assignment. Through 669 surveys and 19 interviews, our paper outlines the successes and challenges of breakout sessions and teamwork in virtual learning environments faced by professors, graduate teaching assistants, and students. Our findings show the importance of pedagogical research for online environments, the student need for persistent instructions and check-ins to facilitate teamwork in breakout sessions, and strong justification for the use of breakout sessions in online courses. Based on our findings, we propose design recommendations to address the challenges highlighted within the classroom and software used by instructors and students. Our work contributes and extends previous CSCW and HCI research in online distributed teamwork and education.

Background: Listening to music is a common practice among software developers. Music listening after work can help release work-related stress; while listening to music at work can improve work efficiency and make tedious work more enjoyable. The working environment of developers in the past few years has changed dramatically due to the vast adoption of remote and hybrid work policies. Aims: We aim to understand how listening to music at work affects remote developers’ perceived productivity and creativity. Method: We investigated 130 software developers and collected their music listening habits during remote work in a questionnaire. We studied the impact of listening to music on developers’ creativity and productivity while working remotely during the COVID-19 pandemic. Results: Our survey data suggests that developers generally feel more productive and creative when listening to music during remote working conditions. Conclusion: We found that developers who listen to music feel more productive and creative while working remotely due to reducing environment distractions.

The mass shift to working at home during the COVID-19 pandemic radically changed the way many software development teams collaborate and communicate. To investigate how team culture and team productivity may also have been affected, we conducted two surveys at a large software company. The first, an exploratory survey during the early months of the pandemic with 2,265 developer responses, revealed that many developers faced challenges reaching milestones and that their team productivity had changed. We also found through qualitative analysis that important team culture factors such as communication and social connection had been affected. For example, the simple phrase "How was your weekend?" had become a subtle way to show peer support. In our second survey, we conducted a quantitative analysis of the team cultural factors that emerged from our first survey to understand the prevalence of the reported changes. From 608 developer responses, we found that 74% of these respondents missed social interactions with colleagues and 51% reported a decrease in their communication ease with colleagues. We used data from the second survey to build a regression model to identify important team culture factors for modeling team productivity. We found that the ability to brainstorm with colleagues, difficulty communicating with colleagues, and satisfaction with interactions from social activities are important factors that are associated with how developers report their software development team's productivity. Our findings inform how managers and leaders in large software companies can support sustained team productivity during times of crisis and beyond.

Communication and teamwork are essential skills for software developers. However, these skills are often difficult to learn for students with autism spectrum disorder (ASD). We designed, developed, and ran a 13-day, remote video game coding camp for incoming college first-year students with ASD. We developed instructional materials to teach computer programming, video game design, and communication and teaming skills. Students used the MakeCode Arcade development environment to build their games and Zoom to remotely collaborate with their teammates. In summative interviews, students reported improved programming skills, increased confidence in communication, and better experiences working with others. We also found that students valued the opportunity to practice teaming, such as being more vocal in expressing ideas to their peers and working out differences of opinion with their teammates. Two students reported the remote learning environment decreased their anxiety and stress, both are frequent challenges for autistic people. We plan to rerun the camp next year with materials that we have made available online.

As the computing job market continues to expand, the demand for eligible professionals to fill open positions has increased. In response, diversity efforts seek to broaden the participation of underrepresented populations in computing. This movement towards broadening participation includes blind or visually impaired (BVI) people who, historically, have faced barriers in succeeding in a primarily visually-oriented field. The present literature has examined modifying current tools for greater accessibility for BVI people and developing new, more inclusive learning environments. We argue, however, for additional investigation into the accessibility of computing education from the lens of instructors who teach computing to BVI students. Our paper reports on findings from interviews investigating the learning experience of BVI students in computer science courses from the perspective of teachers of the visually impaired (TVI). We interviewed K12 TVIs regarding their experience teaching students how to code, preparing lectures to accommodate their students' needs, and the resources they believe are necessary to help teachers provide more accessible instruction to the students. Our findings revealed that despite the recent improvements to increase accessibility in K12 computer science curricula, challenges still exist regarding the technology used by BVI students and the lack of accessible learning materials available to teachers. Additionally, our participants offer suggestions of resources to help K12 teachers in providing more accessible instruction to their students. The findings may benefit those interested in improving accessibility in computing education for students with disabilities.

Advances in artificial intelligence are constantly increasing its validity as a team member enabling it to effectively work alongside humans and other artificial teammates. Unfortunately, the digital nature of artificial teammates and their restrictive communication and coordination requirements complicate the interaction patterns that exist. In light of this challenge, we create a theoretical framework that details the possible interactions in human-agent teams, emphasizing interactions through groupware, which is based on literature regarding groupware and human-agent teamwork. As artificial intelligence changes and advances, the interaction in human-agent teams will also advance, meaning interaction frameworks and groupware must adapt to these changes. We provide examples and a discussion of the frameworks ability to adapt based on advancements in relevant research areas like natural language processing and artificial general intelligence. The results are a framework that detail human-agent interaction throughout the coming years, which can be used to guide groupware development.

Network Automation seeks to integrate software solutions that aid in the management and maintenance of modern networks. In industry, large organizations see dedicated software engineering resources within a networking team. However, in the broader industry, it is more common to see traditional network engineers working on network automation. With the growth of Free and Open Source Software (FOSS), network automation software solutions also started to adhere to this development model. However, as it is known from the literature, onboarding to FOSS projects is not a trivial task and may be more challenging for people without a software development background. In this paper, we study network automation FOSS projects, which are seeing a large number of new contributors who do not have traditional software engineering skills. We analyze a set of data collected from pull requests and issues collected from 81 GitHub projects (71 network automation projects, and 10 top-projects from other domains), to identify the characteristics that are specific to first-time project contributors in the network automation domain. Our results show that pull requests in the Network Automation domain differ from those in the Top-10 set and the existing literature. At the same time that Network Automation projects are more inclusive (rejection rate: 12% vs. 28% on Top-10), the pull request latency is longer in this specific domain, especially for first-timers.

There are many benefits to pair programming, including increased knowledge transfer, higher quality code, increased code comprehension, and team bonding. Unfortunately, when programmers work remotely, it becomes more challenging to collaborate. Virtual Reality (VR) technology has become increasingly popular in domains outside of software engineering. It allows humans to experience increased social presence, a key for collaboration, while still working remotely. In the last few years, and even more so recently, remote work has become very common for software engineers. In this paper, we explore remote pair programming and code comprehension in virtual reality. We conducted remote pair programming experiments with a total of 40 professional programmers. Half of the participants pair programmed using VR as a tool and the other half used a screen sharing system to collaborate. We found that programmers solved almost twice as many bugs using VR. We also found that the time taken to solve bugs was, on average, reduced when working in the VR environment than using the state of the art.

The rapid rise and ubiquity of computing has led to tremendous growth in the field of software development; growth that has outpaced society's ability to fill available positions. The gap between this large number of openings and the decidedly smaller pool of qualified candidates available to fill them has created opportunities for individuals from non-traditional backgrounds to pursue careers in software development. Due to the nature of their disability, blind and low vision persons have not to date been heavily pursued as candidates for software development positions given the arguably visually demanding nature of the practice. As such, we argue, there are significant knowledge gaps as it pertains to how visual impairment may impact a developer's contribution to a software development team. To explore this issue we interviewed 11 visually impaired software developers about their experiences. Our findings suggest that workplace dynamics, project management practices, and tool accessibility are among the most significant challenges for these developers. We argue that this work furthers the understanding of visually impaired software developers which contributes to the movement towards accessible workplace environments and employment equity in software development.

There are many benefits of migrating applications to the cloud, including highly available and elastic compute power, unlimited backup and storage, fully managed services, and overall cost savings. However, there are many challenges that software engineers face when migrating applications to the cloud. Even more challenges during the recent COVID-19 pandemic. The focus of this paper is to shed light on the challenges software engineers face performing cloud migrations during a global pandemic. A proposed set of research questions will be used to determine the challenges remote software engineers face, as well as the tools and methodologies used during the cloud migration process. Future work will consist of building a process model by examining the current state of cloud migration approaches as well as new approaches due to a global pandemic.

Software development teams dedicate considerable resources to training newcomers. Newcomers are new developers to a software project. The software onboarding process is more complicated than onboarding into other organizations. It is much more challenging and time-consuming. The role of a mentor in onboarding newcomers in software engineering is well understood. However, the disruptions to the work of an experienced developer can reduce the quality of their work and job satisfaction. We propose a conversational bot that can help onboard newcomers to a software project instead of an experienced programmer. The bot will act as a mentor for the newcomer, thus putting less stress on experienced programmers. The bot will also be able to scan outside sources, such as stack overflow, for solutions to issues a newcomer may face. The newcomer will be able to interact with the bot using natural language. We will use this bot to assess improvements to code quality in future studies.

Virtual reality is an emerging technology for various domains such as medicine, psychotherapy, architecture, and gaming. Recently, software engineering researchers have started to explore virtual reality as a tool for programmers. However, few studies examine source code comprehension in a virtual reality (VR) environment. In this paper, we explore the human experience of comprehending source code in VR. We conducted a study with 26 graduate students. We found that the programmers experienced more challenges when reading and comprehending code in VR. We found no statistically significant difference in the programmers' perceived productivity between our VR and traditional comprehension studies.

The development of scientific software is, more than ever, critical to the practice of science, and this is accompanied by a trend towards more open and collaborative efforts. Unfortunately, there has been little investigation into who is driving the evolution of such scientific software or how the collaboration happens. In this paper, we address this problem. We present an extensive analysis of seven open-source scientific software projects in order to develop an empirically-informed model of the development process. This analysis was complemented by a survey of 72 scientific software developers. In the majority of the projects, we found senior research staff (e.g. professors) to be responsible for half or more of commits (an average commit share of 72%) and heavily involved in architectural concerns (seniors were more likely to interact with files related to the build system, project meta-data, and developer documentation). Juniors (e.g. graduate students) also contribute substantially - in one studied project, juniors made almost 100% of its commits. Still, graduate students had the longest contribution periods among juniors (with 1.72 years of commit activity compared to 0.98 years for postdocs and 4 months for undergraduates). Moreover, we also found that third-party contributors are scarce, contributing for just one day for the project. The results from this study aim to help scientists to better understand their own projects, communities, and the contributors' behavior, while paving the road for future software engineering research.

Programmers who are blind use a screen reader to speak source code one word at a time, as though the code were text. For example, "float f = 5.23;" can be read as "float f equals five point two three semicolon". This process of reading is in stark contrast to sighted programmers, who skim source code rapidly with their eyes. At present, it is not known whether the difference in these processes has effects on the program comprehension gained from reading code. These effects are important because they could reduce both the usefulness of accessibility tools and the generalizability of software engineering studies to persons with low vision. Furthermore, a lack of knowledge about blind programmers contributes to a bias against employing blind programmers. Employers are unfamiliar with the idea of a blind programmer and as a result may feel unsure about hiring one.

Blind programmers use a screen reader to read code aloud. Screen readers force blind programmers to read code sequentially one line at a time. In contrast, sighted programmers are able to skim visually to the most important code areas, assisted by syntax highlighting. However, there is a place where there is a widely adopted approach to skimming a structured document: the web. Modern screen readers employ what is known as a virtual cursor to navigate structural information on webpages such as HTML heading tags. These tags can indicate different sections and subsections in the structure of a page. We harness the existing familiarity of blind computer users with this interface in our approach which we call AudioHighlight. AudioHighlight renders the code inside a web view, either as part of the Eclipse IDE or as a web service. It places HTML heading tags on the structural elements of a source file such as classes, functions and control flow statements. We compare AudioHighlight to the state of the art in code skimming represented by a previous code skimming approach called StructJumper. We also compare to the state of practice in reading code on the web as represented by GitHub. We found that AudioHighlight increased the quality and speed of code comprehension as compared to both approaches.

This paper targets the problem of speech act detection in conversations about bug repair. We conduct a ``Wizard of Oz'' experiment with 30 professional programmers, in which the programmers fix bugs for two hours, and use a simulated virtual assistant for help. Then, we use an open coding manual annotation procedure to identify the speech act types in the conversations. Finally, we train and evaluate a supervised learning algorithm to automatically detect the speech act types in the conversations. In 30 two-hour conversations, we made 2459 annotations and uncovered 26 speech act types. Our automated detection achieved 69% precision and 50% recall. The key application of this work is to advance the state of the art for virtual assistants in software engineering. Virtual assistant technology is growing rapidly, though applications in software engineering are behind those in other areas, largely due to a lack of relevant data and experiments. This paper targets this problem in the area of developer Q/A conversations about bug repair.

Programmers who are blind use a screen reader to speak source code one word at a time, as though the code were text. This process of reading is in stark contrast to sighted programmers, who skim source code rapidly with their eyes. At present, it is not known whether the difference in these processes has effects on the program comprehension gained from reading code. These effects are important because they could reduce both the usefulness of accessibility tools and the generalizability of software engineering studies to persons with low vision. In this paper, we present an empirical study comparing the program comprehension of blind and sighted programmers. We found that both blind and sighted programmers prioritize reading method signatures over other areas of code. Both groups obtained an equal and high degree of comprehension, despite the different reading processes.

User stories are descriptions of functionality that a software user needs. They play an important role in determining which software requirements and bug fixes should be handled and in what order. Developers elicit user stories through meetings with customers. But user story elicitation is complex, and involves many passes to accommodate shifting and unclear customer needs. The result is that developers must take detailed notes during meetings or risk missing important information. Ideally, developers would be freed of the need to take notes themselves, and instead speak naturally with their customers. This paper is a step towards that ideal. We present a technique for automatically extracting information relevant to user stories from recorded conversations between customers and developers. We perform a qualitative study to demonstrate that user story information exists in these conversations in a sufficient quantity to extract automatically. From this, we found that roughly 10.2% of these conversations contained user story information. Then, we test our technique in a quantitative study to determine the degree to which our technique can extract user story information. In our experiment, our process obtained about 70.8% precision and 18.3% recall on the information.

Programmers rely on source code documentation to quickly understand what the source code does and how they would use it. Unfortunately, many programmers do not have the time to write and maintain source code documentation. A solution to this problem is to document and summarize source code automatically. Unfortunately, research efforts to automatically generate documentation have stalled recently because the research community does not know exactly what a summary of source code should include. To solve this problem, my overall strategy is to study programmer behavior in order to write algorithms that mimic that behavior. I have four key areas of work in which I execute that strategy: First, I determine what areas of code programmers read when they create documentation. Second, I find patterns in programmers' eye movements when they reading code. Third, I use recordings of developer-client meetings to extract user story information. Finally, I propose to conduct a grounded theory study at a medium sized software company to determine whether factors outside the code influence source code summarization. This paper discusses the foundation for my career in the software engineering community, and I seek the community's advice.

Abstract Bug reports are crucial software artifacts for both software maintenance researchers and practitioners. A typical use of bug reports by researchers is to evaluate automated software maintenance tools: a large repository of reports is used as input for a tool, and metrics are calculated from the tool's output. But this process is quite different from practitioners, who distinguish between reports written by experts, such as programmers, and reports written by non‐experts, such as users. Practitioners recognize that the content of a bug report depends on its author's expert knowledge. In this paper, we present an empirical study of the textual difference between bug reports written by experts and non‐experts. We find that a significant difference exists and that this difference has a significant impact on the results from a state‐of‐the‐art feature location tool. Through an additional study, we also found no evidence that these encountered differences were caused by the increased usage of terms from the source code in the expert bug reports. Our recommendation is that researchers evaluate maintenance tools using different sets of bug reports for experts and non‐experts. Copyright © 2016 John Wiley & Sons, Ltd.

Eye movement patterns are the order in which keywords or sections of keywords are read. These patterns are an important component of how programmers read source code. One strategy for determining how programmers perform summarization tasks is through eye tracking studies. These studies examine where people focus their attention while viewing text or images. In this study, we expand on eye tracking analysis to determine the eye movement patterns of programmers. We begin the study with a qualitative exploration of the eye movement patterns used by 10 professional programmers from an earlier study. We then use what we learned qualitatively to perform a quantitative analysis of those patterns. We found that all ten of the programmers followed nearly identical eye movement patterns. These patterns were analogous to eye movement patterns of reading natural language.

Source Code Summarization is an emerging technology for automatically generating brief descriptions of code. Current summarization techniques work by selecting a subset of the statements and keywords from the code, and then including information from those statements and keywords in the summary. The quality of the summary depends heavily on the process of selecting the subset: a high-quality selection would contain the same statements and keywords that a programmer would choose. Unfortunately, little evidence exists about the statements and keywords that programmers view as important when they summarize source code. In this paper, we present an eye-tracking study of 10 professional Java programmers in which the programmers read Java methods and wrote English summaries of those methods. We apply the findings to build a novel summarization tool. Then, we evaluate this tool. Finally, we further analyze the programmers' method summaries to explore specific keyword usage and provide evidence to support the development of source code summarization systems.

Source Code Summarization is an emerging technology for automatically generating brief descriptions of code. Current summarization techniques work by selecting a subset of the statements and keywords from the code, and then including information from those statements and keywords in the summary. The quality of the summary depends heavily on the process of selecting the subset: a high-quality selection would contain the same statements and keywords that a programmer would choose. Unfortunately, little evidence exists about the statements and keywords that programmers view as important when they summarize source code. In this paper, we present an eye-tracking study of 10 professional Java programmers in which the programmers read Java methods and wrote English summaries of those methods. We apply the findings to build a novel summarization tool. Then, we evaluate this tool and provide evidence to support the development of source code summarization systems.