Skip to content
November 4, 2012 / Damien Irving

Best practices for scientific computing

Welcome to the first ever Dr Climate blog post! As discussed on the What is Dr Climate? page, I’m hoping to cover a lot of ground on this blog. From the latest climate science textbooks/resources, to literature searching, programming, word processing, data management and career progression / self marketing, I’ll be touching on a wide range of tools and general practices that can improve the way you do research in the weather and climate sciences.

Despite this long list of topics to choose from, the decision to make scientific computing the focus of my first post was actually a pretty easy one. It’s something we all spend a large percentage of our time doing, and yet most of us are primarily self taught. We all know that there must be easier and more efficient ways to do things, but in many cases it’s hard to know where to start. I used to think that I was the only person who felt this way, however I’ve come to realise that we all feel like this to some degree. I’ll talk more about the Software Carpentry Bootcamp that I’m involved in organising in later posts, but the fact that registrations have been coming in thick and fast is testament to the fact that we’d all like a little extra help in this area.

In fact, if you don’t know where to start when it comes to improving your computing (or even if you do), check out the Software Carpentry website. Greg Wilson, who is the head of Software Carpentry, recently published a paper titled “Best Practices for Scientific Computing.” The paper makes the following key recommendations:

  1. Write programs for people, not computers
  2. Automate repetitive tasks
  3. Use the computer to record history
  4. Make incremental changes
  5. Use version control
  6. Don’t repeat yourself (or others)
  7. Plan for mistakes (defensive programming, write and run tests, turn bugs into test cases, use a symbolic debugger)
  8. Optimize software only after it works properly
  9. Document the design and purpose of the code rather than its mechanics
  10. Conduct code reviews

Over the coming weeks / months, I’ll devote a number of posts to documenting my efforts in trying to adopt each of these key recommendations. In the meantime, have a read of the draft manuscript. Do you already do all 10 recommendations, or do you have a long way to go before you are operating at ‘best practice’ standards?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: