Foundational Competencies and Responsibilities of a Research Software Engineer: Current State and Suggestions for Future Directions

1.1.1 The term Research Software Engineer

Research Software Engineering can be considered an interface discipline, linking traditional Software Engineering with Research itself.⁵⁷ Due to this nature there is a plethora of different variations of RSE depending on the particular Research domain they are working in. Therefore the broad notion of Research Software Engineers is better thought of as a collection of sub-communities. The term Research Software Engineer is made more difficult to grasp since an internationally recognised definition is still missing. While there is consensus about the general notion that an RSE is a person with one leg in their research domain and the other in software development, this spans a whole spectrum depending on which one is more emphasised. There is also the question of what level of professionalism concerning both non-SE research and SE is expected. A more inclusive definition allows more people to self-identify as RSEs, thereby also fostering an inclusive community of people working in digital science (see also Section 3 on the values of an RSE). RSEs fall therefore somewhere on the spectrum between a researcher at one end and a software engineer at the other. Common to all of them is, that they need to be able to work in the research environment the software is used in, ideally at eye-level with native researchers, but at least as close as possible. RSEs often need to deal with non-technical complexities that are characteristic for research environments: organisational, motivational, with respect to the size of projects, independence and heterogeneous goals of stakeholders, boundary conditions for funding and future funding, to name just a few. Summarising, RSEs have skills and experience in three important areas: in the research area(s) their software is used in, in software engineering topics, as well as in interdisciplinary communication.

1.1.2 Further definitions

Depending on the national research environments and processes that readers are familiar with, the notion of the terms software and research might differ. Therefore, to avoid ambiguities, we define these as follows:

Software: Source code, documentation, tests, executables and all other artefacts that are created during the development process that are necessary to understand its purpose.

Research software: Foundational algorithms, the software itself, as well as scripts and computational workflows that were created during the research process or for a research purpose, across all domains of research. This definition is broader than in⁵ and is the outcome of a recent discussion in.⁴⁰

Research software engineers: People who create or improve research software and/or the structures that the software interacts with in the computational environment of a research domain. They are highly skilled team members who may also choose to conduct their own research as part of their role. However, we also recognise that many RSEs have chosen specifically to focus on a technical role as an alternative to a traditional research role because they enjoy and wish to focus on the development of research software.

Researchers: People who are using the services provided by Research Software Engineers. This, on purpose, is a very broad definition and was chosen for a better reading.

3.1.1 Data security

A lot of RSE work involves the manipulation or creation of data processing tools. We highlight that professional conduct requires these creations to be reliable and to maintain data integrity. In particular, the way that personal data is handled can have far-reaching implications for society. Independent of the encoding into the respective national law in an RSE’s jurisdiction, the right to information privacy is internationally recognised as a fundamental human right, e.g., in the European Convention on Human Rights.^20,45 RSEs need to be aware of this topic’s importance and deal with tensions that might arise with researchers’ desire for trouble-free sharing of data, thereby expecting openness about the research process, versus the integrity expectations of the society towards information technology (IT) systems. Handling personal data also has ramifications for information security considerations during the software development process. Data protection is a complex topic, so RSEs should be aware that they may need to consult external expertise, for example when dealing with special topics such as cryptography or re-identification attacks.⁴²

3.1.2 Mentoring and diversity

RSEs are often experienced professionals who work closely with and provide technical training and guidance to early career researchers. Similarly to academic supervisors, they bear a certain responsibility to guide and advise less-experienced colleagues with respect to career development and the achievement of academic goals. This can take the form of supervising a student or mentoring a fellow RSE. The RSE needs to be aware of the biases arising from the sociological imbalances in research and academia. According to the United Nations Educational, Scientific and Cultural Organization (UNESCO) Science Report⁷⁸ women account for 33.3% of all researchers. 60.2% of researchers come from high-income countries which account for 17.5% of the global population in 2018. Furthermore, the socioeconomic background of academics is not representative of the general population, for example in the US a tenure-track academic is 25 times more likely to have a parent with a PhD.⁶⁵ Thereby, to promote their values of an honest, open, and inclusive research space, they should be aware of the diversity problems and help to mitigate them whenever they have the chance to do so.

