Invite an RSE

Plenty of institutions now have Research Software Engineers (RSEs), people who combine an understanding of research with a knowledge of software engineering methods and practice. If you know of an RSE on your campus or in your network, you may consider bringing them in on your Research Dugnad to help out.

How can an RSE help us?

Research Software Engineers can help with any of the process or practice issues you have in writing, maintaining, or distributing the software you produce in your research. If you’re having trouble keeping your documentation up to date, for example, they may be able to recommend tools for generating documentation from code comments and automatically producing formatted documentation on every change. If you’re finding that different group members make incompatible changes to your code, they can recommend changes to your version control workflow to mitigate that problem.

Many RSEs provide training on software engineering practices, for example based on courses from Software Carpentry. If your whole group identifies a need for a particular skill, then devoting a significant chunk of your dugnad to a workshop facilitated by the RSE could make sense. Otherwise you could invite the RSE to give a short presentation on an aspect of software engineering that you then discuss in the group, mentor group members on software skills, or help out in particular code cleanup tasks.

RSEs are enthusiastic about, and experienced in, communicating software best practices with researchers. Engaging an RSE is a great way to get non-judgemental and jargon-free suggestions on improving your software skills and results.

Whether any particular research software engineer, or RSE group, has specific experience in your domain of research, or with the tools you use, will vary greatly. Nonetheless a lot of software engineering practices and skills are highly transferable so an RSE will still be able to offer help.

What should I ask them?

It’s best to start with a description of the problems you’re facing, so that you can work with the RSE to identify causes and solutions that address those causes. We’ve had good experience with “software surgeries”, short sessions conducted either face-to-face or online in which a researcher presents a particular problem and works through diagnosis with the RSE. These work best if you share access to your source code in advance of the meeting, though a “show-and-tell” screen-sharing session can also work well.

Maybe you don’t know what your problem is, but just want a general health assessment of your project and some pointers for things you might improve. There’s a whole range of scopes you could consider here, from requesting a code review of a particular function (some sites have set up collaborative networks for just this purpose) to getting a full software evaluation. How broad or how focused you want to go depends on how much of the dugnad you want to devote to the evaluation, and where you think the time will be best spent.

Where can I find an RSE?

There are RSE groups at institutions across the world, and the United States RSE Association maintains a map. There are also specific maps for the UK and Germany.

If there isn’t an RSE group near you, there may still be RSEs! “Embedded” research software engineers are members of research groups and focus on the software-related needs of those groups. Put out a call across your site or your research area, and see who responds!