An interview with a research software engineer

Having loved physics and coding since high-school, Ania Brown was always set on a career that married the two together. She first undertook an undergraduate degree in Physics and Information Technologies in Australia, before studying for a Masters in Tokyo and beginning a PhD at the same institution. After finding that typical academic life was not for her, Ania chose to leave the PhD behind and moved to the UK to take up a position of Research Software Engineer (RSE) at the University of Oxford, which perfectly combined her desire to work in physics research and in software development. Ania worked on multiple projects in academia and is now moving to industry to see how the role of Research Software Engineer is different there. We caught up with Ania to find out more about her career path, what it was like working as a Research Software Engineer in quantum, and her hopes for the future.

You are a Research Software Engineer; can you tell us a little bit more about what this means and how it is different to being a software engineer within a private company?

I tend to define a Research Software Engineer fairly broadly as anyone who works on codes with research applications and has some familiarity with the research process, but who spends a significant fraction of their time writing code. Generally, most of the people working as RSEs have some background in doing their own research, though like me a fair number don’t have a PhD — it might be a Master’s degree or an undergraduate research project. Some people like myself specialise in a particular technology rather than a research area, for example my specialisation of high-performance computing (HPC), whereas others may like web development or data science, and are able to apply that to many different domains. This means that we rely on others to provide the context to make sure that what we’re developing is of use to researchers. At the other end of the spectrum you could have someone who really specialises in one area and who does their own research too.

Compared to a traditional research position, RSEs tend to have more focus on good software practices like documentation, testing and code maintenance, which can be difficult to justify spending time on when your primary research output is expected to be papers. And then the close involvement in the research process means it looks a little different to typical software engineering work too. Even a generalist RSE like me needs to interface regularly with domain experts to clarify the code specification, which typically is a lot less firm for a research project than for an application for a private company (and might change a lot when the research takes an unexpected turn), and to design tests to prove the code is correct. An RSE who is also a domain specialist might additionally be designing the algorithm used and coming up with the research questions that the code will be answering.

How did you get into being a Research Software Engineer and to working in quantum?

I knew since leaving high school that I wanted to combine programming and physics in some way, although the career path has been fairly winding, which I think is fairly typical for RSEs! I studied for a dual undergraduate degree in Physics and Information Technology in Australia. While there was not always an obvious overlap between the two degrees, there were some scientific computing and high-performance computing courses that I found had that nice balance between practical work and interesting theory that I was looking for, so that’s the direction I’ve gone in. I took up a Master’s in Tokyo in the Department of Energy Science, working on a coding project on GPUs (Graphics Processing Units), and while I really enjoyed the work, I realised eventually that I was being evaluated based only on the research papers that I wrote when what I really wanted to do was write a code for other people to use and to do science with. At this point I was one year into my PhD and my partner found work in the UK so I was looking to transfer my PhD there, but I saw the position of Research Software Engineer advertised at the University of Oxford e-Research Centre, which didn’t require a PhD and was basically exactly what I wanted to do – support research by writing codes and making codes run faster. I applied and I was very fortunate to get that, and then to additionally find a whole community of Research Software Engineers in the UK who had very similar experiences to me.

At Oxford, I worked within Dr Ian Bush’s HPC group on a quantum computing project, QuEST, as well as codes for plasma physics and radio astronomy. After that, I moved to the Research Software Group at the University of Southampton for two years, a generalist group that serves the entire university and is very closely involved in RSE community building work as well. I’ve just finished there and I’m now heading to industry and will be working for NVIDIA, where again I’ll be in a research-facing role working with research codes.

After working as a Research Software Engineer in academia, you’re now taking the leap to work in industry. What made you make the change?

I've always assumed that I might move between the two because I knew I wasn’t on a typical academic path, and while there are ways for people in the RSE role to progress within academia, those routes are still in development and there aren't very many of them. Academia is set up to evaluate you based on the research papers you write and not on things like spending time maintaining code, speeding up code or that kind of thing. It's better than it was, and it is possible now to be senior and not really write that many research papers, but it’s not common yet. I think being willing to work in industry as well opens up a lot more options. I also think it’s useful to get some mixing between academia and industry to bring in technical expertise — this new position is going to let me specialise deeply in GPU programming and optimisation within high-performance computing, which is something I’m really looking forward to. Finally, a big factor for me is the ever present two body problem. My partner is an academic and now that I've found an international company to work with that might make the next move easier. For me the important thing is to stay tied to research in some way, and in my new role I will be working in industry but still on research codes — I’m interested to see how it’s different!

Do you think it is common or easy for research software engineers to move into and out of the field of quantum and into and out of academia?

I think it’s more common for RSEs than for typical academics to move between academia and industry — I wouldn’t say there’s a huge proportion of people doing it, but I definitely know people who have made that move in both directions, and I’m hoping I haven’t closed the door for myself to come back to academia at some point either!

