Evolutions in the Discussion of RSE Career Paths
By Mark Stillwell, Cisco Meraki, Caroline Jay, University of Manchester, Robert Haines, University of Manchester, Louise Brown, University of Nottingham, Jeremy Cohen, Imperial College London, Alys Brett, Culham Centre for Fusion Energy, Shih-Chen Chao, University of Manchester, Raquel Alegre, UCL, James Davenport, University of Bath, and James Hetherington,UCL.
A speed blog from the Collaborations Workshop 2016 (CW16).
Huge progress has been made in recognising research software engineering as a profession since initial discussions about this role began at the Collaborations Workshop in 2012. The topic still gets a lot of coverage at Software Sustainability Institute and UK Research Software Engineer (RSE) events, and with good reason. Many of the basic problems that led to the initial discussions continue to exist: in particular, a lack of academic credit for software contributions, and lower pay in relation to similar industry roles. While these problems remain unsolved and important, the fact of the matter is that people are now carving out career paths as RSEs or managers of RSEs, and new issues and concerns are starting to arise.
The discussion group contained a diverse mix of participants with links to research software engineering: Louise Brown is one of the EPSRC’s inaugural RSE Fellows; Robert Haines, James Hetherington and Alys Brett manage RSE teams; Jeremy Cohen is a Research Fellow in High Performance Informatics; Mark Stillwell, Shih-Chen Chao and Raquel Alegre currently work as RSEs, and Caroline Jay and James Davenport are academics who work with RSEs.
It was clear that enabling a stable career path for RSEs remains problematic. Previously this was due primarily to the short term nature of contracts and uncertainty around funding that affects most post-doctoral researchers. Whilst this continues to be an issue, at some institutions (including UCL and the University of Manchester), permanent RSE posts are now available, regarded by all as a positive step. Concerns are now starting to focus more on recruitment and retention of RSEs, as well as ensuring that there is sufficient flexibility to enable engineers to move back to a primary research role, should they wish to change direction.
There was also a lively conversation about the scope of RSE related activity, which can run the gamut from actively pursuing a research agenda that involves programming and publishing papers, to performing systems administration tasks that would be essentially the same in any professional sysadmin role. There was some further discussion of the various “types” of RSEs, and some people seemed to want to formalise these distinctions, while others wanted to keep this recommendation informal in order to be able to simplify job descriptions for advertisement, and to make it possible to re-deploy people on a variety of tasks without having to change their job title.
One significant concern was the split between academic and RSE career paths at postdoctoral level, and the barrier that this creates to moving back and forth between these roles. Someone may spend time working primarily on software, and in the process develop very valuable technical skills, but there was a perception that these were not always valued in academic circles, and ensuring that people are able to maintain a CV that would allow them switch back to a more traditional postdoc role is important.
Some felt that RSEs should be seen as an integral part of the research team alongside PIs and RAs, and proposed that one way to achieve this is for RSEs to take on a number of duties traditionally performed by academics beyond research. In particular, teaching and grant reviewing seem to be areas where RSEs should be able to make real contributions. There is still a perceived problem of class separation, with academics being “upstairs” and other members of the research team being “downstairs”.
Another issue that came up was how to increase diversity and be sensitive to people coming from different backgrounds. This is not uniquely an RSE problem, and in fact software development in general is not good at diversity. Job Descriptions / Advertisements for “rock star” developers may be perceived to target and privilege a narrow demographic of young male applicants.
The variation in the sort of activities that RSEs engage in, as well as the range of skills and abilities required, can make management a challenge. It can be difficult to get a team with a good mix of skills that covers everything that needs to be done. Also, it’s important to have people rotate through tasks so that everyone gets the opportunity to work on plum projects as well as drudge work. Overall, however, the conversation was positive, and it appears that the RSE role has finally gained real traction and recognition within the research domain.