Birds of a Feather

Teaching Research Software Engineering

Julia Damerow, Jeffrey C. Carver, Jason Yalim

Research software engineering is a profession without a clear educational pathway. The international RSE survey from 2022 (Hettrick et al. 2022) found that about 23% of all respondents finished their highest level of education in computer science, closely followed by physics and astronomy (21%), and biological sciences (10%). Respondents from the US had a very similar educational background with computer science (23%), physics and astronomy (19%), followed by mathematics (12%). Moreover, 42% of respondents worldwide and 30% of respondents from the US did not consider themselves a professional software developer. These statistics raise the question how we can train and prepare future research software engineers given that the “traditional” educational pathway of software developers in the private sector does not apply for research software engineers. Furthermore, there are many researchers and students who develop software for research that do not aspire to become full-time research software engineers but rather use programming as a tool in their research. How can we train them in research software engineering best practices in order to increase code quality and code sustainability and reusability?

We propose a Birds of a Feather session to discuss different approaches, projects, and initiatives that teach the principles and practice of research software engineering. We plan to start the session with four 7-minute presentations about teaching efforts in different settings followed by an audience discussion with planned breakout groups depending on the number of participants. The presentations are as follows:

  • “Teaching the Fundamentals of Research Software Engineering to Graduate Students” by Julia Damerow
  • “INnovative Training Enabled by a Research Software Engineering Community of Trainers (INTERSECT)” by Jeff Carver and Ian Cosden
  • “The Better Scientific Software (BSSw) Tutorial Series” by David E. Bernholdt and Anshu Dubey
  • “Incorporating research software engineering best practices into NSF CIREN cyberinfrastructure professional training” by Marisa Brazil and Gil Speyer To start off the discussion with the audience, we will create a poll and compile a list of discussion points with questions such as:
    • In your experience, what is the biggest challenge when teaching research software engineering?
    • What makes research software engineering unique?
    • What’s the typical background of the people you teach?
    • At a minimum, what should an aspiring RSE be trained in?
    • What’s the best career timing(s) for RSEng training?

Mapping Open Source Science

Jonathan Starr

This BoF will bring the RSE perspective to MOSS – RSEs are perhaps best positioned to provide guidance on these next steps. We will discuss what has been developed already, familiarize ourselves with the map by adding to it, and work to more closely align the map with the goals of RSEs. We will explore and discuss impact metrics, dependency graphing, stewardship of open source repositories by organizations, corporations, and institutions, along with citation graphing for open source research software. We will highlight work that has been done in this field, including ETO’s ORCA and Map of Science projects, and we will chart the path forward for the development of an Encyclopédie for the digital knowledge and research ecosystem.

Exploring the Potential Impact of Advancements in Artificial Intelligence on the RSE Profession

David Luet

I am proposing an exploratory discussion on the many ways AI could impact the RSE profession. I have discussed this topic with many different RSEs and each time I received a different answer. I would like to get a sense of the distribution of feelings towards AI within the community. Once the potential impacts of AI on the professions have been discussed in the first part of the BoF, a second part would explore the potential strategies to best position ourselves to take advantage of the predicted changes.

AI is already transforming the methodologies and practices in software devel- opment and engineering. For example, GitHub Copilot is a popular coding assis- tant that helps improve the programmer’s productivity. Some work is done at Meta to have an AI write tests. They are also AI-driven code review tools, automated documentation generation, and AI-assisted debugging.

What other aspects of the profession beyond software development could be impacted? Project management and data analysis are two examples. How will the wide adoption of AI impact Junior developers? Will it free them from the menial tasks and let them focus on the creative ones or will it take away tasks that are stepping stones for becoming a better programmer? AI can be a valuable teaching tool, but there is a risk of training Copy/Paste Engineers instead. How about intellectual property? What happens to the code generated by an AI trained on your open-source code published under a GPL license? Before the conference, the author would like to run a survey similar to within the US-RSE community. The main questions for this survey would be: “In the next 5 years, how much impact do you think the use of artificial intelligence will have on your job?”. The goal of the survey would be to get a sense of where the community stands between being dismissive (“This won’t affect my job at all”), optimistic (“This will make me much more productive that it will help speed up research”), pessimistic (“There won’t be a need for RSEs, the researchers will just explain their problems to an AI which will then write the code for them”)

Brainstorming Strategies for Cultivating Successful and Collaborative RSE Teams

Abbey Roelofs and Kristina Riemer

Research software engineering groups face unique challenges in functioning effectively and smoothly together. Technical skills and development, project management, and collaboration methods both within the group and also with researchers and domain experts all need to be taken into consideration. RSEs often have diverse backgrounds and skill sets with regard to these various aspects of the profession, and it can be a challenge to balance these competing concerns. How do RSE groups address these challenges to work well together as productive, collaborative, and satisfied teams?

We see this BoF session as an opportunity for everyone involved with RSE work as part of a group to come together and share experiences and ideas that have helped teams work well together better, and also lessons learned about what has not been effective for teamwork. We will choose topics together and break out into smaller groups for discussion. We expect these topics to potentially include (but not be limited to) professional development, project management, communication tools, retention approaches, goal setting, interdisciplinary work, and mentorship models; these are topics that repeatedly arise on Slack channels, in Community Calls, and in various Working Group conversations and are clearly of interest to the community. Following our breakout discussions, groups will report back to the session as a whole. This session will facilitate an open discussion of ideas and methods for building and strengthening RSE teams. Our hope is that participants will be able to take some of these ideas back to their own teams, follow up with the community via Slack or future conversations on how these ideas worked, and build our collective knowledge base of tools and practices for cultivating successful RSE teams.