3.1.3 Shaping digital science

Through writing research software, RSEs hold an important role in the process of scientific production. Their choices might determine whether the respective research is reproducible or not, whether the results can be re-used, whether future research can build on existing tools or has to start from scratch. Builders of larger research-infrastructure projects determine to some extent the possibilities and limitations of future research and therefore need to be able to make a value-based judgement on topics such as open science, path dependence, and vendor lock-in.

3.1.4 Addressing environmental sustainability within planetary limits

The last two decades saw transistor technology approach the limits of attainable miniaturisation, and maximum chip clock frequency begin to plateau.⁸⁴ Nevertheless, a misleading belief in limitless growth of computing capabilities (storage, computing power, transfer speed) is still widespread within popular perception. A practical consequence of this is an ever-growing demand for resources to cover the expanding need of storage and processing, with no clear deceleration in sight (e.g. the IEA estimates a doubling in data centres energy consumption from 2024 to 2026⁴⁸). At the same time, current science is well aware of several planetary boundaries being exceeded due to human activities.⁷⁴ Data processing, storage and transfer account for a non-negligible fraction.⁴⁸ Demands to move resource consumption to a sustainable rate are well justified and supported by science.⁸¹

RSEs have the opportunity to contribute to this effort by, for example, choosing computationally adequate approaches (e.g. recognising where a proven statistical method may suffice in place of a power-hungry AI model, or configuring a test pipeline to minimise redundancy), and embracing data frugality measures (e.g. recognising sufficient resolution when sampling data for processing or storage). If past computational solutions were frugal because of technological limits, in future they should tend to that by virtue of an awareness of what may be adequate. The Governance, Responsibility, Estimation, Energy and embodied impacts, New collaborations, Education and Research (GREENER) principles⁵⁹ suggest how these concerns can be addressed and how research computing can become more environmentally sustainable.

3.1.5 Emerging challenges

RSEs often operate at the cutting edge of technological development and therefore might have to deal with technologies of which the dangers and drawbacks are still poorly understood. A current example is the rush for the application of large language models (LLMs), where RSEs working in these fields should stay up-to-date and be able to help researchers assess topics such as training-data bias, LLM “hallucinations” or malicious use, with the greater goal of making these powerful tools work for the welfare of society.

4.1.1 Classical software engineering skills

To summarise the vast range of the skills a software engineer is typically equipped with, we refer to the Guide to the Software Engineering Body of Knowledge (Bourque, Fairley, and IEEE Computer Society¹⁰). Because research software engineering is an interface discipline, RSEs are often stronger in topics more commonly encountered in research software contexts (e.g., mathematical and engineering foundations) than in other areas (e.g., software engineering economics). However, they bring a solid level of competence in all software engineering topics. Therefore, RSEs can set and analyse software requirements in the context of open-ended, question-driven research. They can design software so that it can sustainably grow, often in an environment of rapid turnover of contributors. They are competent in implementing solutions themselves in a wide range of technologies fit for different scientific applications. They can formulate and implement various types of tests, they can independently maintain software and automate operations of the integration and release process. They can provide working, scalable, and future-proof solutions in a professional context and with common project and software management techniques, adapted to the needs of the research environment. Finally, as people who have often gained significant research experience in a particular discipline, they combine the necessary foundations from their domain with software engineering skills to develop complex software.

4.1.2 Adapting to the software life cycle ( SWLC)

