Osmosis is Just a Fancy Name for Failure

My last post linked to a PLoS paper by Dudley and Butte on developing effective bioinformatics programming skills. I asked, “How many hours do the authors think are needed to acquire these skills?” In response, Atul Butte said, “I think the ideal scenario is when one’s research projects enable one to learn these skills, so that these skills get learned in a practical way outside the classroom too, while doing science,” while Luis Pedro Coelho asked, “Does it matter over the long (or even medium) term? Isn’t improving your skills even you if aren’t being immediately productive what school is for?”

To which I can only respond, “Yeah, but that doesn’t work.” People have been doing computational science for almost seventy years, and have been calling it the third branch of science since (at least) the mid-1980s. If picking things up by osmosis was going to work as an educational strategy, we’d know by now. Instead, what we actually see hasn’t changed in 25 years: a small minority working wonders, and the vast majority not even knowing where they ought to start. We don’t expect grad students to pick up all the math and stats they need by osmosis, on their own, without any structured guidance—why should expect them to become proficient computationalists that way?

Dudley and Butte on Software Skills

Via Titus Brown, a new PLoS paper titled “A Quick Guide for Developing Effective Bioinformatics Programming Skills” by Joel Dudley and Atul Butte. Their recommendations are:

1. Programming languages
2. Embracing open source
3. Unix command-line skills
4. Keeping projects documented and manageable
5. Preserving source code with version control
6. Embracing parallel computing paradigms
7. Structuring data for speed and scalability
8. Understanding the capabilities of hardware
9. Embracing standards and interoperability
10. Put a high value on your time

I think all these things matter, but:

1. How many hours do the authors think are needed to acquire these skills? We’ve tried very hard to fit Software Carpentry into 25 hours of lecture and 50-100 hours of practical work because we recognize that every one of those hours is time students aren’t spending doing science.
2. Shouldn’t testing be in the top 10? Or the top 5, or 3? These days, I care a lot more about how (and how well) someone tests than I do about their mastery of any particular programming language.

NSF Programs

I’d be interested in hearing from anyone who has enough direct experience of the following NSF programs to know whether they might be willing to support Software Carpentry:

1. Course, Curriculum, and Laboratory Improvement
2. Integrative Graduate Education and Research Traineeship
3. CISE Pathways to Revitalized Undergraduate Computing Education
4. Innovations in Engineering Education, Curriculum, and Infrastructure

Double Standards

Nicola Scafetta is refusing to release the software on which he bases his claims that the sun is responsible for much of terrestrial warming during the last century.  I obviously think that scientists should be required to do this as a condition of publication; coming as this does on the heels of Climategate, it will be interesting to see if journals finally start pushing in that direction. It also highlights the need to add more material to this course to cover packaging for release and data provenance.

Why Opening Up (Probably) Wouldn’t Help

Good post from Steve Easterbrook on why open-sourcing climate models probably wouldn’t make a difference.