Time Management: Part Two: Optimization

(Part one)

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 ( http://www.amazon.com/Dionysus-Logged-James-David-King/dp/1413448879/ref=sr_11_1/102-8534707-2865737?ie=UTF8 ) I measured my output via handwriting and at the word processor. Even though you'd think that the hard part of writing (or programming) is composing the thoughts, I turned out 150% more words on the days I used the word processor. 

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 long run. 

(Part Three)

Comments

[Chris Busse]

My team right now is howling at the checkin procedures. It did have an "unnecessary" step of requiring an email approval before checking it. It was, in my mind, a purposeful slowing down so that people would do the right thing.

If you have 50 people on your team and they each only check-in twice a day, it only take 1 bad checkin in a 100 from one person to mean that your build is broken everyday.

Spending extra time to make sure you don't keep your team from being able to work is an automatic in all "large" team formats.

[CDriK]

Nice post.

You can also train your keyboard typing skills on the words you usually write to make less typos.

[siferion]

I came across this from a link from another site so my comment may be way later than article. On the part of using tools that make you more efficient I recently bought a Logitech G15 because the macro keys appealed to the programmer side of me that does repetitive parts of code. It helped with some things, like when you have a bunch of long namespaces that you use commonly, but others it hindered performance trying to think how to use it.

I love "Typing of the Dead" I recently got my mom hooked on it when she asked me how she could improve her typing skills (point n peck). In the last month of playing it, she moved away from point n peck and more to typing. Me and my brother compete against each other in it normally, our shortest combined session was kinda funny, not one level lasted more than 3 minutes.

Typing speed I found wasn't as much related to hand dexterity (I'm also a guitarist so my dexterity could just be at it's optimum), but more so knowledge of spelling and grammar. As my spelling and grammar got better I found I can type a lot more words per hour even if the words per minute decreased from using bigger words. But also it trained my brain to find connections between words to get things across better, in the code terms, I learned how to combine different keywords in ways I never thought before from just normal vocabulary exercises. Which of course resulted in better performing code and more components (broad definition) that worked in a shorter period of time.