One of my all-time favorite expressions is “Yak Shaving”. It makes me laugh. It’s super visual to imagine myself out there with the same electric clippers I use on my head just kinda trying to get the hair off of this huge bovine. Truth be told, I’m not even sure I’ve seen a yak outside of a documentary, so I’m just imagining a big cow that has beautiful long flowing hair (think cow Rapunzel).
Anyway, the origin of the phrase is someone named Carlin Vieri who was at MIT at the time. An email from Jeremy H. Brown explains:
You see, yak shaving is 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.
Some people, like Seth Godin, argue against it on his blog post “Don’t Shave That Yak”. Others, like Florian Gilcher, point out that good things come from shaving yaks.
My blog itself is a yakshave. I decided that I wanted to write a blog post. Then I decided that I didn’t want to use Wordpress or Drupal and everything went downhill from there. I decided that it had to be an application of my own building. I wrote some blog software a long time ago in Ruby after I watched DHH’s famous build a blog in 15 minutes demo. But I didn’t want to write a blog in Ruby, I’d done that before. At work, we were using this cool language called Go.
I really enjoyed Go. I kept making little toy apps that would connect to a database, or validate JWTs, or muck around with general internet stuff. I built a small web crawler to do SEO audits, I built a little thing to handle OAuth to Google with and then persist it with client-side JWT’s. None of it was really coming together into blogging software though.
Every time I tried to get started writing the blog software, I would look around for learning resources on routing in Go. I constantly saw people say things like “You just need the standard library”. So I started a few times and came up with a few small routers using the standard library, and they were at best just ok. I didn’t like how I ended up using them, so I kept falling back to using Gorilla or Echo.
Anyway, I decided to start writing the software at the bottom. Since I was already using Go, I looked at AppEngine - both are made by Google, so they had to go together. I knew that I wanted a way to write the posts, and that meant I needed a way to persist the data, a database. Google Cloud has one called Datastore, but it was getting replaced by one called Firestore as I started this project, so I figured, let’s just use Firestore.
Back to Go. I wrote a server-side application that interfaces with Firestore. It uses basic IAM management to secure it. It doesn’t include Firebase’s JS. I also wrote a router in Go using the standard library. It’s not great and I wouldn’t recommend other people use it. On the other hand, I’m really happy that I dove in and wrote enough server code to get something working.
Writing your own router is very different than writing a blog post. There’s a lot of cool stuff in these seemingly unrelated tasks that I learned because I was willing to follow the yakshave until I got what I wanted. I wrote a CMS, I wrote a router, I wrote a bunch of templates, all so I can shout into the ether.
Yak Shaving happens in real life too, not just in programming worlds. Sometimes you end up following a chain of tasks that don’t seem related at all to what you should be doing. But if you’re learning from those tasks and can build back up to what you should be doing, then those tasks are worth doing.
Instead of just saying “Don’t Shave That Yak!”, figure out if there’s something worthwhile to learn from following the chain until you do have to shave the yak. Because sometimes shaving the yak is the right thing to do.