In this article, I want to chart the course that led me to run the Software in Polar Science event as part of my Fellowship and share what I’ve learned along the way, especially as a result of being an RSE and SSI Fellow.
I applied twice to be a Software Sustainability Institute Fellow, in 2021 and 2022. Now in 2024 the original motivations are lost to me, but it’s really illuminating to return to the presentations to see what motivated both me and the work (though you’d have to pay me handsomely to watch the videos from 2021 or 2022 again, as hearing my voice is cringe-inducing).
The first time I applied, I was already five years into my journey to become a research software engineer. This term means a lot more to me now than it did then. This is the first thing that applying for software-related funding afforded me: the context of the problem and the roles surrounding research software. At the time, I was a support engineer looking after disk platforms, HPC and systems across the British Antarctic Survey (BAS), having originally started with developing operational data management systems in Antarctica (you can find the obligatory link to photos here). The Natural Environment Research Council was shifting (though I didn’t have that broad a view at the time) towards awareness of digital and I was exercising my reasonably long career as a software developer to (a) be a pain in the neck and (b) help carve out the role of software engineers (not necessarily limited to research compute) in the organisation. I should add that many, including but not limited to senior research and technical staff, were aware of a need for it, but struggled to develop the sentiment, narrative or business case for it.
To that end, I had applied for the EPSRC RSE Fellowship, which I didn’t get, and tried to bolster my agenda through the SSI Fellowship (an organisation I knew little about), which I also didn’t get. I won’t lie in saying that the future of my role as a software engineer in an organisation that didn’t explicitly have that capacity looked bleak, especially given the friction I was causing working outside the role I was employed for. Even more so as I had come from an industry that was far more financially rewarding, though at the expense of variety and innovation.
This is where I learned my second lesson about the research world: simple undertakings have chaotic effects, (from experience I know) much more easily than in industry. At this point, I had positioned myself to head up projects within IT at BAS, as well as contribute existing knowledge. I had also used a simple approach to software engineering to build a tool that really helps our researchers interact with the HPC at scale. My RSE Fellowship application had been noticed by our science director and the head of the newish AI Lab (who I was regularly supporting), and I had practised applying for funding applications.
RSEs were now on the radar as something we needed to employ and I was in the fortunate position of having shown what they could do for BAS already. We definitely didn’t have a massive deployment of investment and a sudden influx of technical staff (sans strategy), but we did open an RSE role, which I applied for and got by describing educating on six simple engineering practices as key to improving software sustainability and collaboration: architectural design, iterating development, coding style guidance, interface development, debugging and optimisation strategies, and defining workflows.
Later, I got the SSI Fellowship. The difference between 2021 and 2022 is that I had an agenda to carve out software engineering as a practice. The community at the SSI offered me opportunities to engage. I created my profile on the SSI website and presented at the first Collaboration Workshop I attended on a concept I thought translated from my industry experience to research software. This was one of the best things I did as it taught me the third important lesson of my research software experience: that you should offer information freely. Saving face is pointless if not doing so helps others understand new concepts. I try my best to undertake my role(s) this way, even if I don’t always manage it (it’s hard to evaluate your own performance!)
To that end, I undertook a wave of public-facing activities thanks to this Fellowship that are imperative for a researcher, but you wouldn’t have to bother with in a corporate role. I spoke on a Code for Thought episode and co-wrote a blog at CW22 (Visibility of Research Software Engineers in research funding) and CW23 (Tracking the environmental impact of research computing). I particularly enjoyed the latter due to the importance of the subject and the wonderful group effort involved). I tried to engage this open discourse about what I was doing through SSI blog posts such as Lessons from my SSI Fellowship: first half(ish) and Collaborations Workshop 2023 live blog.
Finally, I spent most of 2023 trying to fulfil (at first unsuccessfully in October ‘23 and then successfully in February ‘24) my Fellowship goal: “Using the Fellowship funding I propose to run a public, hybrid webinar for RSE/AI communities with talks”. This was, I’m not unashamed to say, something I found a complete departure from what I like doing, but that I felt really needed to be achieved if I was truly living up to “acting as the public BAS champion of software in Polar Science”, which is what I said I wanted to achieve with the Fellowship and my RSE role. That event ran on the 6th and 7th February and is described in this blog post. The net benefit of that is outstanding but chaotic, and I’m bloody happy I stuck to the goal I set myself despite moaning about having to live up to the expectation I set myself. At the beginning of this year, I was happily involved with the professionals working on the Collaborations Workshop 2024 (CW24) steering committee.
What I haven’t mentioned is how the chaotic outcomes translated into my role. Well, by undertaking all this and trying to be a software engineering champion, I got involved with polar research software engineering as a role. In doing that, I proved that RSEs play an important role in research, which since has led to the formation of a small team (as of late 2023), which I can now try to shape with my evil, domineering (no, no, wait, stream of consciousness, whoops…), kindly and benevolent software engineering agenda.
This is another lesson: if you have an agenda that is for the good of others and work to fulfil it, those activities will ultimately be beneficial even if they’re not planned from the outset. The agenda is important, but how you fulfil it is not always driven by your agenda but by a broader set of influences and making the best of the situation.
So now that I lead a Digital Innovation Team full of diverse skillsets, both digital and non-digital, and have to consider those wider implications of what we do, I’m trying to work out what the agenda is. What do I concentrate on? What do I ignore, delegate or get engrossed in? How should I help people now that I have line management responsibility? How, most of all, should I communicate now that I’m getting older and looking at the personal implications of what I’ve done, right or wrong, throughout my lifetime?
What small impact can I deliver before I’m no longer capable of working, due to tiredness, health or other life influences?
The last observation I make now, as I’m in a new decade of my life (you guess) and have accepted (as industry never got me to do this) line management as a role I will at least try to be successful at, is that it pays to write, to describe, to reflect upon the timespan of your endeavours. I didn’t realise how consistent my agenda was and it hasn’t changed much, but I didn’t realise until writing this how much the things I’ve done in roughly three years have formed me. The approach has changed though, and I don’t think I’ll ever stop being an SSI Fellow in my heart, but I need to look at how the outcomes from this period can really benefit others, so my future activities will be very different from what they were in 2021.