This is foremost a place for my online CV. In addition, I kicked around a few blog ideas and eventually landed on this one.
People around me say I’m good at documenting code. I would tend to agree, to the extent that I’m surrounded by scientists, who are famously terrible at writing code. What sets me apart is a willingness to sit down and work on readability. I budget time to document code as part of the time to write it. Because, simply:
If no one can understand your code, it is useless for science.
Yes, that includes if you can understand your code. You may understand it right now, but if you have to step aside for a month or three on a different project, will you be able to come back to your own code? Will you be able to explain what it does, why it does that, and how it works?
Wet-lab folks document their procedures for reproducibility and (if/when stuff goes wrong) to aid figuring out what happened. Dry-lab folks should do so too. See my post on dry-lab notebooks.
Documenting code really isn’t that hard. I’ll explain, in practical terms, how one can do so, and what empirical benefits documentation offers. So, the blog. I promise no consistent update schedule*. This is half for me to organize my own thoughts, a third for me to link to colleagues as an example, and only perhaps one-sixth for random other people to come across it. There will be no comments. If you have some topic you really want me to cover, email me (address in CV).
(The last one-sixth may also be attributed to pure vanity. Your choice.)
If you suspect I choose my topics (for a blog no one will ever read) as excuses to rant about coding practices that I dislike, you win a cookie. Not one on this website, since I don’t know how to set cookies, nor one in real life, since I lack a cookie transporter. An imaginary cookie. Hope you like it.
*in practice, I tend to update on Saturdays every week or two, but the exact day and time varies. I update at least once a month to add to my series of published code critiques.