The traditional software development life cycle defines the stages that form the process of building a piece of software. Initial development generally involves an analytic process where requirements and ideas are gathered and analysed (requirements engineering), followed by formulating a plan to fulfil them (design) that is finally turned into running code (implementation). This is accompanied by different measures of quality control (e.g., reviews, testing), validating and verifying that things work as expected and that they continue to do so when development progresses further. Depending on the software project, this can mean a simple “Think-before-you-do”, or more elaborate and formal processes.⁶⁷ Often the development cycles are executed iteratively and incrementally. The life cycle further includes periods of deployment, maintenance and further development (software evolution), as well as software retirement. To assess the current state and needs of the software, the RSE should be familiar with different maturity metrics, e.g. the DLR application classes,⁷⁷ the research software maturity model²¹ or technology readiness levels (TRLs). Additionally, the research software life cycle extends the traditional life cycle with software publication. The RSE should be aware of this life cycle and be able to predict and cater to the changing needs of a software project as it moves through the stages.

4.1.3 Creating documented code building blocks ( DOCBB)

The RSE should be able to create building blocks from source code that are reusable. This ranges from simple libraries of functions up to complex architectures consisting of multiple software packages. An important part of enabling code reusability is the provision of sufficient information in the form of comments within code, documentation or other means. This is vital to ensure that developers and maintainers understand what a piece of software aims to do and how to enable others to use the provided functionality. This is primarily achieved through a “clean” implementation and enhanced by documentation. Documentation ranges from commenting code blocks to using documentation (building) tools. It should be written with consideration for the different audiences who may need it depending on their goals and expertise, for example by following the Diátaxis framework.⁷³

4.1.4 Building distributable software ( DIST)

The RSE should be able to distribute their code on their domain/language specific distribution platforms. This almost always encompasses handling/documenting dependencies with other packages/libraries. It sometimes requires knowledge of using build or package management systems to enable interoperability with other projects. In terms of usability and needs of the user community the RSE should be able to decide whether a library or a framework is the right type of program to build and distribute.

4.1.5 Use software repositories ( SWREPOS)

The RSE should be able to identify and use fitting software Forges (often just termed “repos”) to share the artefacts they have created and, if possible, invite the public to scrutinise them in an open review process. These software repositories usually provide facilities for software development, which differentiate them from the domain repositories described later.

4.1.6 Software behaviour awareness and analysis ( MOD)

We define this as a certain quality of analytical thinking that enables an RSE to form a mental model of a piece of software in a specific environment (program comprehension). Using that, an RSE should be able to make predictions about a software’s behaviour. This is a required skill for common tasks such as debugging, profiling, optimising, designing good tests, or predicting user interaction. Many tools exist to help with understanding and evaluating existing code, especially from a structural point of view. An RSE should understand their output and its implications. An important facet of this capability relates to information security. RSEs need to consider the safety and integrity of personal data and other sensitive information and make sure that they do not negatively impact the integrity of their institution’s network and computing infrastructure (see Section 3.1.1).

4.2.1 Conducting and leading research ( NEW)

RSEs are curious and able to conduct research, both on research software engineering, and on their research-wise “home domain” (see also Section 5.4.1). Senior RSEs are also able to lead research, and many RSEs have a doctorate.⁴⁴ Since RSEs often operate in different research fields, they also gain their reputation from their effectiveness in interacting with researchers from the same or other domains. Therefore, some curiosity together with a broad overview of the research field is required, as this enables the RSE to learn new methods and algorithms directly from domain peers. Similarly, a broad overview of the field of SE research and the growing field of RSE research enables the RSE to learn, apply, and teach new methods and tools for improving the way they develop software. This curiosity, together with the ability to convert it into new ideas, is also reflected when an RSE is actively trying out new tools or discovering related literature from adjacent domains. Lifelong learning is then no longer just a phrase but becomes a motivation to work.

4.2.2 Understanding the research cycle ( RC)

