Reading Time: 9 minutes

Key Takeaways

  • What an RSE does: A Research Software Engineer builds and maintains the software that powers scientific research — from simulation engines to data pipelines. Unlike pure software engineers, RSEs blend domain expertise with engineering rigor.
  • Two entry paths: You can enter as either a software engineer (strong engineering, weaker domain knowledge) or a researcher (strong domain, weaker engineering). Both converge on the same competencies over time.
  • Salary by sector: Academia/university roles range $70K–$165K, national labs $90K–$225K, industry $130K–$210K, and Big Tech $200K–$500K+. The gap narrows at senior levels.
  • GenAI is reshaping, not replacing: Generative AI gives 55–56% faster coding with Copilot, but cannot “truly understand or maintain” research software. RSEs are becoming more important, not less.
  • Career ladders work: Princeton’s peer-reviewed study showed a proper career ladder reduced RSE turnover from 70% to 7%, proving that parallel IC and team-lead tracks matter.
Visual note: An RSE Career Roadmap infographic showing entry paths → Junior → Mid-Level → Senior → Principal/Team Lead tracks with salary bands and skill milestones will be commissioned separately. A placeholder graphic will be added during the publishing phase.

What Is a Research Software Engineer?

A Research Software Engineer (RSE) is a professional who develops, maintains, and optimizes the software used to support scientific research. The term was coined in 2012 at the Software Sustainability Institute’s Collaborations Workshop, and it has since been formalised by CASRAI’s role definition as “a professional whose career focuses on the development and application of software to support research activities” [1].

This is not a research IT role — it is a research software engineering role. The distinction matters. An RSE does not just manage infrastructure; they write, test, and optimize the actual code that runs simulations, processes data, and visualizes results. They are the bridge between scientific questions and working software.

If you are already working with FiPy’s mesh structures or exploring how FiPy handles meshes and grid structures, you are already encountering research software. The RSE career path is about building that software at scale, with the same engineering rigor that industry applies to its products.

Why RSEs Matter

Modern scientific research increasingly depends on software. A single simulation can run for weeks on hundreds of cores. Data pipelines process terabytes of measurements. Reproducibility requires versioned, tested codebases that other researchers can audit and extend.

The CASRAI role guide explicitly frames RSEs as “critical to the success of modern research” because software is now the primary output of computational science — not just a means to an end. Researchers who cannot maintain production-quality code will find their work fragile. The RSE career exists precisely to solve that gap.

Two Entry Paths Into RSE

There are two main routes into research software engineering, and both have distinct strengths and blind spots.

Path 1: Software Engineer → RSE

People entering from pure software engineering backgrounds arrive with strong engineering practices — version control, testing, code review, API design, modularity. They can write production-grade code from day one.

What they do well: Code architecture, testing frameworks, scalability, documentation, CI/CD pipelines.

What they struggle with: Ambiguous research requirements, domain-specific terminology, the difference between a working prototype and a productionally maintainable codebase. Researchers often say “I need something that does X” where X is poorly defined. Engineers need precise specifications.

Path 2: Researcher → RSE

PhDs, postdocs, and senior researchers transition into RSE roles after years of writing scripts and tools for their own research. They understand the science deeply.

What they do well: Domain expertise, research problem formulation, scientific validation, literature review, communication with domain scientists.

What they struggle with: Code modularity, testing, scalability, refactoring, and the engineering habits that make code maintainable by others. They tend to optimize for “it works on my machine” rather than “it works on any machine.”

The Convergence

Both paths converge on the same core competencies. A software engineer who stays in the RSE role long enough learns the domain. A researcher who transitions into RSE long enough learns the engineering. The best RSEs come from either background — they just take different timelines to reach the same floor.

The Software Sustainability Institute’s Diego Alonso Álvarez documented this journey personally, going from postdoc to Senior RSE at Imperial College. His blog post on the researcher-to-RSE career path captures the transition with candid detail about the skills gap and the learning curve.

RSE vs Data Scientist vs Software Engineer

These three roles are often conflated in job postings and departmental budgets. A 2025 peer-reviewed comparison in the GI Digital Library makes the distinctions explicit, and institutions that confuse them tend to mis-budget and mis-hire.

Dimension Research Software Engineer Data Scientist Software Engineer
Primary output Durable, tested software Analysis and findings Commercial software products
Domain focus Research domain expertise Statistical/domain expertise Application domain expertise
Lifecycle position Builds tools others reuse Consumes data, produces insights Builds features users buy
Code durability Designed for multi-year reuse Often single-use or notebook-based Designed for product lifecycle
Validation Scientific correctness + engineering rigor Statistical significance + model accuracy Performance, security, UX

The key distinction for our audience: a Data Scientist outputs analysis; a Research Software Engineer outputs software that other people reuse. If your institution is conflating these roles, you are likely under-investing in reproducible research infrastructure.

