Coding confessions

Posted by j.laird on 9 November 2021 - 2:00pm
coding confessions
Image credit: the authors

Colin Sauze, Eirini Zormpa, and Patricia Herterich reflect on the organization of the first ever Coding Confessions panel at the SeptembRSE conference.

This blog post is published as part of the Research Software Camp: Beyond the Spreadsheet.

Introduction

Everybody who develops software has at some point written some software badly, quickly, cut corners or simply made a mistake that made it function incorrectly. The current research culture does not encourage sharing these mistakes openly, thus making it difficult for others to learn from others’ unsuccessful attempts and avoid similar issues.

Coding Confessions was created as part of the hackday at the SSI’s Collaborations Workshop 2021 as an initiative to change the culture of disclosing mistakes and build a collection of stories highlighting failures and lessons learned from them. The initial hackday project included creating a page where submissions can be added and writing guidelines to run a Coding Confessions session at events. 

Our first Coding Confessions Event: SeptembRSE 

SeptembRSE, the Society of Research Software Engineering’s conference provided the ideal opportunity to try out these guidelines and organise a panel to invite the community to confess to some mistakes.

Panellists were invited through an open call published on the Research Software Engineers, SSI Fellows, Turing Way and Open Life Science Slack channels as well as on Twitter. Furthermore, the organisers contacted candidates in their network to ensure a gender-balanced panel.  

The final panel comprised Graham Lee (University of Oxford), Magnus Hagdorn (University of Edinburgh), Ed Bennett (Swansea University), Jannetta Steyn (Newcastle University), Yo Yehudi (Wellcome Trust), and Becky Arnold (Keele University). Their confessions ranged from embarrassing typos in git commit messages, situations when core code for financial databases stopped working and needed to be fixed on urgent timelines, issues with code supporting PhD research as well as core aspects of enterprise solutions not working for customers.

Lessons Learned

  • Know your tools, understand what the library was created for and if it’s really suitable for your solution
  • Being lazy can be good
  • Being lazy can also be bad
  • Document your stuff (and ask others to do the same)
  • Don’t be ashamed to ask for help if it was a genuine mistake
  • Don’t blindly believe the hype about technologies
  • Testing is not optional
  • Close files and free resources when you don’t need them any longer 
  • Ensure that what’s in the loop needs to be in the loop (“Don’t open new connections in a loop”)
  • Test with more data than you’ve been given to ensure it scales
  • Simplicity correlates with efficiency
  • Don’t use anything deprecated, take the hit early and reworking it
  • Pick a few tools that will do the job well
  • You can test your system really well but you still won’t test for every eventuality. Users can be very good at finding the situations you didn’t test for and breaking your software.
  • Don’t leave somebody who’s just started a job with complete responsibility to run a production system without help

Most of the stories that were shared resonated with the audience, highlighting the importance of sessions like this where experiences can be openly shared. It also shows how even experienced software developers make mistakes. New software developers shouldn’t feel scared when they make these mistakes.

In addition to hosting the panel, we also had a poster that allowed SeptembRSE attendees to submit their coding confessions anonymously.

How the event went

Overall this first coding confessions event went quite well. A lot of effort went into trying to get a panel with an even gender split, but this is made difficult by having a community which is male dominated. There were worries at the start that nobody would be willing to confess their past mistakes; fortunately this proved to be untrue. People who were quite established in their careers were intentionally targeted. It was hoped this would help encourage more junior people to submit anonymous confessions. It was also thought that established people would have more stories to choose from and ones which weren’t so recent and that would be less risky to confess. Perhaps in future events it would be worth targeting some mid or even early career people too. 

Find out more

Acknowledgements

The authors would like to thank the session panelists for sharing their confessions, the SeptembRSE organising team for hosting our panel session and the SSI for the financial support to compensate our panelists.


Want to discuss this post with us? Send us an email or contact us on Twitter @SoftwareSaved.  

Share this page