One of the key skills that RSEs have is their understanding of how research works. They embrace being part of a larger community which, despite friendly competition, shares the common goal of gaining knowledge to disseminate it. Thereby they know that they are part of a bigger undertaking that involves many other parties in and outside their domain, and also that their software can be utilised at different stages of the research cycle by different people. They may be asked to contribute to the ethical and regulatory evaluation of a project to ensure integrity of the research performed therein. Like other researchers, RSEs are open to discussions and arguments beyond their own expertise and appreciate the underlying principles of good research, including publications, reviews and reproducibility.

4.2.3 Software re-use ( SRU)

The re-use of existing assets such as libraries and pieces of code to improve efficiency and quality belongs to the fundamentals of software construction.¹⁰ To discover software, RSEs rely on domain-specific knowledge and domain repositories, as well as research skills, discovering related software via software citations and metadata. To evaluate whether the artefacts to be re-used suit their needs, RSEs often need to consider the scientific context of their origin. For example, a paper that references the code under consideration might be crucial to validate its fitness for purpose or lack of suitability. Code that incorporates research-domain specific knowledge needs to be understood at a very detailed level and its re-use documented to meet standards of good research practice. Not only the technical compatibility needs to be understood and documented (programming languages, system interoperability), but also the underlying models and computational methods need to fit the purpose; this question often requires wider research skills and deeper understanding of the research domain at hand.

4.2.4 Software publication and citation ( SP)

Another part of FAIR software is concerned with publishing new and derived works and making them available for re-use by the research community and the general public, within the boundaries set by their institutional policies. RSEs need to have a basic understanding of common software licence types, including proprietary and open source licences and how “copyleft” and “permissive” open source licences differ. They should also understand compatibility between different licences, and the ramifications for re-using and composing programs. Beyond that, RSEs will need to properly execute the technicalities of software publishing. These include the application of licences and copyright statements, understanding and assigning software authorship, crediting contributors, maintaining FAIR software metadata and publishing software artefacts on respective publication platforms. Finally, RSEs will need to understand the principles of software citation.⁸² This concerns both the potential for reuse of their own work, which demands the provision of complete and correct up-to-date citation metadata for their software, as well as their own citation obligations deriving from building on previous work in the form of dependencies.

4.2.5 Using domain repositories/directories ( DOMREP)

Almost all research software is developed within a specific scientific domain. Some software may be able to cross boundaries, but the majority will have a home domain, with which it needs to be able to interact. The RSE then needs to be aware of any domain specific repositories that will contain data sets, catalogues, and other domain specific artefacts, in addition to software. The RSE also needs to be aware of how their software can interact with the existing domain-specific data repositories. Finally, they need to be able to assess and use software repositories - domain-specific or generic - for publishing software with the relevant metadata.

4.3.1 Working in a team ( TEAM)

Being able to work, and effectively communicate in teams is essential for RSEs. For example, RSEs need to be able to explain particular implementation choices made and may even need to defend them. Within a team of RSEs, code reviews improve knowledge transfer and increase team cohesion. The team might change on a project-to-project basis and might be comprised of colleagues with very different backgrounds including, for example, IT staff, domain scientists and technicians working alongside software engineers. The shared values come into play and each RSE needs to ensure that these values are lived by and passed on to others. Senior RSEs may lead a team of RSEs.

4.3.2 Teaching ( TEACH)

RSEs have many opportunities to teach. These range from inducting new colleagues to teaching digital skills either through short courses, for example from The Carpentries,⁸⁵ or entire lecture series. RSEs may also act as mentors and consultants. Code review also includes aspects of the teaching skill.

4.3.3 Project management ( PM)

The RSE should have knowledge of project management processes. At some institutes, project management tools and approaches differ between individual research groups, but it is useful if an RSE understands general structures of a PM scheme, or can bring in new ideas for improvement. Project management in research software engineering poses specific challenges (see USERS) that might require the capacity to adapt to changing conditions and deviate from common project management methods. Additionally, the RSE should know that SE offers various methods and approaches specifically tailored to management of software projects and products.

4.3.4 Interaction with users and other stakeholders ( USERS)

