Bingo. And it goes vice-versa; because software engineering standards are so lax (read: non-existent) in most academic disciplines and domains, on the rare occa

Bingo. And it goes vice-versa; because software engineering standards are so lax (read: non-existent) in most academic disciplines and domains, on the rare occasion where you get accompanying code to an academic work it may be impossible to actually much of the source to the original work itself. During my dissertation I had to collect implementations of about a dozen parameterizations of a process I was studying, with the intent of coupling them/incorporating them into a set of climate modeling experiments. All of the implementations were in Fortran (which in and of itself wasn't a problem, albeit it was annoying re-writing or re-factoring some F77 code to play more nicely with the more modern Fortran codebase in which our climate model was written). Of these codes I collected, the majority of them had bugs which restricted my ability to reproduce the reported results from the original work they accompanied. One or two of them had significant flaws in them - answer-changing bugs which, when corrected, potentially would yield different results from those reported in their original papers, and might actually lead to different conclusions. One of the nice things about the Jupyter ecosystem of tools and Julia is the ability to more closely replicate equations from the original paper. It seems dumb, but in my anecdotal experience I've noticed fewer significant bugs when colleagues have used these features. I've also noticed a propensity for scientists and researchers to write clearer, better-documented code - if your next line of code is going to directly mimic Equation 13 in your paper, why wouldn't you go ahead and write a comment saying so?