Full text
Graham Lee, September 2025 “Where do the people come from?” A mixed methods investigation of Research Software Engineering
Graham Lee, September 2025 “I really don’t like Gaussian processes. I wanna write Python libraries.” A mixed methods investigation of Research Software Engineering in the U.K.
Motivation To discover how Research Software Engineering can enable better research by aligning its practices with the things researchers value.
Research Questions RQ1 Do UK-based researchers have the skills and training they need to fulfil the software-related requirements of their work?! RQ2 Does RSE exhibit the four properties of a profession in the functionalist theory of professions: a body of expert knowledge; technical autonomy; valuing service to others; and privileged status? ! RQ3 How do the institutions and logics of research influence the way an RSE performs their work, and what competing institutions vie for legitimacy? ! RQ4 Does the structure of the relationship between researchers and RSEs in a research group affect the research software practice?
Methodology A constructivist, mixed-methods approach 1. Survey of Oxford University researchers to quantify the software skills gap.# Helps identify the prevalence of informal learning and unmet training needs within the institution.! 2. Open-ended interviews with RSEs and other stakeholders.# Provides deep understanding of RSEs' self-perception, challenges, and aspirations regarding professional identity.! 3. Search and analysis of public blog posts about RSE.# Reveals how the RSE community articulates its value, practices, and navigates academic expectations in public discourse.! 4. Focus group discussions with researchers and RSEs working together.# Directly examines how collaboration models (e.g., embedded vs. pooled RSEs) influence software quality and community building.
RQ1: The skills gap persists Finding: Most researchers need software skills and learn through self-teaching or peer mentoring, with formal training close behind but little RSE-led mentorship.# # Practical Implication: RSE has yet to effectively close the skills gap for the broader research community.
RQ2: A liminal, unrecognised identity Finding: RSE lacks a consistently defined body of knowledge, and its autonomy, service, and status are precarious, often perceived as “granted” by Principal Investigators. RSE is often perceived as a struggle for recognition against “traditional, snobbish academic cultures”.! Practical Implication: RSEs need to proactively define and articulate their unique value proposition and advocate for clearer career pathways and recognition, distinguishing themselves from technical roles that make less-direct research contributions. Picture credit: Paramount
RQ3: RSE is isomorphic with academia Finding: RSE is highly dependent on academic structures (funding, career paths) and adopts academic logics to maintain legitimacy. Software engineering practices are often adopted incompletely and mimetically (copying visible practices) rather than systematically. Key SE areas like requirements management and software maintenance are consistently problematic or ignored.! Practical Implication: RSEs must strategically navigate academic politics, emphasising the tangible benefits of good software practice (reproducibility, impact) in terms that resonate with traditional academic incentives (publications, grants). This includes championing neglected areas like robust requirements and maintenance. Photo by Volodymyr Dobrovolskyy on Unsplash
Recommendations A Manifesto for RSE change (1/2) •Funders:! •Systematically identify software that needs to be sustainable using a clear checklist.! •Ensure dedicated funding for ongoing maintenance for sustainable software.! •Research-producing organisations:! •Establish parallel career pathways and job descriptions for software roles.! •Incorporate software responsibility into codes of ethical practice.