Tag Archives: BCompute

Doing things well takes time

I’m not the world’s fastest programmer, nor am I the slowest, and much like any person who does creative work, there are times when things come easily, and times where it’s a slog. But regardless of the day-to-day ups and downs, I’ve come to appreciate a simple fact in recent weeks: doing things well takes time.

A little while ago, I started working on a computational biology library that I’m calling BCompute. The idea came as I was working my way pretty quickly through the challenges at Rosalind.info. If you look at the challenges there, you’ll see that most of them are pretty easy to solve in a script-y way that works for a narrow set of cases. (I.e. the one you’re working on.) String manipulations, analysis, and so forth are pretty straightforward in most high-level languages.

Somewhere around problem 5 or 6, I got to thinking that it would be fun create a compbio library exploring the domain, and becoming a better developer along the way. I didn’t want to just build a collection of scripts; I wanted to build a real, performant library with concepts modeled at the proper level of abstraction, with a type-safe, unit tested, composable domain model that could be used for more than just toy problems. So I started reworking those scripts into something real.

Now, about a month later, I have a library that is getting closer to being able to Do Stuff, and will mostly keep you from doing the wrong thing. Along the way, I’ve learned a lot, and had quite a bit of fun. But man does it take time to do things The Right Way–even when you understand the domain pretty well, which is an advantage that I certainly don’t have. (Though I’m getting there.)

  • Writing tests takes time
  • Squashing bugs takes time
  • Refactoring objects and interfaces takes time
  • Building composable objects takes time
  • Learning and then accounting for the biochemistry edge cases takes time
  • Applying a growing body of domain knowledge to your object model–which appears deficient in new and interesting ways the more you learn–takes time

After 100+ commits, 130+ unit tests, and more refactoring than I can even remember, the most salient thing I’ve learned is that it all takes time. (And there’s still a long way to go…)