As research software engineers (RSEs) or researchers who develop software & code, at some point we will need to provide evidence that our software actually has some positive effect on the world. Whether this is for career progression, the REF, just for your own peace of mind or any of a whole host of reasons, collecting usage data takes many forms but can often come as an afterthought.
This International RSE day (Thursday 13th October 2022) let’s have a look at how we can plan to collect some evidence to demonstrate the value of our work and hopefully mitigate some potential stumbling blocks in our career progression.
When it comes to ‘traditional research outputs’ (i.e. peer-reviewed publications), the dreaded journal impact factor1 has come to be the de facto standard measure of the quality of a piece of research, however flawed we know it to be.2 Along with numbers of citations3, these measures are a big part of what’s used to determine how worthy the author of some research is of: promotion, funding, recognition etc. But with software, we don’t implicitly have the *ahem* “luxury” of impact factors and numbers of citations so using other ways of showing that our work has merit is something of a necessity, but how do we do that?
Originally conceived as a metric to help librarians select journals to subscribe to, the impact factor is a measure of a journal’s ratio of citations to papers published. https://en.wikipedia.org/wiki/Impact_factor ↩
See the Declaration on Research Assessment (DORA) for more on the movement to improve the way researchers and scholarly work are evaluated. ↩
Flawed for many reasons as well, not least because of the massive disparity in citation rates across disciplines. ↩
Pre-commit is a powerful tool for executing a range of hooks prior to making commits to your Git history. This is useful because it means you can automatically run a range of linting tools on your code across an array of languages to ensure your code is up-to-scratch before you make the commit.
Thanks 🙏 to Neil Shephard for checking though this!
Research Software Engineers are often not much better at actually writing code than any other researcher, we just know a lot of cheats, shortcuts and ways to automate things. I’m going to risk the wrath of my fellow engineers and share some of these here. They will mean you can work a bit faster, but mostly will stop you throwing code away when you come back to it after a few months and can’t figure out what the flip it’s supposed to do.
The RSE Team are pleased to announce three scheduled sessions of the increasingly popular Git & GitHub through GitKraken - Zero to Hero!. These courses will run over two consecutive days in morning sessions from 09:30 to 13:00 on the following days.
Git is a system of version controlling your code. Think of it as a lab-book or doctors notes that are taken as you progress through your work, recording conditions, saving what has worked and correcting what doesn’t.
GitHub is a website that allows people to work collaboratively on version controlled code.
GitKraken is a client for working with Git and GitHub that includes both a GUI (Graphical User Interface) and a CLI (Command Line Interface)
Everyone who writes code! If you write scripts to analyse your code in R, Stata or Matlab you would benefit from using Git to version control your code and GitHub to share your code and make it open. If you write Python, JavaScript, C/++ code as part of a team in your research group you would benefit from using Git and GitHub to work together.
Getting started with these tools can be overwhelming but by taking this course you will be introduced to the concepts behind them and how to use them effectively to not just version control your own work but work with others on the same code.
The course material is available online if you want to take a peek and the first half using Git and publishing web-pages can be worked through in your own time. The real benefit comes from participating in the collaborative exercises in the second half where you work together on projects making Pull Requests and resolving problems that arise.
If you’ve never used Git, GitHub or GitKraken or have only just started then sign-up and come and learn more about these powerful tools.
git
is an exceptionally popular and useful tool in developing software. In the RSE team we’ve been running a regular course on using git and GitHub via a great interface called GitKraken client. Recently, we got together as part of one of our LunchBytes events to share our favourite tools and tips for working with git and GitHub, so here are some of the tools that we saw demonstrations of! You can also see demos of each tool in the video from the LunchBytes session below, time codes are provided in each section.
We want to make our candidate selection process as open as possible. Generally we’re not trying to hire people who can solve software problems on the acute timescale and in the pressured situation of a job interview, so maybe it’s best to share some example interview questions and assessment tools with everyone?
This is a representative example, and gives an idea of what to expect, but the process we use for any specific role may differ somewhat.
We have a job advert out for an RSE! Here are six reasons to apply:
Please view the advert to apply, and see contact details for enquiries about the job. General enquires about the team are welcome at rse@sheffield.ac.uk.
In research, it is of utmost importance to the scientific process to be able to reproduce research findings in order to establish their validity. However, more often than not, the code that is written for research purposes cannot be easily run again, sometimes even by the code’s authour (yours truly included!).
This year, I’ve been awarded a fellowship by the Software Sustainability Institute to develop guidance and training to help researchers who use MATLAB to find and learn the tools that they need to easily produce better research by making their code reproducible.
During my PhD and postdoctoral research, I used MATLAB, among other languages, to analyse data, run simulations, make figures and control instrumentation. However, at the time, I didn’t know about the concepts required to make my code reproducible for myself and others. Over the last few years, as a Research Software Engineer, I’ve gained the experience needed to develop reproducible software in a range of languages including MATLAB. Now it’s time to share what I’ve learned with everyone!
This blog post should serve as a very brief set of signposts to some of the concepts you can use to develop a reproducible project in MATLAB. You can expect more to come throughout my fellowship, so watch this space.
If you’ve been dabbling in programming for a while you may have heard of “linting your code” which is a process of static code analysis to remove the “fluff” from your code. Just as physically linting your clothes removes unwanted fluff, linting your code removes “fluff” and can help…
This helps reduce the technical debt which impacts the amount of time required for maintenance and further development of a code base. The main focus of this article is the use of linting to ensure consistent coding style, it focuses on Python under Linux but similar tools are available for other operating systems and languages.
Due to team member relocating to another country (😥) we have an RSE role in the team at the University of Sheffield. It is role where we are specifically looking to recruit someone with skills in R.
For queries relating to collaborating with the RSE team on projects: rse@sheffield.ac.uk
Information and access to JADE II and Bede.
Join our mailing list so as to be notified when we advertise talks and workshops by subscribing to this Google Group.
Queries regarding free research computing support/guidance should be raised via our Code clinic or directed to the University IT helpdesk.