This year’s RSE conference took place from 3^rd – 5^th September in Newcastle. Around 20 ARC staff attended in person, with several others joining in the hybrid experience remotely. The latter has been steadily improving year on year, at least for contributing to the formal parts of the conference programme. The informal conversations are still much better in person, and this aspect was particularly appreciated by our newer RSEs. This blog post summarises our joint impressions of the conference, based on a debriefing discussion we had in our weekly “Collaboration Hour” later in September, and edited by Jonathan Cooper. We have raced against the conference committee to get this blog post out before the conference materials are published!

The programme had a mix of technical topics and sessions devoted to how we work as RSEs, and indeed wider “Research Technology Professionals” (RTPs) as well. RTP is a newly coined phrase used by UKRI among others to refer to the wide range of specialist roles that exist alongside traditional researchers, encompassing all the ARC professions and more. Several initiatives are aiming to leverage the success of the RSE movement to advance other professions in a similar way, some of which we are involved in or proposed at the conference, notably in the RSE leaders and aspiring leaders satellite event on the Monday. This has grown massively since its inception as a safe space for those struggling to create RSE groups to share the pain and learn from each other! Now there are many kinds of RSE group, many individuals in different RTP leadership roles, and much more wide-ranging discussions as a result. I particularly appreciated the session on the skills that leaders need in this environment – what people have found helpful and how we should be growing the next generation.

A similar topic was covered in the RSE Competencies workshop, although this covered all areas of RSE skills and tried to categorise these. We ended up with more non-technical skills than those focused on specific technologies. The work is ongoing with monthly community meetings, aiming to build a toolkit that will help people advance their careers: identify skills they need and avenues for training and professional development.

Several sessions focused on project management and Agile approaches. We heard from Manchester how they are adapting Scrum for their research projects, notably the categorisation of projects that they have according to how large they are and how engaged the researchers are, and therefore the different sort of tweaks they’re made to Scrum in each case. These seem to be fairly similar to how we operate in ARC, but in a more formalised structure. We contributed to the discussion session they ran on the following day (led by Sarah Jaffa, formerly of ARC!) with Monika and I doing a double act presenting a high level view of our approach and a summary of Kanban. An important theme of that session was that project management is as much about self-care as it is delivering on the goals of the project, and these aspects need to be well balanced or both suffer. A special interest group (SIG) is being set up dedicated to project management, and we have continued discussions within ARC too, with a recent blog post on adapting the agile values and principles to a research context.

Others in the group focused more on the technical programme. Mutation testing was one highlight – described as sort of like test coverage, but your code is randomly changed to see what breaks. If no tests fail then you may have revealed an untested code path that needs to be tested and fixed. It’s good for catching edge cases that haven’t been thought of but does take time to run. We noted that this is good as part of a wider array of testing approaches that can be used, for example hypothesis testing (randomising code inputs rather than the code itself).

Best practices for setting up development environments were covered in a couple of talks, and how this is perhaps one aspect that distinguishes an RSE from a CS researcher. These range from use of pip and pipenv in Python to things like dev containers and Nix. These are important for reproducibility. The Netherlands eScience Centre python project template had a nice feature that allows updating projects created using a template when updates to the template itself are made.

Several talks looked at performant Python. We were surprised (perhaps unfairly) at how much impact simply upgrading to the latest Python version can have. Tools like numba and approaches such as vectorisation were well known, but tips for using list comprehensions, sometimes in preference even to Pandas apply operations, were appreciated and will be useful for several of our projects.

As you might expect from ARC we had significant involvement in the high-performance computing sessions, including Tuomas running a “birds of a feather” (BOF) event for the HPC RSE community and giving several talks. Talks not by us covered a range of topics, including the age-old comparison of the merits of different languages and porting between them, the newer frameworks aiming to ease GPU programming, portability between different hardware, and debugging parallel programs. We enjoyed trying out the Grace Hopper chips in IsambardAI, and discussing how to utilise HPC in the most environmentally sustainable way. The conclusion from Archer2 is that given the CO₂ released by manufacturing HPC systems, the best option is to run them as intensively as possible since this maximises the research done for a given carbon cost – and indeed that personal lifestyle changes may be a better option for minimising your impact!

Green RSE was the focus for another BOF which some ARC staff attended. A SIG is being set up for this, trying to raise awareness of what RSEs can do and consider what training might be helpful. This is something we want to get involved with more at ARC, starting with an inventory of our current state in conjunction with the department’s Green Team.

The Fortran satellite event was very well run. It revealed that many people want similar improvements to the Fortran ecosystem to support automated testing and the like. We have recently started an initiative along those lines at ARC so will be trying to work with the wider community on this and avoid duplication of effort, having now met some relevant people.

Some talks focused more on particular research domains. Given ARC’s current efforts developing Trusted Research Environments (TREs) we were interested by the Turing’s approach. They worry less about packages coming into the secure environment, and advocated for just proxying CRAN, PyPI and the like, while making sure that your infrastructure is set up securely enough that things can’t get out unless you want them to. So if something does get in and cause havoc, it shouldn’t be able to egress any data and it should only affect a single study or project. This is also the approach we take in ARC’s TRE.

The unconference session was a highlight for some, particularly discussion of developing software as a medical device. This covered trying to work with people in the institution to come up with processes, but also trying to figure out what the role of RSEs and the Society of RSE should be in that process. Are we just followers or the ones coming up with the process? How much of the regulatory side is our responsibility and who else we need to work with? No firm answers from that, but lots of questions! A prototype tool we developed for one project may be useful here if we can get funding and/or collaborators to continue the work.

All found the keynote talks inspiring, especially the one from Anne-Marie Imafidon. The test driven development workshop got a mention as being really clearly presented with great materials, as did an interesting C++ graphics library called Morphologica.