It’s certainly possible to move between different fields, such as quantum, as an RSE. One thing that’s becoming more common is for universities to support a central group of RSEs that works on research codes across all departments in the university. If you’re the kind of person like me that likes to learn a bit about a lot of different fields, that kind of group can let you work on a wide range of different projects. There’s a trade-off there of course — if I specialised more in quantum the additional context would make it easier to spot potential errors in my code or come up with relevant new features, but moving around different fields lets me learn HPC techniques from one field and apply them to different fields. I think we need a mix of generalists and specialists.

As a software engineer you can work in a variety of different fields; what was it that attracted you to working in High-Performance Computing and in particular, quantum?

I think it’s really interesting physics! I enjoyed the quantum courses that I studied during my degree and it was nice to have chance to learn some more about it. I also assume that I’ll be writing code for a quantum computer as part of my job within my lifetime so I’m pretty invested in how things turn out.

High-performance computing involves using large scale computer systems to create simulations and perform data processing. Beyond just finding big simulations cool, I enjoy the process of modifying codes to run well on these systems. I find the hypothesis testing that you go through to figure out why a code is running slowly and which resources are being used by the code really satisfying, and it’s always nice to be able to tell a researcher that they no longer have to wait as long for their results to come back or that they can simulate a larger scale problem.

Is there a particular area of high-performance computing that interests you the most and if so, why?

I've always enjoyed working with GPUs which are massively parallel computing devices which were traditionally used to display computer graphics and have been used for some time for general purpose computing as well. While you can’t map every problem onto a GPU, many scientific simulations are regular enough to work well on that architecture, and the performance improvements in that case are often pretty spectacular.

You worked on QuEST (the Quantum Exact Simulation Toolkit), can you tell us more about what that is and what you did during your time in that role?

QuEST is a code that simulates quantum computing circuits on classical computers, it’s run by the QTechTheory group at the University of Oxford. I received that code as a prototype that had been optimised to run efficiently on a single computer but couldn’t run across multiple computers, which limited the size of the problem that could be simulated and how fast it could run. My role was to modify the code to run on a traditional supercomputer (multiple computers wired together by a fast interconnect) and, because I’m always interested in GPUs, I also added a GPU version which increased the speed of code pretty significantly for smaller problem sizes.

The other nice part of that project was that I was given enough time to work on the sustainability of the code — I added documentation, a test system and version control, and we released the code open source on GitHub. I was also able to work on the usability of the code— it was important to us to make the code easy to run for someone that didn't have a high-performance computing background on whichever architecture would be most efficient, without needing to go into the details of that architecture. Building on that foundation, members of the QTechTheory group have enthusiastically taken on development of the code after me, and while I don’t work on the code any more it’s really nice to see that it’s still being used by the community now.

What are your hopes for the future?

I've been heavily involved in representing people that are on this new career path and that's very close to my heart. I think as things are, it can be isolating and disheartening at times, just because of the lack of people doing the same work as you in the same group or department, and the lack of recognition for it because of the way the structures are set up. I think the role of Research Software Engineer forms an important part of scientific computing and research, so I hope that there's a bit more support for people in that role in the future. I've just recently finished a two-year term as a trustee of the Society of Research Software Engineering and hope that people are able to find more support there too. It's been interesting to see how much response there has been to some of the work I've been doing in this community, how happy people are when they find that there are other people doing the same kind of work and how useful they find it to be able to talk and share technical information along with just knowing that there are other people in similar positions. On a personal level, I just hope to be able to keep doing this kind of work. As I've said, it certainly strikes a fun balance for me in terms of getting to learn about really interesting science and then getting to solve interesting problems with programming as well.

What would you say to young people who are considering pursuing a career in STEM, particularly in a role like yours? Are there any skills that they should look to develop to help them with that?

I feel like I should start by saying to be aware that there’s some risk involved in that following the same career path as I’m on makes it a lot harder to get a typical role in academia, if only because you likely won’t be writing as many papers. I think there will be interesting work out there for you, but it may involve a step like moving to industry or working in a central RSE group. That said, there are more and more people out there doing this kind of work, which is promising, and obviously I have found it to be worth it.

In terms of skills, I would say that problem solving is more important than knowledge. A lot of the work is about being able to figure out things and not being scared to start working on a problem initially being confused about how to solve it because a lot of what we do is either working with new technologies for each different project or working in different application areas. You’ve got to be happy to take on new things and learn as you go. It’s also important to be comfortable with the idea that you can never know everything in this, because you're going to be moving around so much. You will work with different programming languages, frameworks, technologies and hardware, especially if you work in a team that serves, for example, an entire university. Communication and collaboration skills are also important — you’ve got to be able to translate between tech specialised language and research domain specialised language.

Finally, I have found having access to a community of people like me incredibly helpful, particular for a career path like RSE which is still a bit odd and new. If you’re looking for support or to learn more, I would check out the RSE jobs board, and the RSE slack channel where you can find thousands of people in similar jobs and ask either career based or technical questions — it’s a very welcoming space in my experience.

‍