An enormous share of modern research depends on software: simulations, analysis pipelines, instrument control and the bespoke code that turns raw measurement into result. Building that software well requires deep expertise — in both the science and the craft of programming — yet for a long time the people who provided it had nowhere obvious to stand. They were too specialised in software to follow the conventional academic track, and too embedded in research to be ordinary developers. The result was a recognised gap in the research workforce, and a name for the people who fill it: the Research Software Engineer, or RSE. This article looks at how RSE has come to be recognised as a career path in its own right, a development that belongs in the mentorship and career-stages domain of the CASRAI Dictionary.
The gap that created a profession
The problem was structural. Academic careers have traditionally been built on publications and the metrics derived from them, with progression assuming a path through postdoctoral research towards a faculty post. Someone whose contribution was the software — who wrote the code that made a hundred papers possible but appeared as author on few — did not fit that mould. Such people were frequently employed on short, precarious contracts attached to individual grants, with no clear progression and little recognition for work essential to everyone around them. The consequence was damaging: talented people left for industry, where their skills were valued, and research lost the expertise it increasingly depended upon. Naming the role was the first step towards fixing a problem that had previously been nobody’s to solve.
The RSE movement
What grew from that naming has become an international movement. It began with the recognition that a community existed, scattered across institutions and disciplines, doing fundamentally similar work without a shared identity. Bringing those people together — under the banner of research software engineering — gave them visibility, a professional network, and collective weight to argue for recognition. The Society of Research Software Engineering emerged from the UK community to represent and support RSEs, organising conferences, fostering local groups and advocating for the profession. In the United States, US-RSE plays a parallel role, and similar associations have formed in other countries, increasingly linked through international cooperation. The movement’s achievement has been to turn a diffuse population of overlooked specialists into a recognised profession with a name, a community and a voice — the precondition for everything else that recognition requires.
Building a genuine career
Recognising RSE as a profession means building the infrastructure of a real career, not just adopting a job title. Several developments matter here:
- Dedicated RSE roles and teams. Many institutions now host central RSE groups, employing software engineers on stable terms to support research across the organisation rather than tying each one to a single grant.
- Career frameworks. Progression routes specific to research software engineering — with defined levels from junior to senior and leadership roles — let RSEs advance on the basis of their actual work, rather than being judged against a publication-driven academic ladder that does not fit them.
- Stable employment. Moving away from short grant-funded contracts towards more secure positions addresses the precarity that drove people away.
- Professional recognition. Treating research software engineering as a profession with its own standards, training and identity gives RSEs standing comparable to other research roles.
Together these turn a label into a livelihood: a path a skilled person can choose, enter and progress along without having to pretend to be something they are not.
Recognising software contributions in the record
Career structures address how RSEs are employed; the scholarly record must address how their contributions are recognised. Two mechanisms are central. The first is software citation: treating research software as a citable output in its own right, with a persistent identifier, version information and clear authorship, so that the people who built it can be credited and cited just as the authors of a paper are. When software is citable, the RSE’s work becomes visible in the formal record rather than disappearing into a methods section. The second is structured contribution description. When a piece of research is reported, the work of building its software can be named explicitly rather than left implicit, which makes the RSE’s role legible to readers, evaluators and employers alike.
The CRediT Software role
That structured description is exactly what the CRediT taxonomy provides, and one of its roles speaks directly to research software engineering. The Software role recognises programming and software development, the design and implementation of computer code and supporting algorithms, and the testing of existing code components — precisely the work an RSE does. The full set of roles is set out in our overview of the CRediT taxonomy and explored further in the resources at our learning hub. By assigning the Software role, a contributorship statement records an RSE’s contribution in the same shared vocabulary used for every other contributor, placing software work on an equal footing with the work that has always been visible. That parity of description is a quiet but powerful form of recognition: it says that building the software was research contribution, not mere service.
A consistent vocabulary for software careers and contributions
For the contributions and careers of Research Software Engineers to be recognised consistently — across institutions, funders, publishers and reporting systems — the way those contributions and roles are described must mean the same thing everywhere. That consistency is what the CASRAI Dictionary provides: a shared vocabulary so that an RSE’s software role, career stage and citable outputs are understood identically wherever they are recorded. The broader work of recognising the full range of people who make research possible is the concern of research administration, where careers, contributions and recognition come together. The RSE movement has shown that a profession can be built where none existed; a shared way to describe software contribution is what helps that profession take its proper place in the research record.
Leave a Reply