When not to program

It’s end of the semester time ’round here, and students I’m TAing are frantically trying to get their final projects working. One of the emails I fielded today was basically asking, “Is there a way to get MATLAB to automate this for me”.

The answer to the question, of course, is “yes”, but knowing that student’s comfort with programming, I phrased it more like, “Yes, you could do it by XYZ, but it’s probably just as easy to do it manually for the 6 data points you’re interested in”. What I didn’t write (but really meant) was essentially, “If you have to ask, the answer is no”.

It’s worth pointing out that the course isn’t designed for teaching general programming concepts (unlike other courses I’ve been involved with), and instead uses a very restricted set of MATLAB and programming concepts as a tool to understand biological modeling. It’s so restricted a set of concepts, in fact, that back in week 3 or 4, I wrote up a handout that was essentially a step-by-step recipe for doing the coding for all but one of the rest of the labs.

In grad school, there’s often two modes with somewhat opposing goals. First and foremost, you want to get stuff done. But you also want to leave things in a state where it will be possible to quickly and easily repeat things in the future. Sometimes, that latter goal is achieved by stopping before hand to think about the way to structure code, sometimes you even need to learn more skills which you will apply in the future (either programming or bench techniques or *gasp* math).

So in this student’s case, the answer (given that the final project is due in just a few days) is probably to do it the stupid, manual way that’s less elegant, but also much much faster than taking the time to really grok loops. In the long run of grad school, it won’t always be obvious where to spend more time making things faster, and where to just grind it out. And, of course, one final thought is that sometimes you can take longer to make it faster, and not succeed: