back to the schedule

Research Software Engineering: the growth of a movement

Alys Brett

The importance of Research Software Engineering as a role, a discipline and a community is becoming more and more widely recognised because it is essential for harnessing the opportunities and of modern, computational research. Alys Brett is head of the Software Engineering Group at the UK Atomic Energy Authority and founding president of the Society for Research Software Engineering. She has just handed over the leadership of the Society after several years in that role. In this talk she will share the experience from the UK of building recognition for the RSE role and developing groups, career structures and communities, and reflect on where we are now with this international movement.


Questions and comments

  • Can a research software engineer be also a "research data engineer" or do you think we will need a new "RDE" role?
    • I think RSEs often need to do a bit of everything so in some projects they will be the data engineer and will probably need to be able to navigate the basics and research the rest. There definitely are distinct roles relating to research data engineering and management though and we should promote recognition of and collaboration with these complementary roles too. I have an RSE team and a research data engineering team in my group and there is a lot of overlap in skills but some greater emphasis on devops and data management over numerical modelling and statistical methods in the data-systems-focussed team.
  • Related to the above, how does RSE relate to many other 'support staff' kind of role, even if software is not their main focus?
    • In the UK, some RSE groups are part of Research IT services departments and some are within academic departments. Similarly, individuals will have different kinds of contract. In some places the distinction between researchers and support staff is very rigid and limits what you can do, and in others it is more flexible. We have found there is no one size fits all approach to how to make it work which is one of the reasons starting such a group is hard as you have to get into the specific way finances, contracts, HR etc work in your institution. The words "support staff" can be a bit controversial, partly because of the hierarchical culture in research (which is a problem in itself). I prefer to talk about "specialist roles" and "professional collaborators/consultants" in various fields to set the expectation that RSEs and researchers are collaborating as equals with complementary skills. There can definitely be a similar model in non-software but research-related specialist roles and common cause in developing the culture and the structures to support those careers and skills.
  • What might the value be for an RSE group to hire a software engineer that has not worked with researchers before?
    • [name=a] I think there is value in there. As an RSE you naturally tend to split your time between doing, teaching and learning. Having a dedicated Software Engineer with experience churning out good quality code and familiar with the necessary concepts can be very useful. I've generally had people like that close to me and it's useful to bring them in to give talks, help with course material, workshops and so on. They also get something out of it - experience in working with researchers.
  • For the researches who were not exposed to software engineering in a formal way, there are very little opportunities to get the best practices. There are no university course for such things either. How do we fill this vaccume?
    • Software Carpentry Workshops aim to introduce "basic lab skills for research computing" in a 2-day workshop (eg programming, version control and Unix shell)
    • CodeRefinery! More advanced for practicing researchers.
    • Increasingly part of Researcher training programmes. RSE groups in UK often run training and some teach parts of undergrad and postgrad courses
    • On the job... Richard is covering this well :-) pair programming and informal interaction with people who have the skills along with workshops/online courses etc, but need the culture in research to value and support this
  • Whats the relationship between RSE and the more narrow "Bioinformatician" role that has gotten more traction and recognition over the last couple of years?
    • I think about it in terms of overlapping communities, so bioinformatics is a possible specialism for an RSE and some (most?) bioinformaticians will regard themselves as RSEs. I have heard the term "pet bioinformatician" used by people who were the sole person doing the programming for a group and feeling a bit isolated/unsupported so I think they can benefit from a wider community and the strong overlaps with methods and tools used in other research fields.
  • Is there a "career path" for RSE in UK now?
    • It's not a completely solved problem, but the larger RSE groups will often have RSEs at multiple grades so there is scope for progression. In my group there are four levels: graduate RSE, RSE, Senior RSE and team/group leaders which are the same as levels in research groups. For RSEs in research roles
    • Depends very much on the group. For example, I was employed as an RSE but to get promotion I was treated like a PostDoc and required to publish papers. I think it needs a department head who understand the problem and who they have, otherwise they lose them.
  • In my department people (i.e., professors, researchers, managers, etc.) do not understand the difference between RSE, post-doc or teaching-assistant: they treat everybody in the same way (although we all have different salaries, duties, etc.) and expect all of them to support them, their research and their teaching, in the same way. How can I/we make them understand what RSEs are?
    • Influencing professors is possibly the hardest part of this whole effort. I don't think there is a magic answer but when RSEs are in demand from multiple groups they are in quite a strong position to explain how they can best use their skills to collaborate and to prioritise projects where they can make the most effective contribution. Some groups have written down criteria for accepting projects that include the ability of the research group to work with them effectively and the opportunity to transfer skills to the researchers. Also, they sometimes listen more when they hear it from outside so getting talks (or a couple of slides in a talk) about what RSE is into big domain conferences can be good.