This blog is part of the Research Software Camp: Careers and Skills in Research Software series.

Research Software Engineering (RSE) is a crucial component of modern research, but as a profession, it is often misunderstood, under-recognised, and discovered by accident. Researchers often find themselves writing software long before realising that their work constitutes a career pathway in its own right. While RSEs’ contributions are not always supported or acknowledged, the field is gaining visibility, and efforts to strengthen recognition and support are growing.

This article brings together RSEs' perspectives across different fields and institutions. Through their reflections, we explore how people come to recognise software as research, the challenges of navigating the boundaries between researchers and engineers, the complexities of career progression, and the changes needed for research institutions to better support their work. Their insights also offer a perspective on the future of RSE and how generative AI, shifting research cultures, and evolving training pathways will influence it.

When did you first realise that writing software could be part of doing research - and not just a tool for it?

The RSE profession is not always well known, and many stumble into it by chance or work as RSEs without knowing the role has a name. RF and PVM discovered RSE well into their careers. RF “didn’t know what RSE was until mid-Covid” when he was brought in to work with other RSEs on the Fair Data Pipeline. Although he was meant to be a data scientist, he found himself writing the software. PVM similarly notes that RSE was not really talked about during his PhD in Spain and that only after three years working in the UK did he realise he had “been an RSE for almost 8 years.”

PF suggests that there are two ways people learn about the RSE profession. The first, through using software and tools in their research, the second — as in his case — by “writing code from scratch to solve research problems.” Of course, he points out, there is a distinction between writing software for research and it being “recognised as research or considered on the same footing as other research outputs.”

AM adds that the “best scientists aren’t always the best software developers” and that the two are “quite distinct disciplines within the research community.” Similarly to the others, he also did not expect to write as much software as he did when he joined the Met Office as a Researcher, but that “it became a big part of the job.”

Have you ever felt caught between being a researcher and a software engineer? How do you navigate that?

RSE would be more rewarding if software was treated as a first-class research output. AM believes that it is important to focus on what you enjoy and are good at. For him, that means working as an RSE and “creating reproducible software and enabling other scientists to do their great work.” PVM agrees, but points out that it is hard to make yourself heard and champion better research software practices when “there isn’t really time and capacity for that,” as teams tend to prioritise results and papers.

RF notes that it would be nice to be involved from the very start of a project, but that he usually “gets invited to look at the software after the research is done.“ He argues it should be a “collaborative effort and shouldn’t be an afterthought.” PF adds that “as a PhD student and postdoc, it was research first and software second,” but that as an RSE this balance has “reversed to some extent.” He recognises the tensions others describe, and observes that during his post-doc in the US, RSE roles were referred to as “computer facilitator” or “cyber infrastructor.”

What are your thoughts on career progression?

Career progression in the RSE field seems to be uneven and often constrained or poorly defined. PVM would like to continue working within research, but struggles with the expectation that researchers must run experiments, a requirement that consistently appears when applying for funding. In biology, experimental work remains the “golden standard”, while some still consider computational work to be mere support and image analysis only a “pretty picture.” As a result, he has considered pursuing the RSE path or even moving into freelance work. RF adds that his institution offers scientist and technician tracks, and he chose the scientist one. However, he notes he might have “left for industry” had he not been on a permanent contract and able to apply for grants more easily than others.

PF is interested in finding out what RSE career progression looks like outside academia. At his institution, RSEs feel like an afterthought within the career framework. There are scientist and technician tracks, and RSEs are placed on the former but are only explicitly mentioned in two of the five available tiers. Progression criteria revolve around publications, teaching, and grant success, activities that “may not directly translate to RSE roles.” In practice, however, RSEs are well supported by team leaders who are themselves RSEs and understand what the role involves. AM notes that the Met Office also offers two tracks, scientist and RSE. Because the organisation sits within the Civil Service, career progression is limited, but he highlights “there are a lot of skills development and learning opportunities.”

If you could redesign how research institutions support software work, what would you change first?

Funding and proper resourcing sit at the heart of the issue when it comes to how research institutions support software work. RF argues that institutions need to offer stable, full-time contracts and recognise that sustainable software requires sustained investment. He notes, however, that the field is not yet in a position to match salaries in industry, “because there’ll always be a disparity between industry and academia.” AM expands on this by highlighting the need for “proper planning of resources for projects.” Many teams simply do not have “enough people to get the work done,” or the work progresses inefficiently because the initial project planning failed to account for the true effort involved. As he puts it, “planning is hard” and “it takes a lot of experience and knowledge to do it well.”

