GameDevBlog

Time Management, Part 3: Case Study

(Part 1)
(Part 2)

So, using myself as an example, once I'd discovered that e-mail was a big chunk - (the fifteen minutes here, fifteen minutes there, really add up) - what did I do about it?
Step one was I made a decision - I'd try to only read my e-mail once a day.  There are other benefits besides the time-savings to doing this:

- less multitasking.  When coding, etc, I can focus on just that.  I won't have an e-mail popup interrupting my flow.

- when profiling my time, I can get a better measure of just how much time I spend processing e-mail, because it's all in one contiguous chunk.

"But," you say, "that doesn't actually save time!  You still have the same amount of e-mail to process each day."

Not true!  The thing is most people are habitual e-mail checkers like me, and what often happens is I'd get an e-mail, immediately compose a response and send it, and then my correspondent immediately composes a response and sends that. 

Step two was to use the phone more.  As fast as I type, I can talk a lot faster.  For e-mails that take more than a few sentences, instead of e-mailing my coworkers I call them.  (Although sometimes these calls can turn into long conversations about whatever.)

Step three was to just be smart.  Not every e-mail needs a lengthy response.

So, with all that, I've shaved about an hour a day off my e-mailing time.  Which is huge, if you think about it.

The downside is I can no longer "stay on top of things" - important e-mails that need an immediate response might get missed.  So I made sure to tell my coworkers that I was doing this, and if they had anything important to tell me about, they needed to call my cell.  (Now I just had to remember to keep it charged.)

Also, something I've recently started doing, because production on our game is in full swing and we need to communicate as much as possible, is filtering my co-workers e-mail into the "Important" box, and everyone else gets shunted off to the "Later" box.  This seems to be a good compromise.

Next week (but no promises):  David "no open loops" Allen vs. Mary "dump that long queue on the floor" Poppendieck grudge-match in my head.

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)

If You Build It They Will Come?

Apparently not:

http://rondam.blogspot.com/2006/10/top-ten-geek-business-myths.html

I've heard plenty of horror stories of the "We spent $$$$ on a demo and nobody cared" variety.  On the other hand, I've seen a few projects that had no traction actually go once a prototype was made.  So...while "If You Build It They Will Come" may not be true, this is:

If You Don't Build It, They Won't Come

Time Management, Part One: Profiling

Sometimes people ask how I have time to work, be with my family, play games, and write blog entries.

The answer is not in *Getting Things Done* (what we really need is a book called *Getting More Done*), but it is one of the oldest tricks from management literature - I first saw it in Drucker in a book he wrote decades ago, and it's been in plenty of other books as well.  I think it's just plain common sense, although I rarely see people do it, and some people have told me it's just plain crazy.

Anyhow, here it is.  Managing time is a lot like optimizing code or tightening a budget. (Or even dieting, if you do it the good old fashioned calorie-counting way.) First you profile;  then you cut or tighten the bottlenecks.

To profile my time, I have a lined paper broken into fifteen-minute blocks, and sometimes I'll update it when I switch tasks, and sometimes I'll update it retroactively with my best guess for how the previous n hours were spent.  Although I used to just profile the work day, lately I've been profiling my whole twenty-four hour days, because doing the startup thing I find myself working on the evenings and weekends, so its valuable data.  I don't profile every day - I only start profiling when I find myself wondering, "Where did my time go?  How come I didn't get anything done this week?"  Don't we all wonder that from time to time?  Well, when I find myself wondering, I start gathering data to get the answer.

I'll usually collect data for about a month or so and then stop.  Sometimes I'll put the data into a spreadsheet and sometimes I'll just eyeball it. 

In my latest round of time-profiling, the biggest chunk of time went to sleep.  Spending time with Cathy and/or Sofi was the next biggest chunk, although much smaller than sleep.  Coding was a big chunk, but not as big as I would have liked - ideally I'd arrange things so I get more time for this.  Reading and writing e-mail was a big chunk.  Actually playing games was a big chunk.  Blogging, interestingly, was barely on the radar - I spend about an hour every week or three writing a blog entry, which strikes me as a worthwhile investment.

Next week (or whenever I get around to it) - once you've profiled, how do you optimize?