The act of writing tests at different scales (unit, integration, functional) makes you think about structuring your code into well-defined units with clear responsibilities. And it discourages practices like shotgun debugging that are all too common in part-time programmers. (Myself included, until fairly recently)

And a variation on number 4 — make your own research code open-source. It makes you think about writing code that others can understand, good documentation, following a clear change-build-test-release cycle etc., and forces you to use source control and issue tracking.

Inaugurating a new project in SourceForge isn’t actually that hard.

However, it is not easy to contribute to an opensource project, as it requires great ‘diplomatic’ skills.
You must have survived for at least one or two years in usenet, or have great patience, otherwise, you will end up by giving up, as contributing to open source projects maintained by scientists can be especially difficult.

Agreed! The key is for everyone (reviewers and the author of the code) to understand that the code is being reviewed *not* the coder. A white paper on the social effects of code review is available here: http://smartbear.com/docs/CodeReviewSocialEffects.pdf

It would be nice if it was continued though, although it serves as a good introduction to better programming techniques

It’s amazing how many times people forget that they can read!!