Skip to content

Commit

Permalink
Suggest changes to SE skills section (#231)
Browse files Browse the repository at this point in the history 
* Suggest changes to SE skills section

Here is my long-promised suggestion for changes to the section on SE skills. Some words on the motivation behind these changes: 
* First suggestion is to rename "software engineering skills" to "technical skills". This is in particular motivate by the fact that things like re-use and teamwork that are included in the research and communication skills are also usually regarded SE skills. I think it makes sense to focus here on the technical aspects in contrast. Also, it makes it a bit easier to motivate why RSE is different from "standard" SE.
* Then I would suggest to mention the life cycle as first item in the list, as at least DOCBB and LIBS build upon that. I enriched the SWLC with a number of standard technical terms from SE, to show that all these things also have their place in RSE (albeit often in different forms).
* MOD seems to be the skill to me that in SE is commonly called "program comprehension" so I added that term. 

Co-authored-by: mschwarzmeier <[email protected]>

* Update competencies.md with @sdruskat's suggestion in order to work on it....

Co-authored-by: Stephan Druskat <[email protected]>

We should sharpen the notion of repos anyway. I think we continue the discussion in #241

* replaced another instance of software engineering skill

* FAIR is in glossary, FAIR4RS is reference to paper

* do not spell check intro.md it was removed with 4b9d44

---------

Co-authored-by: CaptainSifff <[email protected]>
Co-authored-by: mschwarzmeier <[email protected]>
Co-authored-by: Stephan Druskat <[email protected]>
Co-authored-by: Magnus Hagdorn <[email protected]>
  • Loading branch information
@CaptainSifff @mschwarzmeier
@sdruskat @mhagdorn
5 people authored Apr 5, 2024
1 parent 75edd9e commit 0e4f667
Show file tree
Hide file tree
Showing 2 changed files with 37 additions and 18 deletions.
1 change: 1 addition & 0 deletions .github/spellignore.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -94,6 +94,7 @@ HTC
IDEs
Ing
ISCB
iteratively
Jena
JOSS
JU
Expand Down
54 changes: 36 additions & 18 deletions competencies.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -187,7 +187,7 @@ We start with a non-exhaustive overview of existing initiatives in @sec:related-
provide the guiding principles for the work of an RSE.
@sec:required-generic-skills defines a set of core skills based on these values.
The skills themselves fall into three categories, namely
"software engineering", "research", and "communication" skills,
"software/technical", "research", and "communication" skills,
reflecting the hybrid nature of an RSE.
To justify the selection of these skills,
we also list some current tasks
Expand Down Expand Up @@ -380,7 +380,7 @@ The role of an RSE lies somewhere on the spectrum between that of a researcher
(the "R") and a software engineer (the "SE") and, therefore, requires
competencies in both fields. RSEs typically apply their knowledge and
experience in larger teams which allows them to cultivate this hybrid nature.
Therefore, we categorise the competencies into three categories: *software engineering skills*,
Therefore, we categorise the competencies into three categories: *software/technical skills*,
*research skills*, and *communication skills*, with a particular focus on the software and
research cycle and the scientific process. These competencies are relevant in a
broad setting and form the foundation for specific specialisations.
Expand All @@ -396,19 +396,36 @@ and competencies also depends on the size of the RSE team
(**Project team size**). Finally, different sets of skills are emphasised in
the different RSE specialisations (**RSE specialisations**).

## Software engineering skills
## Software/Technical skills

\newcommand{\skillsection}[1]{\hypertarget{skills-#1}{%
\subsubsection{\glsentrydesc{#1} (\texorpdfstring{\glsentrytext{#1}}{#1})}\label{skills-#1}}}

There are many \ac{SE} curricula out there, that try to define
which tasks a software engineer should be able to perform. A recent example
highlighting some aspects in more detail than here is @Landwehr2017.
The software skills outlined here are required to make research software adhere
to the \ac{FAIR} principles, which are aspects of good scientific practice.
@ChueHong2014 defines different levels of research
software reusability and the extent to which the \ac{SE} skills
need to be applied to reach them.
The technical skills required by an RSE overlap to a large extent with the common
fundamental software engineering skills (see, e.g., @Landwehr2017), but put greater
emphasis on aspects related to achieving good scientific practice.
For example, RSEs need to know how to make research software adhere to the
\ac{FAIR} principles, and how to achieve different levels of research
software reusability @ChueHong2014. To reflect this, the technical skills
listed below complement competencies regarding the standard life-cycle of
software development with RSE-specific focus skills.


<!-- Adapting to the software life-cycle -->
\skillsection{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 needs and ideas are gathered and analysed (requirements engineering),
followed by a formulation of 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 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.
Additionally, the research software life-cycle extends the traditional life-cycle
with \gls{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.


<!-- Creating documented code building blocks -->
\skillsection{DOCBB}
Expand Down Expand Up @@ -449,14 +466,15 @@ and be able to predict and cater to the changing needs of software as it moves t
<!-- Use repositories -->
\skillsection{SWREPOS}

The RSE should be able to identify and use fitting public platforms (so-called software repositories or repos) to share the artefacts they have
created and invite the public to scrutinise them for public review.
The RSE should be able to identify and use fitting public platforms (so-called software repositories or "repos")
to share the artefacts they have created and invite the public to scrutinise them in public reviews.


<!-- Software behaviour awareness and analysis -->
\skillsection{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.
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.
Expand Down Expand Up @@ -671,10 +689,10 @@ A story-like example of an individual through the hierarchies can be found in @s

| Competency | Junior RSE | Senior RSE | Principal RSE |
| --- | ---------- | ---------- | ---------- |
| \gls{SWLC} | Should be aware of the software life-cycle. | Should know where in the life-cycle their project is and which decisions are likely to lead to technical debt. | Should know how to manage and steer development/project resources accordingly. Should also have an understanding of the potential consequences of key project management decisions. |
| \gls{DOCBB} | Should be able to write reusable building blocks. | Same as junior, but the quality should set the standard for the project, while following current best practices. | Should know the current best practices and point their staff to the right resources. |
| \gls{LIBS} | Should be able to use package distribution platforms. | Same as junior, but should also be familiar with current best practices for building and deploying packages. | Should ensure that their project is available via an up-to-date and secure distribution platform. |
| \gls{SWLC} | Should be aware of the software life-cycle. | Should know where in the life-cycle their project is and which decisions are likely to lead to technical debt. | Should know how to manage and steer development/project resources accordingly. Should also have an understanding of the potential consequences of key project management decisions. |
| \gls{SWREPOS} | Should seamlessly interact with the repository of their project. | Should be well-versed in the intricacies of a repository, and probably interact with repositories of multiple projects. | Should promote the use of repositories and be able to convey best practices to junior and senior RSEs. |
| \gls{SWREPOS} | Should seamlessly interact with the repository of their project. | Should be well-versed in the intricacies of a repository, and probably interact with repositories of multiple projects. | Should promote the use of repositories and be able to convey best practices of sharing and reviewing to junior and senior RSEs. |
| \gls{MOD} | Should have a basic grasp of their piece of the software in order to use basic tools such as a debugger. | Should understand the characteristics of large parts of the codebase considering a variety of the metrics. | Should understand the big idea of the software project in order to define the task that the software solves. |

Table: Levels of software eng. skills expected per RSE career stage. {#tbl:comp-lvls-se}
Expand Down Expand Up @@ -1283,10 +1301,10 @@ and attend these additional modules to deepen their knowledge in the field.

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

- \ac{SE} skills:
- Software/Technical skills:
- Foundational module: Here we have an introduction to programming: Emphasising use cases over programming paradigms, students learn at least two languages: a language that facilitates prototyping and data processing (e.g., \gls{Python} or \gls{R}) and a language for designing complex, performance-critical systems (e.g., \gls{C}/\gls{Cpp}). This exposes them to computers in a hands-on fashion and is the foundation for (\gls{DOCBB}, \gls{LIBS}).
- Computing environment module: Programming languages are not enough to work in a landscape of many interconnected software components; hence we require something like software craftsmanship, where tools such as the Unix shell, version control systems, build systems, documentation generators, package distribution platforms, and software discovery systems are taught to strengthen skills in (\gls{LIBS}, \gls{DOCBB}, \gls{SWREPOS}, \gls{SRU}).
- Software architecture module: Here we teach software design and \ac{SE}, again strengthening (\gls{DOCBB}, \gls{LIBS}) on a more abstract level.
- Software engineering module: Here we develop foundational software engineering competencies (basic knowledge and skill regarding requirements engineering, software architecture and design, implementation, quality assurance, software evolution), again emphasising and strengthening (\gls{DOCBB}, \gls{LIBS}) on a more abstract level.

- Research skills:
- Optional domain mastery module: Additional minor research courses, but students with a home-domain already have the research part well-covered.
Expand Down

0 comments on commit 0e4f667

Please sign in to comment.