Software Carpentry

The Carpentries[0] provide some great resources and training for academics who are interested in this. Check out Software Carpentry[1] and Data Carpentry[2] in particular.

Publishing research code is admirable, and in an ideal world everybody would publish their code and data. That said, we shouldn't pretend that there aren't tradeoffs. Time spent polishing your code to make it presentable is time not spent on other aspects of your research. Time spent developing software development skills is time that could be spent learning new research techniques (or whatever). Reproducible research is great, but it's certainly possible to take it too far at the expense of your productivity/career.

You should also take your own personality into account. If you're a perfectionist you might struggle to let yourself publish research-quality code rather than production-quality code and consequently over-allocate the time you spend prettying up your code.

[0] https://carpentries.org/

[1] https://software-carpentry.org/

[2] https://datacarpentry.org/

Really interesting take, very much in line with my experience that scientific code is often broken from a software engineering point of view. Science benefits greatly from using more standard toolkits in open languages instead of proprietary code of any sort. This way the kind of reproducibility the author talks about would be easier to evaluate.

That said, it's often hard in practice. I remember asking a colleague why they were so matlab-heavy when nothing they did couldn't be done in say, python. Their response was that all the previous code in the lab was written in Matlab, so re-writing and re-engineering it would be a huge and somewhat fruitless undertaking. You don't get publications from refactoring.

Globally though I think science is heading in the right direction, big fan of efforts like Software Carpentry (http://software-carpentry.org/).

We're teaching a course at ETH Zurich [1] where --besides the actual payload of solving partial differential equations (PDEs) on GPUs-- we put a lot of emphasis on "tools". Thus students learn how to use git and submit their homework via pushing to a repo of theirs on github, we teach testing and continuous integration, writing documentation, running code on a cluster, etc. In their final project, again submitted as a GitHub repo, they need to make use of all of theses skills (and of course solve some PDEs).

Note that excellent work in this space is done by the Software Carpentry project which exists since 1998 [2].

[1] https://pde-on-gpu.vaw.ethz.ch/
[2] https://software-carpentry.org/

The fundamental problem here, as you note, is that scientists are rarely also engineers, and don't really share our desiderata. The point is to develop and publish a result, and engineering analysis code for resiliency is of secondary concern at best when that code isn't likely to need to be used again once the paper is finished.

The "Software Carpentry" movement [1] has in the past decade tried to address this, as I recall. It's very much in the vein of the "basic literacy" course you suggest. I can't say how far they've gotten, and I'm no longer adjacent to academia, but based on what I do still see of academics' code, there's a long way still to go.

[1] https://software-carpentry.org/

I glanced at the Clive Thompson article. I disagree. I feel movements like "software carpentry" (https://software-carpentry.org) are a good indicator of what mass computer literacy will look like in the workplace and society as a whole. Essentially more folks will know how to develop small scripts to support their main work (or customise their home automation systems). In turn, I also suspect, in the long run, programmers that act as the equivalent of a scrivener (the 'blue' collar workers of those articles) are going to dramatically decline as a percentage of folks engaged in software development.

If you get a chance go on a Software Carpentry [1] course. I went on one 4 months ago and it changed my whole outlook. Greg Wilson take you through the psychological aspects of programming - why you should break every hour - the difference between "sip of tea" and "make a cup of tea". How your code relates to short-term memory and much more.

Don't think "I know how to program". Even if you know the syntax and the idioms you don't know everything. Simply going through a workshop will change the way you think.

[1]http://software-carpentry.org