Scientific Programming “Don’ts” – is the first in a series of blog posts created from the nightmares of the The Research Software Company’s top developers. We encourage you to heed our warnings!
As developers, we are often called upon to consult only after something has gone horribly wrong. For example, sometimes we are handed code that was written by people who are brilliant, but inexperienced. (And yes, by “people”, we largely mean PhD candidates or postdocs. It’s easy to forget, but those cola-and-pizza fueled sentient sweatshirts who inhabit your lab are actually people) New programmers often make mistakes that can be easily avoided if someone with experience coaches them through the early stages of a project. When this happens in smaller projects it’s relatively easy to fix. But sometimes basic mistakes happen in big projects, which its really painful. How painful? Like, sitting calmly on a porch-swing and your friend passes by and gives you a big push, and you lose your balance and fly over the porch railing and into grandma’s rose bushes painful.
For example, quite often we see people who simply don’t use source control repositories. Instead they store the code on their local drive, and have a bunch of folders possibly on multiple computers with different versions of their code. If they’re extra careful they keep backups on a thumb-drive on a shelf somewhere.
This is not something you should do. Source Code Repositories give you the advantage of version control, backup, and easier bug fixes. There are many good, free, places to upload your code for storage. Bitbucket, for example, offers free academic accounts that don’t have the restrictions of their usual free accounts. Just use that. Or github, or gitlab. You can even use SVN if you must, just use something. Although not Source Safe. Please don’t use Source Safe. That would hurt worse than grandma’s rose bushes.