Update: We now are an official association!
I recently attended the first Workshop for Research Software Engineers at Oxford University. Organized by the SSI, I was on the steering committee and this event came out of our position paper last year. Hot on the heels of a recent article in the Times Higher Education, the aim of the workshop was to bring those people together who work in research labs but actually spend most of their time writing software.
Topics of discussion focused around the importance of software in research, software development workflows, quality control, notable tools, getting recognition for software (a real problem in academia), the role of funding bodies, and career progression.
The 50-odd delegates were mainly from academia though there was a good industry presence as well. The workshop was run in unconference style and keynoters were Ian Gent from St Andrews University and Mark Hahnel from Figshare. Ian talked about the recomputation manifesto he put together with the aim of ensuring that all computational experiments are, and always will be, reproducible (avoiding another SHRUDLU incident). Mark gave an overview of Figshare, an online platform for sharing research output (images, movies, code, …) and ensuring it was citeable.
The remainder of this post is a brain dump of some of the things I jotted down throughout the day. Other writeups were done by Mia and SFTC and there is of course the full archive in the google group.
- Ian Gent rightfully reminded us of the #overlyhonestmethods hashtag trend earlier this year. Funny because its true. So actually, not so funny.
- Mark Hahnel mentioned the Welcome Trust and the National Science Foundation were starting to take software more seriously and move towards requiring code to be open and available.
- The EPSRC guy present mentioned that the same thing was happening for datasets at the research councils but that software was lagging behind. E.g., the REF2020 makes no mention of software apparently. Quite disturbing.
- Figshare has seen some impressive adoption and seems to be working very well. There is still the issue about how to properly integrate support for code & the associated license mess. There is no point in cloning Github, maybe the liaison with the Mozilla Science Lab provides some answers here. Suggestions were welcome.
- The discussion about paper equivalence for software & associated career issues came up time and time again. Some fields have sorted this out better than others (e.g., bioinformatics) and some universities are starting to see the light (e.g., UCL) but there is still a lot to do on this front.
- The chicken & egg problem of sharing data & code came up: I’ll only share mine if you share yours.
- There was some complaining that RSEs are not tech support, and no we will not fix your computer.
- Problem: how do you cite contributors to code, especially if they have actually done more work than the original developers. Making snapshots citeable was mentioned as a solution.
- There is a big gap between the courses offered by the Software Carpentry people (very introductory) and the £10k courses offered to large corporations. Where are the affordable but advanced courses in python, R, data management, agile teaming, etc. Something we can offer ourselves in a P2P fashion?
- Some debate over the “Research Support Engineer” & “Research Software Engineer” terms.
- There was a good breakout session on software quality which came out of one of my suggestions. RSEs are typically surrounded by domain scientists and are usually lone rangers when it comes to their own expertise. In other words, it is up to them, and only them, to ensure the software part of the research is up to standard. The problem however is how do you know the solution you are architecting is really the best one or how do you ensure you are doing things “properly”. In a traditional software house you will work on the same codebase with multiple people. However, when operating alone you have nobody to challenge your approach, bounce ideas off of, make you aware of new techniques, etc. How do we ensure RSEs in those situations are doing the best job they can? How do we ensure they don’t become complacent and that their skill level is not only maintained but pushed forward. The code review work Mozilla Science labs is doing is a good step I think.
- Associated with the previous point, how should we be interviewing RSEs? There is a lot that can be learned from industry here.
- In all of this we were reminded many times that industry should not always be seen as the ideal gold standard. As Jeff Atwood has taught us before, fizzbuzz still has its place. The counter, what skills does an RSE have that a regular developer does not, is hardly every discussed.
On the whole the event went really well. As far as I know this was the first time such a community was brought together, something everybody appreciated. It really struck me how everybody had a very similar story in what drove them to attend. It also struck me how there were quite a few people who “went the wrong way”, i.e., crossed over from industry into academia in search of more interesting work and a better quality of life.
I think more questions were raised than answered but the fact that everybody was keen in being part of a connected, formal, community (which is where this is going) was a good sign. Industry sponsorship was mentioned as a way to get some funding.