Research Software Engineers have been working at Advanced Research Computing (ARC), Durham University for almost two years now. Sitting within the research division of the university, the team works alongside academic colleagues on long-term software projects as well as immediate technical support – for example, code refactoring, debugging, performance engineering and more. We aim to advance sustainable software practices in research environments across the university through regular training sessions, discussions and technical collaborations.
We began our presentation at the Research Methods Café with an introduction to how we work as RSEs. Structurally, the RSE team sits alongside the Research Computing Platforms team at ARC. To work with us we ask you to fill out a project application form. From there we would set up a meeting to chat about your project. Up to 5 days of support are free at the point of use and up to 40% FTE of an RSE's time can be costed into grants (as named researcher or Co-I). If you require more than 40% FTE of RSE work it can be distributed over several RSEs (this way, you also have access to a broader set of skills). We also have experience doing ‘proof of concept’ work that can be used to drive forward future grant applications. This might also include defining software and hardware requirements.
RSEs at ARC come from a diverse range of backgrounds and bring a broad range of different experiences to their work. Each RSE gave a brief introduction to themselves as well as the projects they have been a part of while at ARC.
We asked participants what kind of support they might seek from RSEs and got the following five responses: Python, using AI in teaching, debugging, version control and NVivo. We run a number of courses in both Python and version control with Git on a termly basis and would be pleased to see participants at these events. Supporting AI in education is something we would be keen to discuss further. Debugging is a big issue that we only touched on in the discussion. We can both help debugging immediate problems and make improvements to codes that might limit the time consumed by debugging. This might include, building a testing infrastructure or restructuring code.
Our second question for participants concerned how we as RSEs could improve the way we work. The main feedback here was that events like this were valuable, that RSEs should continue to reach out to all research fields and that it would help to meet the team in person. On this final point, we are currently operating through Teams and will gladly set up meetings with anyone who reaches out to us. We are easy to get hold of.
Crucially, you do not have to be an expert in Computer Science to reach out to us. In fact, several of our collaborators leave the software development work to us – in this case our work might begin with a concept or research question. That said, ARC also houses RSEs that will embed themselves within established code teams, work on known problem areas, establish areas for future work or extend code functionality. Consequently, as a group our experience extends through web and mobile development, machine learning, HPC simulation codes and more.
Our third question for participants was one that is much debated within the RSE community: how should RSEs be acknowledged for their work? The results were as follows:
A participant made the valuable point that they had once been promised co-authorship for their work on a physics code base but ended up with an acknowledgement. Moreover, they highlighted how this was a difficult issue to get right: one’s contribution to a big physics code base can involve a lot of one’s own time, but still only be a small proportion of the overall time that went into the project as a whole. We note that in these areas the question of authorship is difficult: how do we quantify an RSEs contribution? Should the question of authorship be determined by relative significance? Should all contributions entail authorship even if an authorship list would become unwieldy – perhaps, almost meaningless – in the process? At ARC we would value co-authorship where appropriate and are increasingly interested in novel solutions to these questions - for example, the ideas proposed by Hidden REF.
It has also been noted that the nature of acknowledgment is often linked to funding models. In cases where publication impact is a performance indicator used to allocate funds, PIs are incentivised to give co-authorship and RSEs should expect to be co-authors. A participant illustrated this through an example from one of the HPC centres in Europe. They do not have a monetary return for the services they provide so one of the ways they can use to measure returns is the output of papers published as a result of their infrastructure. Funding bodies like to see high authorship/paper counts and therefore acknowledgement tends to be more widely distributed in these arenas. However, the accuracy and completeness of these authorship lists remain contested. A more general question of whether bibliometrics is even a good way to assess performance or quality of research is also a long way from finding a satisfactory resolution and casts a long shadow over this debate.
Another participant highlighted how the challenge of fair acknowledgement was not one that RSEs face alone, but rather is often problematic across academia. It was felt that there should be general guidelines and standardisation of how authorship/acknowledgement should work across the university. RSEs at ARC take an active role in driving forward this agenda from their positions within the Software Sustainability Institute and the Society of Research Software Engineering.
The conversation ended with a final question on whether an individual with a Physics PhD has the knowledge to become an RSE. The RSE community is not homogenous and houses people from a broad range of different fields. Training for RSEs is a topic that is under development right now - indeed, one of ARC’s RSEs is working on this within the Society of Research Software Engineering and N8 CIR. The key point is that there are lots of different types of RSEs with different levels of knowledge and they all develop as they work. The field is new and the criteria for being an RSE is fairly flexible beyond being able to write research software. As a first step into the community readers might consider joining the mailing list of the Society of Research Software Engineering and the RSE slack where RSE jobs are frequently advertised.
Many thanks to the participants who joined in with this conversation.
--
This blog expresses the author's views and interpretations of comments made during the conversation. The author is responsible for any errors or omissions.
Mark Turner is a Research Software Engineer at Advanced Research Computing, Durham University.
ApeconAim_ha Shay Jones Here
ReplyDeletehatwhislsandtroub