RSE stands for "Resarch Software Engineer," and it broadly refers to a software engineer that specializes in research software. This spans a wide gamut. Some RSEs are more researchers that do programming, and others are trained software engineers that work on research problems. If you identify as an RSE, regardless of where you fall on this spectrum, you are likely bringing practices from software development like version control, continuous integration, and data provenance into workflows to support sustainable software for research.
RSEs are like granola clusters hiding in a cereal box of flakes. Even if your institution doesn't have any kind of official RSE community, you will still find RSEs scattered about the research community as lab research associates, postdocs, staff, and sometimes even graduate students. They can be found at universities, academic institutions, national labs, and even companies. Sometimes larger labs can afford to hire staff to exclusively work on tools, and research computing groups play a role in helping their users to write code.
However, not all RSEs are hiding. A well established group, the UK Research Software Engineer Association based in the UK has existed since (what appears to be) 2013, and similar groups can be found in Germany and the Netherlands. The US-RSE group based in the United States was more recently established. You'll notice similar branding across these sites, and that is intentional. These initiatives aim to identify the importance of the RSE for success in research, and to establish the role as a full fledged professional path.
As mentioned previously, an RSE can range from a researcher that does a lot of programming, to a software engineer that works in research. While no single RSE is likely to fall within one subtype, one RSE is likely to have one or more facets, discussed next.
An RSE Manager is typically the lead of a group of RSEs, with a role that might be similar to a product manager in a company, or the head of a lab. This individual usually has expertise in software development, and is a leader not just for the work of the group, but the individuals in it.
It's likely that many RSEs sitting within labs started with or developed domain knowledge. For example, a researcher developing software for neuroimaging analysis is likely to be familiar with data formats and software for brain mapping. The domain developer might sit in a specific department or lab, and work exclusively on developing and maintaining software for the domain. Usually input, goals, and feedback would come from the group that the developer serves.
A part of being an RSE might include conducting actual research. It could be with respect to a domain of science, but it also might be research about software engineering, open source development, or general practices of conducting research to begin with.
In stark contrast, a generalist might assist researchers with good software development practices without having expertise about a specific domain. For example, a statistical programmer might hold office hours and assist researchers from departments across a university. This role can be viewed as a service, where the programmer has expertise in his or her practice, and researchers come to him or her to get support.
While a generalist programmer helps researchers with code they are writing, an open source RSE moves up one level to work on open source software that is valuable for their user base. The open source RSE must independently seek out or use some other method to derive what software is valued by their users, and what improvements are needed.
The RSE developer is by far the most challenging subtype of RSE, as it can be more disconnected from the user base, and sometimes requires intuition about what doesn't exist (but might) to improve research sustainability across groups. A generalist developer does not provide a service for researchers like the generalist programmer, but instead works on general software that intuitively could directly or indirectly help researchers. For example, developing new software that targets metadata provenance or creation of reproducible containers might not tied to an existing open source project, and is less likely to be written into a grant and requested by a lab. However, it would likely benefit researchers across domains, and they won't know it until the software is available to them.
For all of the above, the margins are not set in stone. For example, this author considers herself an open source generalist developer, primarily working on existing and developing new open source software for research. For more RSE stories, see the stories folder. Please add your story if you are an RSE.
Next, read about creating a plan for your initiative.