Pushing the profiling code metaphor, we can find other productivity tricks.
When optimizing code, you can frequently trade resources. Trade memory for speed by using a look-up table (or in the days before instruction fetch misses an unrolled loop), etcetera. Likewise, when optimizing time, you can trade (as Mark Nau puts it) the green currency for the gold currency: hire a housekeeper; get your meals and/or groceries delivered; take your laundry to fluff & fold; spend less time bargain hunting and just buy it at the higher price; buy the more expensive tool that makes you more efficient. These days I don't actually do most of these things, since I'm not taking a salary and part of being a startup is focusing on cashflow over efficiency, but they're good tricks to have up your sleeve when the time is right.
And, really pushing the metaphor - to optimize a program, you can cache or off-line computations, spending a lot of time when the program first executes (or during the build process) to save time later. In other words, a large investment in time now can give you a small daily savings that adds up. In general, spend the time to learn how to do a task quicker. Read, or at least skim, the documentation for the entire library of the codebase you're using, so you don't waste time duplicating work. Learn a text-processing language or good shell-script language to automate your tasks. I only just recently started really using the grep built into visual studio to make sweeping changes to the code, but I've already broken even on time saved. Read the docs for your editor; learn the hotkeys. Improve your typing speed.
"Improve your typing speed?" some ask. "Not that much time spent coding is actually spent writing code." (So how come most of the really good programmers I know type like demons? I know, correlation not causation.) I see your point, particularly with the awesome auto-completion in Visual Studio these days - but even if typing speed has nothing to do with coding performance, programmers do spend a lot of time in e-mail. (More on that in Part 3.) "Still," you say, "it's thinking about what you're going to write that takes the time."
There's where I disagree. I did an actual Scientific Study. Back when I fancied myself a novelist (
So, my advice, if you don't type at least 50 wpm get yourself some *Typer Shark* and *Typing of the Dead*, spend some time every day with them, and you can have fun and become more productive at the same time.
There's also a speed-accuracy tradeoff thing. Take typing, again. I type really fast but
make a lot of mistakes. I'm constantly backspacing. I sometimes think
of it as "agile typing" but honestly, I could probably be faster in the
long run if I simply made fewer typos. You can invest time in
accuracy by slowing down, checking your work - and moving away from the typing metaphor - implementing test-driven
development and peer review and by simply concentrating on going slow.
Somewhere there's a sweet spot - the trick is finding it. It's quite possible that slowing down will make you more productive in the