Since research software is often developed as part of the research process itself, its requirements and specifications might change with the progression of research. Stakeholders of research software often change across different research projects or even within the course of one project. Roles in connection with research software are often in flux and diffuse. For example, a single person might be user, developer and project manager at the same time. Often this means it is necessary for an RSE to think “outside their comfort zone”, but at the same time to be able to convey their knowledge and experience to experts of other fields or persons at different hierarchy levels in a way they can understand more easily. These conditions pose specific challenges for requirements analysis, project management, training and support.

5.4.1 An example master’s programme for research software engineering

The target audience for such a master’s programme are students holding a bachelor’s degree from a domain science, which we will call “home domain” in the following. There is explicitly no restriction on the candidates’ home domain: it may be from the STEM disciplines, life sciences, humanities or social sciences, and it can also change later in their career. Candidates with a bachelor’s degree in computer science are also explicitly included, although we acknowledge that their master’s programme should include adaptations to make their interaction effective with other domain scientists. In order to give the future RSE the necessary breadth, we expect this to be a four-semester curriculum.

The curriculum is formed from a combination of modules, some of which are core modules teaching essential skills that must be completed by all students. Other modules introduce more specialised concepts and skills. During the master’s programme, students should pick an RSE specialisation from the list in this paper and attend these additional modules to deepen their knowledge in that field.

Core modules are of course drawn from the three pillars of the RSE and can be categorised accordingly.

Throughout the programme the values outlined in Section 3 are incorporated into the sessions to raise awareness of the codes of conduct and to put these values into ethical practice (see e.g. Ref. 13).

Given that RSE work also involves a lot of craftsmanship skills, hands-on practice is an integral part of the curriculum. At least two lab projects are required within the mandatory curriculum. These should be executed as a team and involve a question from a domain science. We recommend covering both the candidate’s home domain as well as a different one. Ideally, projects stem from collaborations with scientists within the institution and RSE students take the role of a consultant. This setup strengthens the ( TEAM, TEACH, USERS) skill and encourages also the ( MOD) skill through interaction.

To emphasise the exposure to domains outside their bachelor’s degree domain, we recommend that RSEs also support their non-home-domain project with introductory courses from this discipline. This schools their ability to quickly adapt their vocabulary and thinking to other disciplines and is an aspect of ( MOD).

To align with the specialisations listed in this paper, example optional modules include topics on HPC engineering/parallel programming, numerical mathematics/scientific computing, web technologies, data stewardship, AI models/statistics, and community management/training.

The programme is finalised with a master’s thesis which should be dual-supervised by an RSE supervisor from an actual project, and a domain supervisor. The thesis should answer a relevant research question from the domain using computational methods, strengthening ( NEW). Software development is required, and the code is part of the gradable deliverables. The RSE supervisor ensures and grades the software craftsmanship aspects of the project. This setup ensures that we are grading the effectiveness of applying RSE skills in an actual research environment.

5.4.2 An example of a possible career path

Setting the stage Meet Kay, Kim’s² younger sister who currently studies researchology in a bachelor’s programme in the established domain of researchonomy at University of Orithena (UofO). We will follow Kay’s fictional career to illustrate how education, job-experience and a career in academic institutions could lead to become a successful RSE. In Kay’s world, some of the measures proposed in this paper have already been implemented.

Bachelor’s degree Through a program like Software Carpentry⁸⁶ or The Missing Semester,³ Kay learns about using computational tools to support the sophisticated statistical analysis typical for researchology. She uses those tools to create and automate the steps of processing data and producing outcomes for her bachelor’s thesis (generating plots with matplotlib and even CI for automatic building) and takes pride in a fully open and reproducible bachelor’s thesis enabling her to graduate with honours from the faculty of researchonomy.