Core Competencies

The US-RSE Education and Training Group, along with the Goth et al. (2025) competency framework [PMC12426816], identify three pillars of RSE competence. Each pillar has career-level progression.

1. Software / Technical Skills

This is the engineering pillar. It includes:

  • Version control (Git, DVC, datalad)
  • Testing (unit, integration, regression, regression testing)
  • Code quality (linting, type checking, lint tools)
  • Performance optimization (parallelization, GPU, profiling)
  • Scientific libraries (NumPy, SciPy, FiPy, NGSolve)
  • DevOps (CI/CD, containerization, HPC job schedulers)

These skills mirror what you will encounter in Reproducibility Workflows: Data Versioning and Provenance Tracking and Python Testing Patterns for Scientific Code.

2. Research Skills

This is the domain pillar. It includes:

  • Domain-specific modeling (PDE solvers, finite element methods)
  • Numerical methods (FEM, FVM, finite differences)
  • Algorithm development (adaptive mesh refinement, multi-fidelity methods)
  • Scientific validation (convergence testing, benchmark problems)
  • Literature synthesis (understanding state-of-the-art)

This pillar is where a PhD background shines, and where a software engineer needs targeted training. The MIT Missing Semester and Carpentries workshops provide accessible entry points.

3. Communication / Collaboration Skills

This is the soft-skills pillar, but it is anything but soft. It includes:

  • Cross-team communication (explaining technical constraints to domain scientists)
  • Project management (scoping, milestone planning, agile)
  • Mentoring (onboarding junior RSEs, code review guidance)
  • Community participation (open-source contribution, conference speaking)

The Goth et al. framework maps these competencies to career levels (from foundational to expert), and the US-RSE skills list provides a comprehensive enumeration you can use as a self-assessment rubric.

Career Progression Frameworks

RSE career ladders have historically been the weakest point in academic career infrastructure. Without clear progression paths, talented RSEs leave for industry — until recently.

Level Progression

Leading institutions use level frameworks such as L1–L4 (from foundational contributor to expert/leader) and P1–P6 (from novice to principal). These are not arbitrary titles — they map to concrete responsibilities:

Level Typical Title Primary Responsibility
L1 / P1 Junior RSE Execute assigned tasks under guidance
L2 / P2 Mid-Level RSE Own a module or tool; mentor juniors
L3 / P3 Senior RSE Define architecture; lead projects
L4 / P4+ Principal RSE Set direction; represent organization

The Parallel Track

A critical innovation in the RSE ladder is the parallel team-lead track. Not every RSE wants to be a principal individual contributor; some prefer managing people and projects. Princeton’s peer-reviewed study (arXiv 2602.19353v1, Feb 2026) documented this explicitly, showing that turnover fell from 70% (pre-ladder, five-year window) to 7% (post-ladder, three-year window) after implementing Associate through Principal levels with a parallel team-lead track.

This is the first documented, peer-reviewed evidence of a career ladder’s impact on RSE retention. It proves that the ladder matters — not just the existence of levels, but the existence of parallel tracks.

SSI’s Early-Career Perspectives

Four RSEs from the Software Sustainability Institute’s Research Software Camp (Nov 2025) described the progression challenges in candid detail — from unclear expectations and funding uncertainty to the reality of AI disruption. Their perspectives, collected in “Early Career Perspectives: Career and Skills in Research Software” are essential reading for anyone considering this path.

Research Software Engineering Salary by Sector

Salary is the most concrete comparison people make when deciding between career paths. The data below comes from CASRAI guidelines, research.com, Levels.fyi, and Glassdoor.

Sector Typical Range Notes
Academia / University $70K–$165K Strong at senior levels; constrained by academic budgets; “maintenance trap” where publications outweigh code
National Labs $90K–$225K Lawrence Livermore verified via Levels.fyi (software engineer range $110K–$225K); strong benefits; mission-driven
Industry (research divisions) $130K–$210K Closer to Big Tech compensation; stronger career ladders; commercial pressure
Big Tech $200K–$500K+ Highest pay; most structured progression; research software roles often labelled as “Applied Scientist” or “Research Software Engineer”

The national lab sector (LLNL, LANL, ORNL) represents the most compelling mid-range option: better pay than academia, less commercial pressure than industry, and mission alignment with scientific research. The Glassdoor average for RSE roles sits around $184K globally, with significant variance by location and seniority.

What the salary data reveals structurally: the “maintenance trap” — academic career systems reward publications, not code. An RSE who produces excellent, widely-used software but fewer papers will often fall behind in academic promotion compared to a domain scientist who publishes frequently. This is why the Princeton ladder, with its explicit recognition of software contributions, is transformative.

GenAI’s Impact on RSE Careers

