Software Carpentry

Helping scientists make better software since 1997

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.
About these ads

Written by Greg Wilson

2009/12/27 at 11:32

Posted in Content, Noticed, Opinion

6 Responses

Subscribe to comments with RSS.

  1. I agree — it hardly matters how well your code is documented or what open source license it is if it gives you the wrong results.

    It seems like `embracing open source’ and `standards and interoperability’, and `unix shell skills’ would be usefully merged into two points: one about reproducability, both for good science and for not re-inventing the wheel, and one for putting big things together out of little, possibly pre-existing pieces. The little pieces thing would tie in nicely into unit testing, and also make contact with the `keeping projects managable’ bit.

    Similarly, if `structuring data for speed/scalability’ is to mean anything beyond `don’t use flat text files’, then there is significant overlap between that and `understanding the limitations of the hardware’.

    Jonathan Dursi

    2009/12/27 at 18:32

  2. Glad you guys like the article… the list can always be optimized. Classroom time will probably never be sufficient for learning these skills. 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.

    Atul Butte

    2009/12/27 at 19:32

  3. “””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.”””

    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?

    Besides, in the computational sciences, doing science consists, mostly, of writing code.

    luispedro

    2009/12/28 at 22:58

  4. “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.”

    There is certainly truth to this.

    From my experience, if you are writing tests in a testing framework (using a language) then the tests need to be just as clean and well written as the source code you are testing. So skill in the language is certainly important to “how and how well” these tests are done.

    Now what really stands out from this list is the absence of being reflective, mindful, and intentional in their software development. Everyday do they ask themselves, “What can we do better?” Whether it is skills, practices, or processes. What is working and what is not working? Where are we spending too much time or why do we keep seeing this kind of problem?

    Dr. Bubba

    2009/12/31 at 14:56

    • Good points. We tried to allude to “mindful” approach in our section on valuing time, but I really like what you’ve added to the discussion on this with your comments.

      Joel Dudley

      2010/01/08 at 05:23

  5. Thanks for mentioning our article. I agree with your comment about testing. I debated adding testing to the article but ended up leaving it out. In my experience talking to young bioinformaticians about software testing earns blank stares and glossy eyes, but hopefully this will change in the future.

    Joel Dudley

    2010/01/08 at 05:18


Comments are closed.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: