The title of this blog post is a mixed metaphor. It’s a mashup of two common programmer idioms, sharpening the axe, and shaving the yak. I’ve been doing both this week, but before I get into that, I’ll define the terms.
Sharpening the Axe actually comes from a quote attributed to Abraham Lincoln: “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” When googling around for how this applies to programming, it seems a lot of folks have (for some unfathomable reason) latched onto the phrase “sharpening the saw” instead. I can think of four general categories of specific activities this could mean:
- direct study — Ie., reading a book on a language or API, or reading and/or studying some relevant source code. Anything that directly applies to some programming task you have to undertake.
- indirect study — This could include reading more generally about programming or related “industry” news, or learning a new language you will not immediately be using, or any other research not directly related to your current task list but (hopefully) teaching you something tangentially related.
- architecting — This could be formal, in that you’re writing a document or outline, or putting together a task list, or just more generally thinking about the task(s) you have at hand. (I find I do my best architecting in the shower.)
- practice — Writing code, but not code you will be using. I’m not much for this one, but I’ve heard a lot of good programmers say they write something once, throw it away, then write it for real. That sounds like a lot of extra work to me, but who knows, it is definitely easier to write something the second time. I’m not sure it’s guaranteed to be better though.
Yak Shaving is a more complex and subtle problem. Jeremy H Brown defined it in a usenet post in 2000 as “what you are doing when you’re doing some stupid, fiddly little task that bears no obvious relationship to what you’re supposed to be working on, but yet a chain of twelve causal relations links what you’re doing to the original meta-task.” The programmers Stack Exchange has more on the definition and history of the term yak shaving.
So what have I been doing this week?
I’m working on iCloud syncing for ActionGo, my next game for Apple TV and iOS. In a way, this is already shaving the yak, since I’m really only working on that because the Apple TV doesn’t support filesystem saving, and iCloud is their recommended solution. But after only a day or so of work, I found out that it does support NSUserDefaults key/value saving. (Up to 600 K, plenty for a saved game or two.) Since I’d already planned on implementing iCloud as key/value, so long story short, now I’m doing both. (Which is of course better, because it’ll work offline too, just without the syncing.)
But I’ve never done iCloud syncing before. *queue sharpening sounds* There are at least a couple of ways you can store data there, key/value, or document-based. Key/Value is definitely preferred for my use-case (a bit of state data for games in progress, and storing overall meta-game statistics), so I focused on that, but even then there are a bunch of different ways to go about it. Consensus seems to be that it’s really easy to get working, but almost all the blog posts and resource sites I read focused on that initial experience and I didn’t end up finding anyone who went into best practices.
So here’s the yak shaving rabbit hole (oooh, a third metaphor?): I’m using Generic Game Model for game state, which already had saving implemented on iOS using the built-in saving functionality that BaseModel provides. But it turns out that I was using an old version of BaseModel, so I had to update that. Then I wasn’t happy with how BaseModel implements its NSUserDefaults storage, so I re-wrote that. Then I wrote a wrapper that handles the syncing to iCloud whenever a key is added to NSUserDefaults (storing an associated NSDate value also, so I can just keep whatever’s latest), and only just now I’m finally getting around to testing. (Only I’m not so much, since I’m writing this post right now instead.)
When is your axe too sharp?
While “researching” this post *more sharpening sounds*, I ran into this critique of Axe Sharpening from a java.net blog post back in 2005:
But for me, the big problem with “axe sharpening” is that it’s recursive, in a Xeno’s paradox kinda way … to sharpen the axe, you need a sharpening stone… But to get there, you need to build a dog sled… But to use a dog sled I need snow, so I need to go to town to get a snow cone machine. I grab my trusty yak to help you haul the machine from town. But it’ll be summer before I get to town, and I don’t want the yak to get to hot, so I shave the yak. In mid February, I proudly lead my shining, bald, shivering yak into my quarterly progress review…