PF argues that these planning challenges stem from a deeper issue: a lack of understanding of what RSEs actually do and how they contribute to research. In his view, “once people better understand what the role entails, then other aspects will follow, including the planning AM mentioned.” Research teams often underestimate the time needed to develop software, leading to misplaced expectations or evaluations of RSE contributions. He emphasises that “supporting software work is fundamentally about supporting the people who make software work.”

Another issue is the long-term sustainability of research software. PF points out that project proposals rarely include funding for ongoing maintenance, and PVM agrees, noting that there is “no time allocated for maintaining software.” As for solutions, RF suggests that the community needs more programmes like the SSI’s Research Software Maintenance Fund, as well as broader recognition among funders that software “needs to be maintained.”

How is the work of RSEs recognised within your organisation and in academia in general?

Recognition of RSE work varies widely across institutions and academia. At the Met Office and within the Civil Service more broadly, AM explains that RSE contributions are “recognised quite well, with clearly defined career families, and recognised as being essential” to all aspects of software-related work. He emphasises there is a growing appreciation for the skills RSEs bring.

RF describes a different experience at his university, where RSEs are less established compared to other institutions and many colleagues are simply unaware of “what RSEs do and how they can help.” As a result, much of their work is conducted through existing networks and personal connections, which shows that the contribution of RSEs is recognised once people experience it firsthand.

PF agrees that academics and project partners who have worked directly with RSEs typically come to understand and appreciate their contributions, often returning for further collaborations. Yet broader recognition remains a challenge. Within his own institute, senior team leaders provide a supportive environment, ensuring his work feels acknowledged. He highlights that academia remains overly focused on publication count as the primary metric for research success, and there is “a long way to go before software is understood as a tangible output in its own right.”

PVM echoes PF’s points, noting that when seeking postdoctoral positions, recognition depends heavily on the principal investigator. Some PIs “do not truly appreciate” RSE work, while others recognise its importance “for the future of [...] research”.

How do you think RSE work will change in the future?

The future of RSE work is seen both with optimism and caution, as new technologies and evolving research practices reshape the landscape. PF acknowledges reasons for optimism but expresses uncertainty about the impact of generative AI, noting that it gives researchers who do not know how to code access to tools that may “complicate how RSEs contribute in the future.” PVM takes a more confident stance, arguing that “Gen AI is a reason as to why RSEs are more important than ever,” explaining that while AI can generate simple code, it cannot truly understand or maintain it. RF agrees that generative AI is unlikely to replace RSEs, but highlights emerging funding trends that emphasise AI in grants for RSE. AM echoes these points, observing that “Gen AI has the potential to greatly help researchers to write code, but doesn’t replace the role of the RSE.”

The future of RSE will also rely on education and training. PF suggests that universities should offer more RSE-related modules. This would offer students the opportunity of discovering RSE earlier in their lives, and maybe realise it is a career path they’d like to pursue.

Any other general thoughts?

A greater recognition and understanding of RSE work is fundamental for the future of the field. PVM emphasises that more appreciation of the contributions made by RSEs is essential. PF adds that stronger “communication and collaboration between communities,” such as HPC operators, dRTPs in industry, and open-source contributors, could foster valuable cross-pollination, benefiting all parties by sharing skills, approaches, and outcomes.

RF notes that while software validation can occur within research institutions, external partners often need to apply their own metrics. He also highlights differences with industry, where work moves faster but is constrained by costs and stricter intellectual property protections, including NDAs that can slow collaborative processes.

Across all discussions, it appears clear that, although research today depends deeply on software, not everyone within the field has fully adapted to this reality. RSEs often discover their profession after years of writing code, they can face unclear or constrained career pathways, they navigate environments that undervalue maintenance and long-term sustainability, and their recognition varies depending on different institutions and individual managers. And yet there is growing awareness of the importance of software in research and increasing appreciation for the specialised skills RSEs bring. There are opportunities for better planning, funding, and stronger collaboration. Generative AI could be a threat, but it could also reinforce the need for experts who know how to write code and, crucially, why it is done that way.

To ensure the future of RSE continues to be bright, institutions and academia need to acknowledge the role of RSEs in achieving research excellence, treat software as a research output in its own right, and provide career pathways and structures that reflect their value. The path forward requires change, and the first step is realising that supporting research software means supporting the people who build it.