At my job, I’m currently in a cycle that is involving working with software engineers quite a bit. One thing that has happened a number of times is that a software engineer will bring up “research code” with a condescending tone. The implication is that research code is messy, unreadable, and difficult to maintain.
I don’t deny this! It often is those things, but I also think it has a beauty to its purpose and prose that is worth acknowledging.
Most code has a purpose from the get go. Someone thinks “wouldn’t it be nice if my computer did <x>”, then designs and builds the code to achieve <x>. Generally you know where you want to end up and how to get there fairly early on in the project. This makes writing design docs, unit tests and a coherent software architecture possible.
Research doesn’t really work in this way. It is similarly goal oriented, but the distinction is that you never really know exactly how you’re going to get to the goal. You constantly poke at the unknown until something “works”. You get stuck in iterative loops improving small aspects of your design over weeks or months – which naturally causes it to evolve. At the end of the journey the goalposts have moved, more often than not.
In such an environment, you take notes rather than write design docs. They describe where you’ve been and why the things you tried didn’t work. You test one-off implementations directly rather than write unit tests. If something works, you cement it in place as a beacon marking a step towards your goal. If you’re fortunate enough to be working on a problem that allows evaluation metrics, you might record the eval scores you achieve. It might make sense to write a unit test here, but it’s often easier just to treat the beacon code as immutable and branch off of it.
I love this way of iterating on a problem. I always have, well before I joined the field. It’s haphazard as hell, but it also feels as close to “art” as I think programming will ever get. Let me explain that a bit: art is more often then not about individual expression. Programming for most large companies is explicitly not that: it’s about writing in common language with your fellow programmers as well as sharing “cultural norms” like coding conventions, reviews and tests. There are good reasons for all of these things! But the end product is rarely “art”.
By contrast, the code that a researcher builds is a product of the interaction between their individual ingenuity and the real world. It’s organic and complex and two researchers tackling a similar problem rarely come up with the same code at the end of the day. I call that “art”.