RSECon24 - the 'R' in RSE

At RSECon 2024 I delivered one of the emerging voice plenaries . This was a talk about my experiences in research software engineering, with thoughts and ideas for future directions.

As this was a brief slot I wanted provide the content of the talk with a few of the ideas that didn’t make the cut here for reference and posterity.

The slides from my talk can be viewed here but are largely images, most of which are placed at the appropriate points in the below essay.

Except where otherwise noted, these presentation materials are licensed under the Creative Commons Attribution-NonCommercial 4.0 International - ( CC BY-NC 4.0 ) License.

“Participants of RSECon24 - get sunshine”.

The long-term benefits of going outside have been proven by scientists whereas the rest of the viewpoints in this talk have no basis more reliable than my own meandering experience.¹

When narrowing down topics for this talk, something I feel strongly about and wanted to discuss is the “R” in RSE; the “Research”. Personally it is the research application that drives me, so I will share the values I see in the domain-based RSE. I also want to talk about communities, and their value to all RSEs, before finishing with my thoughts on how communication of software-driven research could be better communicated.

My route to RSE is, I imagine, a familiar one, so I’ll dwell on what I feel to be the more salient points.

My initial exposure to programming came in the first year of my undergraduate degree where I sat through a lecture about bubblesort and the von Neumann architecture before being sent to the computer lab to calculate the Fibonacci sequence and plot the Mandelbrot set in C++. There, drowning in curly braces and semicolons, I formed the opinion that I distinctly hated programming.

It wasn’t until my fourth year that I started to come back around when, having not been assigned any of the theoretical or experimental projects I wanted, I ended up working on computational models for thermodynamics. It was the application of code to do science - in particular tackling problems where theory could only take us so far - that placed things in a new light for me. It also helped that I was doing so in what felt like a much friendlier language.

This led to me becoming scientific researcher and discovering what I really loved doing; using numerical models to understand our planet.

In my last job I earned the epithet of “careful coder” from my colleagues. At the time this meant that my code was readable, and didn’t fall over when other people tried to run it.

Over time my interests broadened and I found myself spending more and more time thinking about software alongside the science:

• how do I make code robust?,
• how do I speed it up?,
• why are datetimes so difficult?,
• why is everyone writing their own code to tackle issues instead of sharing it?,
• surely if we took care and made better software we could do better research!?

Despite all this, I still had not heard of the RSE movement.

In fact, my first encounter came when one of my closest friends started working as an RSE in plasma physics and I realised there were opportunities in research to address these issues and people who were working to do so.

So I decided to give this RSE thing a go, doing so from within my domain at the Institute of Computing for Climate Science .

So, given my background I want to ask, “Can RSEs do research?”.

Interpreting this as a question of ability, the answer is undoubtedly yes. Many of us here have worked under the label “researcher”, either in academia or industry. This is not the only route - I have colleagues who, having taken a deeper interest in particular projects, are now pursuing PhD research alongside their RSE role.

So let’s interpret this a different way; “Should RSEs do research?”.

I do not mean working as a “tau-shaped” academics, delving into a particular niche, but rather as “pi-Shaped” researchers, applying both domain and software expertise.²

Some projects require deep-dives into complicated domain software and here a background understanding becomes essential - for me this is climate models. Much of my work involves developing large climate models and I find an awareness of how everything fits together and is tuned is invaluable, even if I am only working on one specific component. With an appreciation of what the code does and how it fits together RSE knowledge can then be applied appropriately to find the best solution to a problem.

Working this way I believe that RSEs can be effective in, in fact, I believe RSEs can enhance research.

Working across multiple projects with a deeper level of understanding allows us to spot links, enabling the transfer of knowledge and ideas and the establishment of collaborations. Something I love about my current position is the ability to sit around a table with academics contributing to the science I love from both a domain and computational standpoint. In these situations I find there is immense value to background knowledge, allowing effective communication with researchers, and rightly or wrongly, it builds trust and respect with collaborators, helping them understand the benefits of Research software engineering rather than turning inwards to a postdoc to tackle these issues

By having a presence in domain environments these RSEs play a key role in the dissemination of RSE concepts to the wider academic audience. As another example, presenting at conferences, provides opportunities to communicate RSE topics directly to the academic mainstream increasing visibility of our movement.

So I believe there will always be a place for those RSEs who wish to stay in touch with research alongside quality software development.

This is by no means advocating for isolationism, however. When I think about what has allowed me to be in a position to give a talk today to the broad church that is RSE the answer, I believe, is other people.

In previous academic positions I was regarded as a ’local expert’ with RSE skills that were self-taught, very much held back by ’not knowing what I didn’t know'.

At ICCS I am fortunate to sit and work alongside the excellent Cambridge core team which allowed my RSE skills to develop exponentially. Being immersed in a team with such a breadth of knowledge and experience has been invaluable for osmotic learning, and for providing people I can turn to for help and advice.