Master’s degree Kay ponders whether to continue with computational researchology, which her bachelor’s supervisor is responsible for, or enrol in a domain-agnostic RSE master’s programme. Researchers in computational researchology need to acquire a large part of the general RSE know-how presented in this paper and specialise in Quantum-Accelerated Bayesian Optimisation methods. However, Kay decides to go for the more generic route of a dedicated RSE programme because she wants to continue in academia, but does not like the idea of becoming stuck with one research topic. She also experienced the immediate satisfaction gained by helping colleagues from her research group with tricky technical problems, which makes her happier than the subdued sense of achievement from having a research paper accepted long after she had written it. For her, coding and sharing knowledge in the form of software is of similar importance to writing a paper focused mostly on the obtained results.

The domain-agnostic RSE Master programme consists of a core of RSE topics with various electives for specialisation, some of them domain-specific (e.g., chemistry) or topic-specific (e.g., cloud computing for research). Kay chooses digital archaeology and develops a pipeline for reconstructing 3D models from ground penetrating radar data, to simplify the process for archaeologists (reproducibility, big data, ML). The project management skills that are being taught as part of the core RSE curriculum really help her to not get lost in this project. Apart from working with the researchers in her archaeology group, she has to work with members of the central RSE department to help her with the pipelines. She also has to liaise with the central IT department to organise storage for the large data sets. Towards the end of the programme, she visits her first RSE conference where she sees a lot of notions ( SWLC, RC) in action that so far have been abstract in her master’s degree.

The exposure to the wider RSE community inspires her to invest additional time into her thesis to publish her software project under a licence approved by the Open Source Initiative and to write an accompanying article in the open source journal JOSS.⁵³ Inspired by the discussion with reviewers of her JOSS paper, and the citation metadata file that JOSS created automatically for her when her paper is published, Kay starts to think more about making her software FAIR. She reads up on the topic in a guide suggested to her, the Turing Way,⁹¹ and creates metadata files that provide the citation metadata and general description for her software. She adds the files to her source code repository, and also adds an automated CI/CD pipeline that updates metadata and creates a new publication record in the Zenodo repository for each new release. Kay has now completed the RSE programme and has reached Junior RSE level.

Junior RSE Kay finds a position in the central RSE department at her university with a competitive IT salary. Although the contract is temporary, there is a good chance that it will lead to a permanent position. The university makes an effort to enable that since it is a member of “The Technician Commitment”,¹⁰⁸ an initiative to ensure recognition and career development of technicians, who face similar challenges to RSEs. Kay completes the Software Carpentry Instructor training and teaches basic research computing, while advising fellow students of her department on better programming ( DOCBB and MOD skill). She also runs a seminar in the RSE Master’s programme. She publishes a condensed version of that in JOSE.⁵² During her teaching duties, she becomes aware of a new project in her department that requires a community manager RSE, and she gladly signs up to focus more on her communication skills. After three years, she takes an exciting opportunity to work in another university.

Senior RSE The new position involves taking responsibility for the RSE related aspects of a large inter-organisational project. With her new responsibilities comes a shift in the importance of various aspects of her work. Having this position in an inter-organisational project places far more emphasis on communication and organisation skills. She is spending time teaching people ( TEACH skill) to onboard them into the project. There is a lot of interaction with different stakeholders in the project like funders and user groups ( USERS skill). To oversee the project, she uses an amalgamation of both agile and traditional project-management concepts and methods which she acquires on-the-job ( PM skills). Her work so far has already been heavy on ( TEAM) skills, but now also the leadership aspect comes into play.

RSE-focused principal investigator The job experience as a leading RSE for a large project was the last requirement necessary to be awarded the title of a “Certified Research Software Professional” (CRSP) from an institutionalised centre of RSE education. The certificate confirms her track record of valuable software contributions and of teaching and mentoring people, as well as her capability to enable, foster and contribute to high-quality research in a leading position. It is recognised by various funding agencies, such as the DFG, and hence enables RSEs to act as a PI for RSE-focused grant applications. It is also recognised by many prestigious universities and opens many career options that are also typical for PhDs. Kay can now write her own grant proposals to effectively fund work of moving research software projects from prototypes to infrastructure.

