Good Code, Bad Code?
or, How to Get the Best From Your New RSE
In March of this year, as the government began introducing lockdown measures, Prof. Neil Ferguson, the epidemiologist whose disease models were informing government policy, tweeted:
If you know anything about RSEs, you can probably imagine the shudder that went through the community … the next couple of months saw “professional software developers” denouncing the code, and RSEs and researchers responding. I don’t want to retread that ground here (I’ve linked a few of the responses at the end of this story), but it provides useful context for thinking about both the why and the how of Research Software Engineering.
The why part is increasingly well-recognised: researchers shouldn’t be expected to write “Good” code. It’s not their job, after all. But just because code isn’t “Good”, does that automatically make it “Bad”? If code reliably produces the right results isn’t it “Good-Enough”? And that’s where the how comes in — finding the “Good-Enough” in your existing code, and helping to make that “Better”, or hopefully even “Good”.
If you’ve already decided to work with an RSE, you’ve taken an important first step, so here’s some extra hints and tips for working effectively with your new RSE.
Share your existing code
This may seem obvious, but RSEs can only really help if you’re willing to let them see what you’ve already done. A surprising number of academics are reluctant to share; perhaps a consequence of competitive funding models and the push to publish novel results, or perhaps simply out of a degree of embarrassment (don’t be embarrassed; your RSE has probably seen worse). Don’t worry if you’re sharing code by putting it on a USB stick or emailing a zip file; part of your RSE’s job is to meet you where you are, then lead you towards best practices.
Acknowledge the strengths of your code
All too often one of the first things a researcher does when meeting an RSE is to apologise for their existing code and highlight its failings. Please don’t! You probably wouldn’t be talking to an RSE if your code was already “Good”. Instead, focus on what works — explain the inputs, explain the outputs, detail which bits of the code you think work well, discuss how you validate the results. This helps your RSE understand what you’re trying to achieve.
Be ready to learn
It is possible to work with an RSE by pointing them at a problem then standing back, but that’s not the best way. Part of the work of RSEs is to embed best practice back into research units, leaving you confident in your own ability to developer “Better” code in the future. This could involve learning new software, programming languages, techniques and development concepts. Your RSE will try not to overwhelm you, and will tailor their input to your level of technical knowledge as much as possible!
Be ready to teach
Similarly, your RSE is there to learn about your research and your field. Obviously, we can’t become experts overnight, but the more you can teach us about your work, the better we can understand your requirements and help you improve your code.
Try to have fun!
With your RSE helping to solve your technical challenges, you might find yourself dreaming of the stars. Do it! There’s nothing your RSE will enjoy more than exploring new possibilities for your research that can be enabled by their technical expertise. Research remains at the core of RSE, and our primary purpose is to make your research better. If you think we can do that, just ask.
In Summary
Having an RSE on your project should be an enjoyable and productive experience; we’re there to bring technical expertise and share knowledge, but also to learn about your research and help drive you forward. Prof. Ferguson has brought in expertise to help improve his modelling code, and you can get that help too — from your own university’s RSE group*! Welcome us in, share with us, and above all, don’t be embarrassed about where you’re starting from. We’ve seen it all; the “Bad”, indifferent, “Good-Enough”, “Just-Starting”, and we’re here to help you move through “Better”, and hopefully to that ultimate prize: “Good Code”!
*the Society of Research Software Engineering maintains a list of RSE Groups
The following articles were written by researchers, developers and RSEs in response to criticisms of Prof. Ferguson’s Covid-19 simulations:
