Today's XKCD starts to answer: how much time should I spend making a routine task faster?
I really like this comic. As a Ph.D. student, I have a lot of control over how I spend my time, and this question comes up a lot. (I'm even writing about analyzing how I spend my time.) Relative to the people I work with, I think I err on the side of spending more time optimizing my workflow, and I think programmers in general tend to do this more than others.
Obviously you shouldn't spend all your time optimizing. We joke that one optimizing friend (Aleks) will only need one keystroke by the time he's done; it'll set off some sort of complex scheme for something-or-other. The details are moot, of course, since he'll never reach that point.
Still, I don't think Randall's chart is the definitive answer. It can be rational to spend more time "optimizing" than you'd naïvely expect to shave off:
-
You may grossly underestimate how much time you shave off. If you're eliminating a frustration, in particular, the expected time should include lost productivity due to becoming frustrated. If these minor frustrations add up, eventually you'll just shut down.
-
Improvements to your workflow can be shared if they apply to other people; this multiplies their effect. This is why I'd rather have my labmates use the same tools as me.
-
Although doing a routine task is usually not interesting, optimizing a routine task often is. So at least for me, the path to getting something done may be shorter through optimization rather than through procrastination.
-
Improving your workflow makes you faster at improving your workflow. The experience and knowledge gained while doing this leads to making faster improvements next time around. It also exposes low-hanging fruit for other workflow improvements you may not have considered. This argument may seem circular, but it's not: you're shaving time off future optimizations, which shaves time off tasks that you wouldn't have otherwise optimized.
These arguments aren't earth-shaking, but at least there's some ammunition to use in defense of over-optimizing.
Update: Cory Doctorow made some good counter-arguments on Boing Boing.