Optimizing Workflow

There is a certain frame of mind programmers step into when doing any sort of optimization.  I’ve found this way of thinking about optimization has come in useful for me when improving my daily workflow.

When we optimize code, we go through a process similar to this:

  1. Establish a reproducible set of steps.
  2. Profile this to get baseline numbers for the metric we wish to improve.
  3. From that baseline profile, identify hotspots.
  4. Fix said bottlenecks.
  5. Re-profile to see deltas.
  6. Iterate as necessary.

Obviously this is greatly simplified, but the important points are to have something to compare against, and constant iteration and comparison against that baseline to determine the effects of your changes.  I have taken this approach to my daily workflow, and have found it has helped my productivity.


Here is a rough outline of a typical day-to-day workflow:

“Get Latest” workflow

“Work Loop” workflow

“Verify and Check In” workflow

“Main” workflow


Main Workflow

At a first glance, it is pretty obvious that most of my time is spent iterating on the “Work Loop”.  So it makes sense to start there.  As I run the game and debug, I note things that I’m doing over and over that are inefficient or easily automated.  Such a list might include:

Once I’ve identified these, it’s easy enough to create debug functionality that’ll make them easier.  I point out a few in a Rescue Time, which logs computer activity.  It lets you set whether a process is “productive” or “distracting” and will give you graphs and history for your daily work.  This gives me a high level overview of where I spend my time.   A Smoky Kitchen was a post that inspired this.

Get Latest and Checking In

I’ve left this to the end, because while a lot of us focus on having a single batch file to try to sync, compile, build and deploy, this typically only happens a small number of times a day.  Our compile times are not excessive and we don’t build data unless we’re changing it, so I haven’t been too motivated to work on this as much.  At a previous job, however, our data builds were in the order of 10′s of minutes, so one forward-thinking SE wrote an Outlook filter that would act on an email sent from his home account and kick off a sync-compile-build script.  Then, by automating the email from a web page, he could create an icon on his iPhone that would kick off his build, and do that when he left the house.  Simple to do, but was a godsend.


Hopefully I’ve conveyed the thought process by which I’ve selected tools to use and functionality to devote my time to, and how that thought process isn’t one that is new to most of us.  And as a bonus, perhaps some readers will find a new tool that will help them out!