Vol. 15 - Maintaining scientific software is a great idea!
The slow, meditative art of maintaining scientific software and learning through code.
Last week (plus or minus a one-week break because I was part of a grant panel), I listed a few reasons why maintaining scientific software is more challenging than it seems.
And yet — there are some excellent reasons to invest some time and energy in this task, and I want to discuss a few that are not “it benefits the community” or “you can turn it into a publication”.
One of my favourite features of software development is that it is slow work. Very slow, sometimes: there is a GitHub notification in my inbox from an issue that was opened in 2012, after a discussion on Twitter involving a few users and maintainers of a specific package. This package is not broken, the code covered by this issue is not wrong. But the consequences of making one specific change are taking a long time to play out.
In virtually all other areas of our job, we are being chased by deadlines constantly. Being able to look at a situation and say “I will fix it” without the need to answer when is incredibly liberating. This lack of deadline gives space, it gives time, to build the things we want to build whenever we feel like building them.
This is not always true. I have fond memories of building tools in the first few months of 2020, powered only by energy drink, severe sleep deprivation, and hubris, while sending 6000 Slack messages a day. Every so often, we gotta build tools to get shit done; most of the time, it is not a world-altering incident if things wait for a few weeks, or a few months.
Building software is also a good way to learn something new. If you can’t explain it to a programming language, you do not understand it yourself, and all that. I spent a few days reading about Bayesian Additive Regression Trees, and this was a great way to get what they were about; moving to the implementation was the best possible way to get what they actually are. The language of code does not handle ambiguity well (at all!), and the profound understanding of any analytical process that comes from reducing it to a series of clear, atomic instructions, is almost impossible to achieve through other means.
The truth is that committing to a piece of code for a long time is meditation. How it started, or where it is going, are less important than putting in the work.
And with all that said, stay tuned for Vol. 16 next week, for a discussion of collaborative writing, and how to make it great.