Troy Comi

The global pandemic has significantly reshaped the landscape of work, prompting a surge in remote work arrangements. Advances in communication technologies and virtual collaboration tools have facilitated interactions among geographically dispersed teams.1,2 Research Software Engineers (RSEs) have not been immune to this shift, as organizations increasingly recognize the benefits of virtual collaboration.3 In this BoF, we explore the impact of remote work on RSEs, emphasizing both its advantages and challenges. We also delve into strategies for effective collaboration with stakeholders in a distributed work environment.

Remote work offers RSEs greater flexibility in managing their schedules. Freed from the constraints of physical office spaces, they can tailor their work hours to align with their productivity peaks. The ability to work remotely also contributes to improved work-life balance. RSEs can better integrate professional responsibilities with personal commitments, leading to enhanced overall well-being. Finally, eliminating daily commutes translates to less stress, more time for productive work, and lower carbon emissions.4 The perceived benefits are best quantified by Barrerok et. al. who report 2-3 days/week of remote work is valued at a 5-10% raise by employees.

Of course remote and WFH arrangements have disadvantages. Family members, pets, and household chores can disrupt focus and lead to underworking. At the same time, the absence of clear physical boundaries between work and personal life can lead to overworking.5 It is essential to establish a dedicated workspace and routines to mitigate possible interruptions and challenges. Remote workers may be more likely to be passed over for promotion due to being physically absent. Finally, an often cited concern with fully remote working agreements is the difficulty in maintaining effective communication with stakeholders.3 RSEs must bridge the gap between remote work and in-person interactions, ensuring that project goals are met even as an exception in office-first settings.

To address these challenges, this BoF session will feature experienced RSEs who have successfully navigated fully remote work environments and stakeholders. During the panel discussion, we will share insights, strategies, and practical tools for fostering collaborations and personal connections. Our aim is to empower RSEs to thrive in a virtual work setting, whether their stakeholders are local or globally distributed.

Better Scientific Software Fellowship Community

Elsa Gonsiorowski, Erik Palmer and Mary Ann Leung

Software developers face increasing complexity in computational models, computer architectures, and emerging workflows. In this environment Research Software Engineers need to continually improve software practices and constantly hone their craft. To address this need, the Better Scientific Software (BSSw) Fellowship Program launched in 2018 to seed a community of like-minded individuals interested in improving all aspects of the work of software development. To this aim, the BSSw Fellowship Program fosters and promotes practices, processes, and tools to improve developer productivity and software sustainability.

Our community of BSSw Fellowship alums serve as leaders, mentors, and consultants, thereby increasing the visibility of all those involved in research software production and sustainability in the pursuit of discovery. This session will present the BSSw Fellowship (BSSwF) Program, briefly discussing our successes in developing a community around software development practices. We will invite conference participants to benefit from our resources and explain how they can join us in this effort. The session will also highlight the work of recent fellowship awardees and honorable mentions in attendance at US-RSE’24. As many in the BSSwF community identify as RSEs, and BSSwF projects are of particular relevance, this forum will serve to amplify the connections between our communities.

Sharing lessons learned on the challenges of fielding research software proof-of-concepts / prototypes in Department of Defense (DoD) and other Government environments

Daniel Strassler

This Birds of a Feather discussion will focus on the challenges of fielding research software proof-of-concepts / prototypes in Department of Defense (DoD) / Government environments. These environments vary widely and have both technical and non-technical challenges. Navigating these challenges can often be extremely taxing and hard. The group of expert panelists will discuss their experiences and answer moderator questions. They will also field questions from the audience. The lessons learned and guidance provided will help inform research software engineers on the challenges they will encounter in DoD / Government environments and how to mitigate them.

RSEs in domain-specific ecosystems

Julia Damerow, Rebecca Sutton Koeser, Laure Thompson and Jeri E. Wierenga

Research Software Engineers (RSEs) are still newer and relatively rare in the humanities and social sciences, and the term is being adopted to cover a wide range of technical work. As a result, the role of the RSE in these disciplines is often distinct from that role in the sciences. Those who write about the RSE career path discuss the value of domain knowledge (Cosden et al., US-RSE & IEEE), but our experience suggests RSE work differs widely by domain.

Each research domain has its own existing ecosystem and how an RSE fits into it varies. In some cases, this is a clear continuation and professionalization of existing work. In other fields, this is a partially or wholly new research endeavor. In the humanities, most scholars are new to collaborative research, to thinking of their research content as data, and to computational approaches. How do these ecosystems impact the RSE role, and how might RSEs be intentionally or accidentally different? How might more nascent perspectives expand the affordances of the RSE role?

In our experience, the most successful digital humanities (DH) projects involve an RSE as co-author or co-PI. The RSE must take an active role in operationalizing research questions because humanities researchers don’t know which methodologies and measurements are possible or useful to answer their questions; something that is taken for granted in other spaces because researchers are trained in this kind of work. For instance, to determine whether a corpus of documents supports a particular hypothesis, specific statistics (such as word frequencies) need to be generated, which can then be interpreted. Researchers need to understand how these statistics are created and what they mean, which is typically not part of the standard curriculum.

We propose a BoF session to share and compare experiences of RSEs in specific research domains. How do these differences impact the training needs of RSEs? What does it mean for institutional support and infrastructure? How might the DH RSE experience benefit and inform RSE roles in other domains? We plan to start the session with a panelist discussion followed by a conversation with the audience.