…so says the famous quote, my current mantra. This leads to my primary mission (or possibly, it would be more appropriate to call this my Prime Directive) is to code and get it all out. Brainstorm in code quicker and faster.
I have this extremely bad habit of writing 10 lines of code before shelling out the rest of the day learning how to improve these lines in R. Yes, I learn a lot through the process, but graduate students are responsible for more than just learning. Sometimes, there are those that actually have no interest in what I have learned but only my results.
This idea is nothing new to me, but this post is an attempt to enforce a turning of a new leaf. It was ridiculous for me to waste the previous hour intending to optimize TWO lines of code! I cannot and will not do this anymore. Those two lines of code were not important enough to waste that much time. Before my bedtime, my whiteboard may be plastered with a repetition of “I will refactor my code later and not now.” Unless the code is being published, procrastinated optimization is far better than procrastinated results.
Am I alone in this endeavor?
One Response
Leave a Comment
June 17th, 2009 at 10:11 am
This whole argument assumes that you are writing inefficient code to begin with. Stop writing inefficient code and this will cease to be an issue.
I don’t know much about the structure and program flow of R but if it’s like any other languages I’ve worked with, one thing that might help is to re-evaluate your code re-use. When you spend a decent amount of time optimizing a piece of code, examine what exactly that block of code does and pull the optimized code block out into a sub-function. Create your own custom library of these optimized sub-functions, and over time you will end up with a collection of efficient subroutines that you will likely find yourself re-using or reading through (since it also serves as a catalog of optimization techniques). This especially works well if you include the “before” code as a comment block before the optimized code. Eventually, you will get to where you start thinking more like the code interpreter/compiler and you will write code that is more efficient the first time around. (one caveat: this can actually make things more difficult if you often code in several different languages).
Spending an hour optimizing a couple of lines of code isn’t too terrible, assuming that the benefit of the optimization makes up that time later. I have spent hours optimizing a 500-line function only to find that the code was only running when the system was idle (thus who cares about performance). I have also spent a week optimizing one line of code that ended up cutting the run time of a simulation down from 20 hours to about 90 seconds. It’s all about how much benefit you will get from the changes (including future users of your code and future code that you will now know how to write more efficiently).