paper_teaching-learning-RSE
paper_teaching-learning-RSE copied to clipboard
CaptainSifff
Suggested title change
In the discussions at Dagstuhl it also turned out that several people are having issues with the "foundational" qualification of the competencies in the title.
Suggested change: "Identifying Competencies and Responsibilities of a Research Software Engineer".
This version just does not qualify if the competencies in the paper are foundational, basic, complete, whatsover (as people really cannot agree on this), and also emphasizes that this is an ongoing discussion.
In my mind we are aiming at providing exactly that: Foundational aka basic competencies. "Complete" is something different. This paper is presenting competencies that we have identified. It's not about "identifying".
If the problem is that "foundational" is perceived as implying "complete", we could use for example "basic"? Also, we could strengthen the notion that this isn't intended as an exhaustive enumeration and we don't mention a lot of skills from the domain of traditional software engineering that are, indeed, foundational.
How about "Identified Competencies and Responsibilities of a Research Software Engineer" then?
Another option would be "Core Competencies and Responsibilities of a Research Software Engineer"
#276 has now qualified a bit of what we mean. Do you feel it is resolved?
There was a good suggestion to distinguish between "Research Softare Engineers" and "Scientists Who Code".
My argument would be that the paper is very good for scientists who code, but it ignores all the competencies that a software engineer (and thus an automotive software engineer, an avionik software engineer or a research software engineer) should have.
Suggested change: "Identifying Foundations Competencies and Responsibilities of a Scientist who Codes".
and clarifying this term in the paper as well.
(or adding all the competencies that a software engineer should have to the paper).
I don't think we should change the term "Research Software Engineer". It was difficult to come up with a succinct name that reflects the scope of the role. It is starting to become well established and organisations are starting to recognise it. RSEs find themselves somewhere on the spectrum between researcher at one end and software engineer at the other. In the paper we describe a number of roles that fall on different parts of this spectrum. I fully agree that some of these roles will need the full set of competencies of a SE. I would also expect a curriculum for a RSE master degree would include these.
I propose to solve this with adding a subtitle to the paper (maybe after a "--"): "From scientists who code to full-time software engineers"
My rationale: I agree with both @mhagdorn and @rumpe. On the one hand some of the competencies we list for an RSE are more on the scientist-who-codes side of the spectrum, thus also diluting the term SE a bit. As Bernhard mentioned this might also make the bridge building between the two communities that we currently work on more difficult, as our paper with its current title also makes a potential funding politics statement/claim. On the other hand I also see that we need to promote the term RSE and show that it actually has the same breadth as (enterprise) software developers, who also work on codes from small prototypes to large enterprise/infrastructure software. At the same time the "research" part of RSE also adds a dimension that is not (always) present in the more traditional SE.
There was a good suggestion to distinguish between "Research Softare Engineers" and "Scientists Who Code".
My argument would be that the paper is very good for scientists who code, but it ignores all the competencies that a software engineer (and thus an automotive software engineer, an avionik software engineer or a research software engineer) should have.
Suggested change: "Identifying Foundations Competencies and Responsibilities of a
Scientist who Codes". and clarifying this term in the paper as well. (or adding all the competencies that a software engineer should have to the paper).
@rumpe , this paper is to delineate competencies to create a breed of specialists with skills that "Scientists Who Code" have and which "Software Engineers" have. Think of "Econometrics" or "Mechatronic Engineering". In other words, the use of "Research Software Engineer" is meant to churn out specialists which are with one foot in each of the two boats.
Given this, is it so that you would prefer the entire community to be instead named "Scientists who code well" or something with that meaning ?
I propose to solve this with adding a subtitle to the paper (maybe after a "--"): "From scientists who code to full-time software engineers"
Thank you for this suggestion, @juckel ! I think it's the best so far. ;) It would however mean that the paper would also (seriously) need to include software engineering skills and competencies, as @rumpe remarked earlier.
The meaning of "RSE" doesn't have a clear, unambiguous, consensual definition yet. That is a symptom of the problem that RSE societies want to address. My understanding from what the community perceives as "RSE" is that not all "scientists who code" are RSEs, but a lot of RSEs are, in fact, scientists who code. "RSE" in the current context does not imply a certain skill-level or breadth of SE-related skills. Here we want to contribute to change that and I believe @rumpe is absolutely right to expect that core SE-skills are an essential part of an ideal RSE's skill-set.
I would like to read his comment as a hint that we did a not so good job at communicating that indeed,
The technical skills required by an RSE overlap to a large extent with the common fundamental software engineering skills (see, e.g., @Landwehr2017), ...
We do mention requirements engineering, design, implementation, testing & validation, documentation, maintenance. Not sure what essential SE-skills relevant for RSEs are missing here. But in any case, we could communicate the essential nature of general SE competencies more prominently and better reference standard SE textbooks, curricula, SWEBOK, ...
It would however mean that the paper would also (seriously) need to include software engineering skills and competencies, as @rumpe remarked earlier.
Your are right, @annalenalamprecht. Maybe this can be solved by wealth of SE material, just like @hvwaldow also just suggested. We could extend the intro into section 4.1 to better explain the distinction and also refer to the SE textbooks etc. (maybe also to the ongoing processes of working better together).
In the EVERSE project I worked hard to replace "best practice" with "good enough practice". I also believe that this is the case for this paper. We don't expect an RSE to be outstanding in all competencies we list, but rather be aware that all these make up the breadth of what an RSE can do. And then, as needed, one advances his/her/their skill set using our paper as one potential guideline.
In the EVERSE project I worked hard to replace "best practice" with "good enough practice". I also believe that this is the case for this paper. We don't expect an RSE to be outstanding in all competencies we list, but rather be aware that all these make up the breadth of what an RSE can do. And then, as needed, one advances his/her/their skill set using our paper as one potential guideline.
Very much reminds me of Wilson et al.'a "Best Practices in Scientific Computing" (2014, https://doi.org/10.1371/journal.pbio.1001745) that was some years later replaced by "Good Enough Practices in Scientific Computing" (2017, https://doi.org/10.1371/journal.pcbi.1005510), arguably also realizing that the first was not a good fit for the target group.
The different interpretations of what an RSE is seem to add to the complication in our case, though.
As for EVERSE, it's admittedly ironic if a project on "research software excellence" promotes "good enough" practices. ;)
I also like the subtitle idea of @juckel. I am slightly concerned however, that it could be read as how to progress from scientist who codes to full-time SE rather than being inclusive.
I propose to solve this with adding a subtitle to the paper (maybe after a "--"): "From scientists who code to full-time software engineers"
Thank you for this suggestion, @juckel ! I think it's the best so far. ;) It would however mean that the paper would also (seriously) need to include software engineering skills and competencies, as @rumpe remarked earlier.
Can you be more specific which software engineering skills and competencies you would like to see included?
I also like the subtitle idea of @juckel. I am slightly concerned however, that it could be read as how to progress from scientist who codes to full-time SE rather than being inclusive.
I agree with @mhagdorn that this very subtitle could make the impression even worse. Because IMHO the paper does NOT address how to proceed towards more software engineering. However, I like the idea of @juckel to add a subtitle in general, too.
Can you be more specific which software engineering skills and competencies you would like to see included?
@BeastyBlacksmith It's not that there are no SE skills and competencies included yet. But the reference to the SWEBOK and related works is at the moment something like a single sentence that is hard to overlook, and other "classical" SE skills are mixed with the RSE skills identified and presented in the paper. Somehow the paper needs to acknowledge more visibly/prominently that there IS already a large set of established SE practices that of course also matter here. Perhaps by not only mentioning SWEBOK, but devoting a section to it to describe what it includes. Other ideas welcome!
Then maybe a variation for the subtitle:
About scientists who code and software engineers in research
what about
Foundational Competencies and Responsibilities of a Research Software Engineer - for both scientists who code and software engineers in research
although we don't want to restrict the readership to just RSEs
what about
Foundational Competencies and Responsibilities of a Research Software Engineer - for both scientists who code and software engineers in research
although we don't want to restrict the readership to just RSEs
Foundational Competencies and Responsibilities of a Research Software Engineer - for both scientists who develop software and software engineers supporting scientists
Foundational Competencies and Responsibilities of a Research Software Engineer - for both scientists who develop software and software engineers supporting scientists
cool, I like that. This seems to be an iterative process
May I potentially add the following issue: I find the wikipedia definition of RSE (https://en.wikipedia.org/wiki/Research_software_engineering) quite agreeable and very intuitive:
"Research software engineering is the use of software engineering practices, methods and techniques for research software, ...."
As a software engineer, I have to say that: When I look at that paper, the paper does NOT talk about the core competencies of a software engineer at all. So I find the paper title as it is does not fit to the paper content.
BTW: TU Munich is placing a bust for the German founders of software engineering, F.L. Bauer, on Montay 10th at the TU Munich, because he would have 100th birthday. (While the software engineering field is only ~60 years old.)
May I potentially add the following issue: I find the wikipedia definition of RSE (https://en.wikipedia.org/wiki/Research_software_engineering) quite agreeable and very intuitive:
"Research software engineering is the use of software engineering practices, methods and techniques for research software, ...."
As a software engineer, I have to say that: When I look at that paper, the paper does NOT talk about the core competencies of a software engineer at all. So I find the paper title as it is does not fit to the paper content.
BTW: TU Munich is placing a bust for the German founders of software engineering, F.L. Bauer, on Montay 10th at the TU Munich, because he would have 100th birthday. (While the software engineering field is only ~60 years old.)
And this is why I would suggest you either change the title or add the core competencies of a software engineer to the body of the paper.
At least I would not be confronted with a paper that tells me that the list of core compentencies of a research software engineer does roughly not contain any content of the software engineering field (except version control).
How about something like that?
https://github.com/the-teachingRSE-project/competencies/blob/1cba3c793cd8d682215a507efe0995ddbc6e2825/competencies.md?plain=1#L473-L496
I had a loook at the core principles that a software engineer should know. Actually the Software Engineering Body of Knowledge, the FAIR principles are not included there.
I would also like to add that some of the misunderstandings we have here come from the view that something like "traditional software development life cycle " still exists. (that was in the 70ties and 80ties). Since then SE has slightly enhanced its body of core competencies.
These are to my belief correctly core competencies: "Proper requirement elicitation, analysis and specification are of the essence for any successful development project. " But only mentioning them makes the paper somehow ill balanced compared to other competencies. However, it comes iinto the right directions ...
One thing at least I'd like to rememember from today's discussion is that currently ~60% of the content of our paper is not mentioned in our title....
a new idea: Foundational Competencies and Responsibilities of a (Research Software) Engineer?
Looking at the whole discussion a bit late (I was offline over the past two weeks), maybe some of these (summarizing) points help:
I think the unique skills of an RSE is that they have knowledge both of Research and of Software Engineering. The additional complexity comes from this two-dimensional field (@CaptainSifff @knarrff @mhagdorn). As "mechatronics" is a specialization that requires both Mechanical Engineering and Electronics knowledge, so is RSE a hybrid specialization (@jpthiele).
For this reason (and to emphasize the relevance to the RSE-related literature), I think we should keep the Research Software Engineer in the title.
The braces in the title would add more confusion, in my view. But we can introduce this distinction in one of the sections.
I find the discussion very interesting and useful, and I understand that we need to add a section about the "usual" Software Engineering skills that an RSE should also know. This would also improve the structure and bring symmetry with Research, as we already have the Ability to do Research (previously: Curiosity) as a skill.
More specifically, I suggest:
- Section 4. Foundational RSE competencies
- 4.1 Software/Technical skills
- 4.1.1 (Ability to do all the technical aspects of Software Engineering, according to the seniority level)
- One paragraph relating to the Software Engineering literature
- Choose a better, more consistent heading
- 4.1.2 Adapting to the software life cycle
- ...
- 4.2 Research skills
- 4.2.1 Conducting and leading research
- 4.2.2 Understanding the research cycle
- ...
- 4.3 Communication skills
