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:
- Establish a reproducible set of steps.
- Profile this to get baseline numbers for the metric we wish to improve.
- From that baseline profile, identify hotspots.
- Fix said bottlenecks.
- Re-profile to see deltas.
- 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.
Workflow
Here is a rough outline of a typical day-to-day workflow:
“Get Latest” workflow
- Sync to head in Perforce.
- Compile code.
- Build data.
- Deploy build to target platforms.
“Work Loop” workflow
- Run game. Execute steps 1, 2,…,n to get to a location in game.
- Check bug or feature.
- Debug.
- Close the game.
- Iterate on code.
“Verify and Check In” workflow
- Run game. Execute steps 1, 2,…,n to get to a location in game.
- Verify feature works correctly or bug is fixed.
- Repeat for multiple platforms depending on how likely changes are to affect other platforms. Ideally test on a different platform than the primary platform I used to fix the bug or implement the feature.
- Run memory leak test.
- If necessary, check performance/load times/memory usage tools to determine impact.
- Shelve and buddy changelist on another machine to ensure there are no missed files or dependencies on other changelists.
“Main” workflow
- “Get Latest”.
- Go for Coffee.
- Look at task list and highlight top priority items to work on.
- While bug is not fixed or feature not complete, run “Work Loop” on that task.
- “Get Latest”
- “Verify and Check In”
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:
- Navigating the UI.
- Connecting multiple machines to test online features.
- Walking to a location in the world.
- Spawning various items.
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!