I’d like to return to writing ‘proper’ posts, both for general readers and scientists. But there’s a lack of this thing called free time—I think it’s called that, I’ve forgotten—that’s getting in the way.
Readers could try the winners of the inaugural Science Seeker Awards. Don’t ask me how 3 judges whittle down over 350 entries to a bit over a dozen winners. You can browse the full list of nominations too. Go for it. Good reading for free!
Some of my older writing is under my Writing page. (Another thing long due for an update or, realistically, more content for it.)
One reason I’m deferring is I’d write something grumpy about bioinformatics software development and the projects that generate them, featuring loud whinges like:
- PIs for goodness sakes insist the student test their code. Really test it. It’s really embarrassing to find one after another solution for a fairly straight-forward task isn’t up to real-world use. Embarrassing to think I’m part of the same field, that is. (And a bit depressing, too.) Note that’s not just bugs, but utility, which leads me to…
- If you’re going to have someone develop a method, insist they have some real-world project using it so they get to use what they make ‘for real’. I’ve touched on this topic before in Developing bioinformatics methods: by who and how. The developer might then have a hope of seeing what’s need to really use what they’re making. (It also works the other way around, that they understand what needs to be solved.)
- A project is not complete until it’s been properly documented. Properly is not a sketchy outline reminder to the author how they did it. It certainly is not failing to point out hidden assumptions in the code, limitations such as it bailing out on some types of input, etc., etc.
- And, er, on I could go…
But you’d be better to look to happier reading, eh? Check out the Science Seeker Award winning entries. (I don’t have time to – ha!)