This is a luxury that many embedded RSEs and researcher-developers don’t have with it being easy to feel isolated. My advice is to seek out a wider community and regularly spend time in it honing your RSE skills and not being afraid of asking seemingly banal questions; indeed several people in this room have been on the receiving end of mine. It’s better to ask and learn than to remain silent and struggle.

On the other side of this my call to action for larger groups is to consider how you can provide these opportunities for more isolated RSEs within your locality.

An example I’ll highlight are the Cambridge RSE Seminars . I have worked to make these a weekly event in Cambridge covering a range of topics from specific software, through walkthroughs, to community development. Equally valuable to the content of the talks, however, is the gathering of the research software community from across Cambridge coming together to form connections. This is greatly helped by having the community gather together for lunch beforehand - driven by Miren who is now helping establish the East of England Regional RSE Group .

In the last year we have expanded to invite speakers from beyond Cambridge, thanks to generous support from ICCS and the Cambridge Open Zettascale Lab. Invitations and opportunities to present work elsewhere are common in the academic sphere, but not so much in the RSE community. This is something I want to change.

Firstly, these are great opportunities to share experiences and exchange knowledge between communities. This year Mark Turner from Newcastle visited to speak about web development - something we have little experience with. In reciprocation Mark used the visit to learn about establishing and managing a HPC system - a new facet of his position in which Cambridge is strong.

Secondly, these talks provide an opportunity for RSEs and researchers developing software to present their work to an appropriate audience; something not prevalent in the academic mainstream. Indeed, multiple speakers note how satisfying it is to present the “effort and clever coding ideas” that go into their work to an interested audience instead of just communicating the scientific results.

We advertise the streaming link to the entire RSE community to join as a hybrid event. If you haven’t attended a talk before I’ll be advertising on the UKRSE slack again soon.

I’m going to finish by returning to the topic of research and sharing some thoughts on how the publication system could be better interfaced with research software.

In his 2023 essay What is a research software engineer? Newcastle RSE Mike Simpson suggests RSEs are not judged on research output, and when talking to colleagues I often find that there is an aversion to anything relating to academic publication. Whilst I agree that the system is broken, I believe that we need to engage with it. This is especially true for those in a domain who may still be reliant on “academic currency” for progression.

Research papers originated in the 17th Century in an effort to improve the dissemination of research beyond academics writing personal letters to one another. The oldest continuous journal is the Philosophical Transactions of the Royal Society which was restricted to the technology of the time - paper! Today, not much has changed with publications being available, ideally open-access, as a PDF - digital paper.

Some journals have started to acknowledge the use of software in research with the standard approach being to take a snapshot of the code, detach it from a continuously developing codebase, and whack it on Zenodo with a DOI linked from the paper.

I argue that it is not the code that should be a snapshot for the paper, but rather that a paper is a snapshot of the codebase.

Results that appear in a paper are generated from a particular version of a codebase that will continue to improve. As this happens I would argue that published results can, and indeed should, change. Previous results remain as a snapshot of what the code could do at that time, with changes showing how our models and understanding have improved. This is not something to be afraid of - research is about iteration.

Taking this view - Imagine if papers were linked by some form of ‘continuous integration’ allowing us to view this by regenerate results of research as the code develops.

Finally, instead of a link to a Zenodo dump, consider a codebase being fully integrated into a publication. By this I mean - imagine a paper written in a way that allowed users to go from a specific section directly to the relevant piece of code.

Often we are not interested in reproducing an entire paper, but instead want to apply or adapt techniques from a particular section for our own application. Imagine the ability to go directly from a paper to examine the relevant function. This would greatly enhance reproducibility and reusability, and reduce ’time to results'.

I have barely had time to describe all of these ideas here and they come from several discussions with Julius Busecke at NYU - I seriously recommend his article To be or not to be a software engineer in climate science? - If and when should climate scientists learn software engineering… . I would love to discuss this in more depth with anyone interested.

So, to conclude:

For some of us it’s research applications alongside a love of quality software that drives us, and this is something that should be embraced from both sides. Domain RSEs should to engage with the generalists to improve their skills, and the generalists should to engage with domain RSEs to drive dissemination of RSE concepts into research.

Related to this are ideas around how software could be better integrated into research communication, bringing it into the computational era - which RSEs would be well placed to drive.

I’ll finish with some advice I got from one of my colleagues:

“It sounds like you’ve found a way to do the science you love and explore things you find interesting seeingly without the bad parts. My advice is to ride that unicorn as far as you can.”

Simon - I’m working on it.

Oh, and trust me on the sunshine.¹

Thank you very much.

Thanks

Thanks to the following for their part in my RSE Journey. In a randomised order:

• Simon Clifford
• Paul Richmond
• Marion Weinzierl
• Steven Carlysle-Davies
• Liam Pattinson
• Kacper Kornet
• Arjen Tamerus
• Julius Busecke
• Peter Kirsch
• Sarah Glauert
• Chris Edsall

Thanks also to Dave Horsfall for the opportunity to speak in this slot, and David Kershaw for help preparing.

Contact

jwa34 [AT] cam.ac.uk
jackatkinson.net
jatkinson1000
@jatkinson1000@fosstodon.org