Generative AI is reshaping research software careers faster than most career guides acknowledge. Two recent studies provide the clearest picture.

The SSSI Findings (Nov 2025)

The Software Sustainability Institute published a comprehensive analysis in November 2025 on “AI After My Job — Navigating the Future of Research Software Engineering”. The headline finding: RSEs are “more important than ever” because AI cannot “truly understand or maintain” research software.

Specific findings:

  • Productivity gains: Copilot gives 55–56% faster coding with AI assistance
  • Deskilling risks: Relying on AI without understanding can erode the very skills that distinguish RSEs from junior developers
  • Validation gap: AI-generated code must be reviewed by someone who understands both the code and the science
  • Recommendation: Invest in AI literacy. Learn prompt engineering, but never stop learning fundamentals.

The AI4RSE Quadrant Model

Siamak Farshidi et al. from the AI4RSE Lab (Wageningen University, ICSE 2026) introduced a Quadrant Model for AI-Augmented Research Software arxiv.org/html/2508.05693v1. The model classifies research code into four quadrants:

  1. Exploratory coding — quick scripts for hypothesis generation (AI-assisted, low risk)
  2. Vibe coding — experimental AI-generated code with uncertain correctness (high risk)
  3. Traditional RSE — production-grade, peer-reviewed code (AI-assisted review, not generation)
  4. AI4RSE — code co-developed with AI where the AI is the primary author (emerging specialty)

The emerging specializations include AI orchestration (managing multiple AI models in research workflows), LLM evaluation (assessing AI outputs for scientific validity), and green/reliable AI deployment (efficient AI inference in scientific contexts).

The Fraunhofer Perspective

The Fraunhofer IESE blog (Nov 2024, updated 2026) frames GenAI as a shift in the software development lifecycle rather than a replacement. The skills that matter most are now architecture, review, and domain expertise — not just coding speed.

Professional Bodies and Training Resources

The RSE community is well-organized, with national bodies, global initiatives, and standardized training. Here is the current landscape:

  • Society of RSE (UK) — The founding RSE society; hosts the annual RSE community meetings; runs mentoring programs
  • US-RSE — The US counterpart; maintains the official skills list; hosts career development workshops
  • de-RSE — Germany’s national RSE community; runs competency frameworks and professional development initiatives
  • CASRAI — Global coordination body; publishes the RSE role definition guide with career-track infrastructure
  • The Carpentries — Standardized training in data science and computational skills; widely adopted in academia

If you are a graduate student, start with Carpentries workshops and US-RSE skills lists as your baseline self-assessment. Then engage with your regional body (Society of RSE, US-RSE, or de-RSE) for mentoring and community.

How to Get Started

Here is my recommendation for graduate students considering an RSE career:

Step 1: Build a Technical Foundation

Start with Git, Python scientific libraries (NumPy, SciPy), and a testing framework (pytest). If you are already exploring modern scientific Python tooling with uv and ruff, you are on the right track. Learn to write tests that actually run during CI — not just in your notebook.

Step 2: Learn Domain Software at Scale

Take an existing research codebase (even your own) and refactor it. Add tests. Document it. Make it runnable on another machine. This is the single most effective transition from “researcher who codes” to “research software engineer.”

Step 3: Train on Engineering Practices

Git workflows, code review, CI/CD, and containerization. The Carpentries workshops and MIT Missing Semester are accessible entry points. The open source sustainability practices we cover on the site are relevant context for understanding what makes research code maintainable.

Step 4: Choose Your Sector

After building technical competence, evaluate sectors:

  • Academia if you value intellectual freedom, publication-friendly environments, and long-term projects
  • National labs if you want mission alignment with research, stable funding, and moderate pay
  • Industry if you prioritize compensation, structured ladders, and faster iteration
  • Big Tech if you want the highest compensation and most structured career infrastructure

Step 5: Engage the Community

Join US-RSE, attend the annual Society of RSE meetings, contribute to open-source research software. The field rewards visibility and community participation — and the structured learning paths we cover for computational mechanics students show that structured community engagement accelerates skill growth.

My Recommendation

If you are at the crossroads — a PhD student wondering whether to stay in academia or transition to industry — here is what I would choose:

Build the engineering skills first. A PhD who can write production-grade code is irreplaceable. A software engineer who understands the domain is equally irreplaceable. The market increasingly rewards the person who can do both.

The GenAI shift accelerates this. AI can write boilerplate code, but it cannot validate a simulation against physical reality. It cannot maintain a codebase for a decade of research. It cannot explain to a domain scientist why their model diverged. Those are the skills that matter.

Choose the parallel ladder path. If your institution offers a career ladder with both individual-contributor and team-lead tracks, take it. Princeton’s 70% → 7% turnover reduction proves that the ladder works. Without one, you are competing with industry for retention — and industry usually wins on compensation.

Related Guides