In the world of research software, it’s very common for a single student to propose (and publish) a new method, then graduate. This is good for everyone except the next person who needs to use the method: issues of code quality and knowledge transfer are widespread, to the detriment of reproducibility.

One of the minor functions of my job, then, is to introduce ideas from the world of software engineering to our research-oriented colleagues. Most recently, I’ve been talking about code review; the slides from this discussion are available should anyone find them useful. Many thanks to the fine folks with the US Research Software Engineer Association (US-RSE) for feedback, suggestions, and improvements along the way. Changing the standard of practice is hard, and it’s a true joy to find people organizing around a common need.

Each time I give a presentation, I try to experiment with some change in style, content, or pacing. In this case, the slides are very text heavy- more akin to lecture notes that a true “slide deck” of the style that has become popular. This is a reflection of the fact that code review is a human process that happens at the project and team level: I can introduce the idea, but actually implementing it will require guidance, support, and further reading long after the talk is over.

These slides were for an internal discussion; for a more formal presentation, I’d probably break those references out to a separate set of handouts, and include some more specific domain examples based on the target audience. Thankfully, modern services make it easy to grab the slides and related content from a URL for later reference; I would like to see repository links become a “default” practice for speakers and conferences.

Like many software engineering practices, small steps to improvement are the goal: no single change will lead to perfection.