Why science needs more research software engineers

Ten years after their profession got its name, research software engineers seek to swell their ranks.

In March 2012, a group of like-minded software developers gathered at the University of Oxford, UK, for what they called the Collaborations Workshop. They had a common vocation — building code to support scientific research — but different job titles. And they had no clear career path. The attendees coined a term to describe their line of work: research software engineer (RSE).

A decade later, RSE societies have sprung up in the United Kingdom, mainland Europe, Australia and the United States. In the United Kingdom, at least 31 universities have their own RSE groups, a sign of the growing importance of the profession, says Paul Richmond, an RSE group leader at the University of Sheffield and a past president of the country’s Society of Research Software Engineering. Nature spoke with Richmond about life as an RSE, the role of software in the research enterprise and the state of the field as it reaches its tenth anniversary.

What do RSEs do?

Fundamentally, RSEs build software to support scientific research. They generally don’t have research questions of their own — they develop the computer tools to help other people to do cool things. They might add features to existing software, clear out bugs or build something from scratch. But they don’t just sit in front of a computer and write code. They have to be good communicators who can embed themselves in a team.

What sorts of projects do they work on?

Almost every field of science runs on software, so an RSE could find themselves working on just about anything. In my career, I’ve worked on software for imaging cancer cells and modelling pedestrian traffic. As a postdoc, I worked on computational neuroscience. I don’t know very much about these particular research fields, so I work closely with the oncologists or neuroscientists or whomever to develop the software that’s needed.

Building code is just one part of the role of a research software engineer.Credit: Norman Posselt/Getty

Why do so many universities support their own RSE groups?

Some high-powered researchers at the top of the academic ladder can afford to hire their own RSE. That engineer might be dedicated to maintaining a single piece of software that’s been around for 10 or 20 years. But most research groups need — or can afford —an RSE only on an occasional basis. If their university has an RSE group, they can hire an in-house engineer for one day a week, or for a month at a time, or whatever they need. In that way, the RSE group is like a core facility. The university tries to ensure a steady workflow for the group, but that’s usually not a problem — there’s no shortage of projects to work on.

What else do RSEs do?

A big part of the job is raising awareness about the importance of quality software. An RSE might train a postdoc or graduate student to develop software on their own. Or they might run a seminar on good software practices. In theory, training 50 people could be more impactful than working on a single project. In practice, it’s often hard for RSEs to find the time for teaching, mentorship and advocacy because they’re so busy supporting research.
Do principal investigators (PIs) appreciate the need for RSEs?

It’s mixed. In the past, researchers weren’t always incentivized to use or create good software. But that’s changing. Many journals now require authors to publish code, and that code has to be FAIR: findable, accessible, interoperable and reproducible. That last term is very important: good software is a crucial component of research reproducibility. We explain to PIs that they need reliable code so they won’t have to retract their paper six months later.

Who should consider a career as an RSE?

Many RSEs started out as PhD students or postdocs who worked on software to support their own project. They realized that they enjoyed that part of the job more than the actual research. RSEs certainly have the skills to work in industry but they thrive in an environment of cutting-edge science in academia.

Most RSEs have a PhD — I have a PhD in computer graphics — but that’s not necessarily a requirement. Some RSEs end up on the tenure track; I was recently promoted to professor. Many others work as laboratory technicians or service staff. I would encourage any experienced developers with an interest in research to consider RSE as a career. I would also love to see more people from under-represented groups join the field. We need more diversity going forward.

What’s your advice for RSE hopefuls?

Try working on a piece of open-source software. If possible, do some training in a collaborative setting. If you have questions, talk to a working RSE. Consider joining an association. The UK Society of Research Software Engineering is always happy to advise people about getting into the field or how to stand out in a job application. People in the United States can reach out to the US Research Software Engineer Association.

If you’re a PhD student or postdoc, give yourself a challenge: try to convince your supervisors or PI that they really need to embrace good software techniques. If you can change their minds, it’s a good indication that you have the passion and drive to succeed.

What do you envision for the profession over the next 10 years?

I want to see RSEs as equals in the academic environment. Software runs through the entire research process, but professors tend to get most of the recognition and prestige. Pieces of software can have just as much impact as certain research papers, some of them much more so. If RSEs can get the recognition and rewards that they deserve, then the career path will be that much more visible and attractive.

doi: https://doi.org/10.1038/d41586-022-01516-2

Source