Research software engineers: who they are and how to work with them

Most research groups have one. The postdoc who knows how the cluster works. The PhD student who rewrote the analysis pipeline over a summer and is now the only person who understands it. The staff member who gets an email every time a script stops working. For a long time these people had no job title, no career path and no line in the grant budget.

The term research software engineer, or RSE, gave that work a name. It started in the UK in the early 2010s and has since spread to many countries. This post explains what RSEs do, where they usually sit, and how researchers can work with them in a way that makes the software, and the research, better.

What is a research software engineer?

A research software engineer is someone whose main job is to build and look after software that is used to do research. That is the short definition. In practice the role sits between two worlds. An RSE is not a pure software developer who takes a specification and delivers a product. They are also not a researcher who writes code on the side. They know enough about the research to understand why a result matters, and enough about software to make the code that produces it reliable.

People arrive in the role from different directions. Some trained as scientists and found they enjoyed the code more than the papers. Others came from industry and wanted to work on problems with a research purpose. Both routes are common, and good teams usually have a mix.

What does an RSE actually do day to day?

The work varies a lot, but it tends to fall into a few familiar kinds of task:

• Building new tools. Turning a method from a paper into a package that other people can install and use.
• Improving existing code. Adding tests, removing duplication, making a slow analysis run in hours instead of days.
• Making work reproducible. Setting up version control, environments, containers and continuous integration so that results can be regenerated.
• Scaling up. Moving an analysis from a laptop to a cluster or the cloud, or parallelising a simulation.
• Data and infrastructure. Building pipelines, databases and web interfaces for research data.
• Teaching and advice. Running training, reviewing code, and answering the question "is there a better way to do this?"

A lot of the value is invisible in the final paper. A well tested pipeline does not get a figure of its own. But it is the reason the figures can be trusted, and the reason a new student can pick the project up a year later.

Where do RSEs sit in an organisation?

There are three common arrangements, and each changes how you work with them.

Model	How it works	What to expect
Embedded in a group	The RSE is hired by one lab or project, often on that project's grant.	Deep knowledge of the science, but the role can end when the grant does.
Central RSE team	A university or institute runs a shared group. Projects buy time from it or apply for allocated effort.	More stable careers and shared expertise. You need to plan and book time ahead.
Research computing or IT	RSEs sit alongside HPC and infrastructure staff.	Strong on performance and systems. Less often involved in the research questions.

Many institutions use more than one model at once. If you do not know which applies where you work, ask your research office or research computing service. A central RSE group, if one exists, will usually have a page describing how to request help.

When should you involve an RSE?

Early. The single most useful change most research groups can make is to talk to an RSE while the project is still being planned, not when the code is already a problem.

At the proposal stage an RSE can help you estimate how much software work the project really needs, which is often more than people expect. They can suggest whether to build something new or extend an existing tool. They can help write the software section of a data or software management plan. And they can make sure there is a budget line for their own time, which is far easier to secure at the start than halfway through.

Bringing someone in late is still worth doing. But it usually means the first weeks go on understanding and untangling code rather than improving it. Undoing early decisions about data formats or code structure is expensive. Getting them roughly right at the start costs very little.

How do you work well with an RSE?

Treat them as a collaborator, not a service desk. The projects that go well tend to share a few habits.

1. Explain the science. An RSE who understands why a calculation matters will catch mistakes that a specification would never mention. Spend an hour walking through the method.
2. Agree what "done" means. A working prototype, a tested package and a published tool with documentation are very different amounts of work. Say which one you need.
3. Share the code from the start. Put it in a shared repository with Git, even if it is messy. Messy code in version control is much easier to work with than tidy code in email attachments.
4. Keep someone in the group involved. If only the RSE understands the code, you have recreated the original problem. Pair on changes and review each other's work.
5. Plan for after the project. Decide who will maintain the software, where it will be archived and how it will be cited.

Regular short check-ins work better than occasional long handovers. A weekly half hour is often enough to keep everyone aligned.

How should RSE work be credited?

With authorship where the contribution is intellectual, and with software citation in every case. An RSE who designed the analysis pipeline, chose the methods for handling missing data, or found a bug that changed the result has contributed to the research. That is normally grounds for co-authorship under the authorship policies of most journals.

Even where authorship is not appropriate, the software itself should be cited. Archive a release, give it a DOI, and cite it in the paper. Our guides on citing software in papers and archiving code with a DOI cover the mechanics. Credit matters for RSEs in a practical way. Their careers depend on being able to show what they built, and a citable record makes that possible.

Where do RSEs find each other?

Through national and regional RSE societies, which have grown steadily over the past decade. The UK has the Society of Research Software Engineering. The United States has US-RSE. There are active communities in Germany, the Nordic countries, the Netherlands, Australia and New Zealand, and elsewhere, and new groups keep forming.

These communities typically run annual conferences, mailing lists or chat spaces, job boards and working groups on topics like careers, training and equity. Many also have local chapters or meetups within institutions. Membership is usually open to anyone who does or supports research software work, whatever their job title says.

For a researcher, an RSE society is a useful place to find advice, to recruit, or to learn what good practice looks like in your field. For someone who suspects they might already be an RSE without the title, joining is often the moment it clicks.

What if your institution has no RSEs?

Start small. Many central RSE teams began with one or two people funded by a single department that saw the need. If there is no team where you work, there are still options:

• Write RSE time into your next grant as a named role or a fraction of a post.
• Ask whether a neighbouring institution or a national computing centre offers RSE support to external projects.
• Find the people in your department who already do this work informally, and make it visible. Ask for it to be recognised in workload models and promotion criteria.
• Connect to a national RSE community to see how others made the case.

Evidence helps. A list of projects that were delayed by software problems, or papers that depended on one overstretched person, is a strong argument for a funded role.

What to do this week

Pick one active project and ask a simple question: who maintains this code, and what happens if they leave? If the answer is uncomfortable, find out whether your institution has an RSE group and book a conversation. If you are planning a new grant, add a line for research software effort before the budget is fixed. And if you are the person in the lab who keeps everything running, look up your national RSE society. You are probably already one of them.