By SSI Fellow Colin Sauze, National Oceanography Centre.

This blog post is part of the Research Software Camp: FAIR Software.

Coding Confessions was created at a Hackday during the SSI’s 2021 Collaborations Workshop. The idea is that software developers “confess” some of their past mistakes. Everyone who writes software makes mistakes and normalising talking about them will help prevent them from being repeated,  it will ease impostor syndrome and help new software developers to feel more able to talk about their mistakes and ask for help. Ultimately we hope this will contribute to improving the mental health of software developers. 

We ran the first Coding Confessions at SeptembRSE in 2021, this was an online event and we managed to find six RSEs willing to give their confessions. Each was given five minutes to describe their mistake, its impact and how to prevent it from being repeated. We also set up an anonymous online form where other people could submit their confessions. Both these and writeups from the live events were published on our website. We’re hoping that through these writeups we can build up an evidence bank about common coding mistakes and how to avoid repeating them.

At RSECon2022 we ran our first in-person Coding Confessions session, with seven panellists agreeing to appear. As before each had five minutes to give their confession. We also took anonymous submissions via our website. 

The panel for this event included:

• Sadie Bartholomew (University of Reading/NCAS)
• Anika Cawthorn (UCL)
• Linus Gasser (EPFL)
• Daniel S. Katz (NCSA, University of Illinois Urbana Champaign)
• Callum Mole (Alan Turing Institute)
• Mark Woodbridge (UK Dementia Research Institute)

Some takeaway points from the confessions and the discussions that followed:

• Don’t deny that your code might be the cause of a problem.
• Don’t leave debug print statements in production code, they can end up in logfiles and fill up the disk.
• Get somebody else to stress test your application before it is deployed.
• If you’re the one receiving code from somebody else to deploy, test it yourself before deploying it. 
• Make sure you aren’t overwriting your previously saved data.
• Write extensive tests to ensure your software is behaving as expected.
• Get somebody else to review your code.
• Be sceptical of code you receive from others and test it as if it came from somebody you don’t trust - regardless of your relative level of seniority or experience. Excessive trust can lead to an unjustified - and risky - reduction of scrutiny.
• Don't leave code in a broken state, fix things that you know need fixing.
• Have a quality assurance process in place.
• Even if you are lucky enough to have a comprehensive test suite and/or manual testing procedure, take time to consider the broader consequences of any code change. It might look (and even be) correct in isolation, but this doesn’t mean it won’t have unintended consequences. If spotting this relies on knowledge of the system as a whole, consider how this knowledge can be represented in the system itself.
• Use an issue tracker to track bugs, use version control (E.g. GitHub) and create a new branch for each bugfix. Merge these back to the main branch and get somebody to review the code in the Pull Request process. 
• Problem-solving is something many software developers enjoy, but make sure you’re solving the right problem.
• Context switching can cause a loss of focus. Keep some notes on what you were doing to help refamiliarise yourself with what you were working on. 
• Don’t change so much of your collaborators' code that it takes away their sense of ownership of it. If you change the code too much they won’t understand it or feel they own it and will avoid using it.
• Target your optimisations to code that runs frequently. Optimising rarely used code is unlikely to help overall execution time.
• Beware of variable ownership when variables are shared between functions or threads. 
• Rust has lots of good features to solve some of the problems of variable ownership. 
• Don’t be too critical of yourself when learning a new programming language, it will take time.
• You will find yourself using the style of languages you’ve previously learned when using a new language. 
• Researchers (and RSEs) are often perfectionists, don’t burn yourself out trying to make something perfect. 

Links

• Coding Confessions website
• Video of the RSECon2022 Coding Confessions event
• If you would like to add your confession to our blog, you can submit it using this form.
• A blog post about a previous Coding Confessions at SeptembRSE in 2021.