We are all looking forward to next year’s conference in Warwick. On a personal level, I’m especially pleased that it is likely not to conflict with INSET days and I’ll be able to be there in person again.

In the weeks running up to the RSE Conference, myself and some colleagues will be providing our thoughts on the questions people have submitted for our panel discussion with senior university management about how RSEs are being supported within academia. (You can submit more questions and vote on the current questions on Sli.do.)

Question: If you have a central university RSE group do other staff working in RSE-like roles in academic departments have the same career opportunities as that group?

As research software groups grow, seemingly inevitably they start to acquire more structure and hierarchy, with more senior roles being created to help manage the group. This provides for career advancement opportunities within the group, although often this is with the caveat that an increase in grade requires more managerial responsibility and reduced time for technical work. The situation is more bleak for those employed directly in research groups, typically on a fixed-term postdoc style contract where typical academic advancement routes – dependent on a publication record – do not easily apply. How can universities ensure the same opportunities are available to all staff?

Several groups have tried to address this challenge by making their job descriptions and selection criteria available to the whole university, for instance at Sheffield and King’s Digital Lab. This promotes consistency of approach, and gives the potential to aim at senior roles with appropriate selection criteria. Sustaining posts beyond a single funding source still presents a bottleneck to supporting careers, however. Central RSE groups with a large project portfolio and successful track record can often offer permanent contracts to staff, whereas this is rarely an option for individual research groups. At UCL we are investigating the potential of establishing ‘satellite’ groups within academic departments. These would be able to offer equivalent terms and conditions to their staff, and collaborate closely with the central team. We are not there yet however!

It is also worth considering a broader perspective. For staff trapped in a succession of fixed term contracts, ‘career opportunities’ is often synonymous with getting a permanent post, ideally at senior postdoc or even up to professorial pay grade. There are however many directions of travel that could be considered. How do we allow university staff, wherever they may be based, to move flexibly between teaching, research and professional services roles (or a combination thereof!), into industry and back into academia, always learning new skills along the way? How can progression be linked to expertise in different technical areas, not just management responsibility?

This question is ultimately not limited to RSE roles, but affects the wider network of roles within academia. UCL’s career pathways initiative (aimed at professional services) and academic career framework provide hopeful first steps in supporting more flexible careers, but there is still plenty of work to be done!

Hear an expert perspective on this and a variety of other questions from a panel of senior institutional representatives covering roles in research, HR and research software at the Science and Engineering South panel on “Institutional Support for RSEs” at RSEConUK19 on the 18th September at 13:30. You can also read previous blog posts in this series by Simon Hettrick and Jeremy Cohen.

My colleague Jeremy Yates made the following comment to an earlier post. I thought it was interesting enough that it deserved a post and reply of its own:

An update from the coalface of the National E-I Project Directors Group. There is a major report being written for us and RCUK that looks at the practical issues of support and training including funding it. We hope this advice is made part of the RCUK E-I Strategy.

While we can at least make sure all the procedures and policies are right; the real task is to convince PIs (like me) of the utility of non-subject domain staff, not under my direct supervision, carrying out software tasks for my research.  The last week has provided me with several examples of a lack of trust/desire to retain control.  It’s taken a long time to wean people off having their own hardware; software is another matter in that it really does represent for many their IP and product – it’s personal.

At the heart of this though is the question “Just what is research software support?”

Some definitions I have heard sound a lot like “research” and seem to be combined with efforts to charge fEC on posts.   As I go deeper into this I’m learning the words that cause friction – Developer is benign in IT, but in research it is synonymous with Researcher; Engineering is, well, a research area.  We find ourselves forced back into terms that have become pejorative, such as “consultant”, or lower-grade such as “technician”. Perhaps we have to use older words such as Specialist or Expert.  Certainly the phrase “scientific programmer” is starting to reappear.

As ever this is going to be rather a long haul.   The need for a new and common lexicon between IT and researchers is the least of it.

— Dr Jeremy Yates, Director, STFC DiRAC HPC Facility,

We’ve been thinking a great deal about these questions in the UCL team: in our view we are professionals who are part of the research community, but are not pursuing our own research directions, instead acting as expert collaborators. This role, integrated within the modern multidisciplinary research effort, with the ability and experience to understand and contribute to research at the forefront of human knowledge, but as collaborators, not research leaders, is becoming more important as the set of skills needed to carry out effective research expands. This professional expert collaborator role, will, I think, apply in the 21st century not just to programming, but to other research contributions, including statistics, visualisation, and technical writing.

When we work with a research team, we take a collaborative, hands-on approach, trying to work with the processes, tools and ways of working that are comfortable for that team, while suggesting ideas from agile software development practices that may be helpful. By embedding ourselves within the culture of the group we are working with, we try to ensure that academic colleagues feel a strong sense of ownership for the code we produce together, while allowing our skills to diffuse into research groups. We do not follow a contractual, delivery-oriented approach. The feedback from the groups we have worked about this approach has been very positive.

We use the terminology Research Software Developer and Research Technologist, to indicate that we are specialist software developers, with the expertise, background, and intellect to engage deeply with advanced research. As I was quoted saying in a recent issue of the Times Higher Educational Supplement:

“It’s not our job to understand the science as much as the principal researchers, but you can’t do good software engineering without an understanding of what the programs are supposed to do. That is what we bring compared with the general software engineering marketplace.”

I’ve been asked to present a guest blog post for the Software Sustainability Institute about being a scientific software developer. After reading the post over at the SSI, if you love learning about cutting edge research, and find delight in crafting robust, readable and efficient code, then please apply to join our team. With the establishment of the Research Software Development Team, I hope we’re on the way towards establishing a successful home for scientific programmers in UCL.