6.3.1 Bioinformatics skills and certification

Bioinformatics is another field that actively works on developing skill trees. The Bioinformatics Core Competencies,^66,95,96 the BioExcel competency framework,⁶⁴ the PerMedCoE competency framework,⁶¹ the Research Data Management and Data Stewardship competence framework²² and the ELIXIR Data Stewardship Competency Framework for Life Sciences⁷⁹ are examples of grassroots efforts aiming at defining the set of skills of various bioinformatics specialities, one of them as a taxonomy.⁶⁶ These frameworks eventually converged into the EMBL-EBI Competency Hub,^25,62 where typical RSE and bioinformatician profiles at different levels of seniority can be queried (e.g., Junior RSE, Senior Computational Chemist) and compared against one another (e.g., Junior vs. Senior RSE).

Competencies can be divided into more fine-grained building blocks: knowledge, skills and abilities (KSAs). They can be organised in a taxonomy, and are also transferable, i.e. a KSA can be a prerequisite to multiple competencies. The Mastery Rubric for Bioinformatics⁹² and the ELIXIR Data Stewardship Competency Framework for Life Sciences⁷⁹ are examples of KSA frameworks for bioinformatics curricula.

The Curriculum Task Force of the International Society for Computational Biology (ISCB) curates a database of degrees and certificates in bioinformatics.^49,66 The database includes bachelor’s and master’s degree programs and specialisations, PhD programs, and certificates from graduate schools.

BioExcel has research competencies that combine some of our research competencies and some notions from the communication skills. Their computing competencies roughly map to our software skills. Here, we find competencies such as “package and distribute software”, which maps to our ( DIST) competencies, and “comply with licensing policy”, which would in our framework be part of ( SP) in the research competencies. In addition, they have a dedicated parallel computing competency section, thereby shifting the emphasis of the knowledge of their computational tools towards the HPC-RSE specialisation in our framework. Career profiles, such as the computational chemist, bring additional domain specific knowledge; we would classify those as a mixture of ${DOMAIN}-RSE and HPC-RSE. It is noteworthy, however, that the BioExcel framework puts very little emphasis on communication skills, which are often involved in RSE-related tasks.

6.3.2 HPC skills and certification

As an area that generally requires a range of advanced skills, HPC is one field where there is ongoing work to identify relevant sets of skills for HPC practitioners and potential paths to develop these skills. The HPC Certification Forum⁸⁹ has developed a competence standard for HPC that defines a range of skills and how they are related in the context of a skill tree.^55,56 This competence standard is currently being built upon by the CASTIEL 2²⁹ project in collaboration with initiatives funded by the European High-Performance Computing Joint Undertaking (EuroHPC JU) to create a framework for HPC certification.³⁹ While this framework focuses mostly on skills specific to HPC, there are a couple of similarities to the framework proposed in this paper. The “SD: Software Development” skill set is very similar to the SE skills discussed in Section 4, describing a wide range of such skills. This skill set contains Programming Best Practices (SD2), Software Configuration Management (SD3), Software Quality (SD5), Software Design and Software Architecture (SD6), and explicit mention of documentation (SD7, see our DOCBB). Besides the Software Concepts for HPC (SD1), which mainly concerns HPC-focused RSEs, most of the skills contained in the SD2-SD7 categories apply to all RSEs. A significant difference compared to the framework proposed in this paper is the absence of skills related to research or communication. Noteworthy is already now the level of detail in their skill tree which is more similar to Section 5.4.1.

Also looking at pathways and how different skills are related, the UNIVERSE-HPC project,⁹³ funded under the UK’s ExCALIBUR research programme,³⁰ is looking to understand and develop training pathways to support the development of specialist skills in the HPC and exascale domains. The project is gathering open source training materials to develop curricula that support the training pathways that are underpinned by high-quality training materials.