I used to co-write a blog called 'Programming for Scientists'. All the posts from that blog can now be found here, under the tag Programming for Scientists. Go take a look!
My co-author on that blog was my good friend Ben, who's a professional programmer, so between the two of us (programmer-interested-in-science and scientist-interested-in-programming), there should be some articles there that have stood the test of time :-)
The 'About' for this blog was this:
Just another blog about programming?
Well, not so much. This is a blog about building better (scientific) software. We’re making two important distinctions here. The first is that developing a piece of software is about much more than just writing the code, important though that is. The second is that for many people, scientists for example, building software is something they do in order to achieve their primary goal. What we mean by this is that scientists’ primary goal is to do great science. But to do this, they sometimes need to write some software. So while they need as many software development skills as possible, they really need the ones that will allow them to build the tools they need and, critically, do a good job as quickly as possible so they can produce more good science. We suspect there are lots of people for whom this is true, not just scientists.
The aim of this blog is to explore ways of building better software, but to do so bearing in mind that the ultimate goal is to produce as much great science as possible. This doesn’t mean coding as quickly as possible, which produces buggy, horrible software; it means drawing from the huge body of software development knowledge for minimising the amount of time it takes to build really reliable software that you can then use confidently to do your science. We won’t be telling you the “best” way to do anything (there’s usually more than one) and we won’t be handing down stone tablets saying that you must do something without good reason. What we will do is present a range of techniques, thoughts and considerations and try to explain why we think they’re helpful. You should use somewhere between none and all of these, depending on what you find most useful.
We’re not here to tell you how you should go about developing your software, we’d just like to suggest a few things that other people, ourselves included, have found useful.
We hope you enjoy the blog and find it useful!