I always liked yak shaving, but avoided it because I knew it came with costs and tradeoffs. More recently, with the help of AI, I’ve been doing lots of it, as the costs and tradeoffs have greatly diminished. In fact, I’ve learned that building my own tools and frameworks, when done properly, comes with huge performance benefits and helps me understand the problems I’m trying to solve much more deeply. There has never been a better time for yak shaving!
Yak-shaving-shaming puts limits on the creativity of talented engineers by constraining them to existing patterns and practices or building on top of abstractions, and practically, that results in engineers and teams with less breadth. In an applied software world that's exploded in framework and library complexity in recent years, I think there are always going to be yaks in dire need of a shave.
At a previous job, my coworkers coined the term "Thomasing" [1], referring to me, as "the act of having a question explained so thoroughly, detailed, and long-winded that the asker has lost interest in the question that they were asking".
I thought it was pretty funny, because that does basically describe me in a nutshell.
[1] Lovingly, it was a good, fairly-tight-knit group, they weren't being jerks. We all did lighthearted ribbing.
This feels like what is really splitting the programming community right now- those that have typically enjoyed the journey, and those that just want to be at the destination as soon as possible.
They are different things. There are projects where I deeply care about the code, and projects where I deeply care about the end result. And a whole lot in between, or that are entirely throwaway.
But I use AI also for some of the ones where I deeply care about the code, now. E.g. my terminal is in Ruby, and it worked well enough, but over the last couple of days I had Claude put together a test harness and burn down a number of sharp corners and refactor the code. It's not perfect still, but it's cleaner than it was because I didn't have time to do enough yak shaving myself. I do care about that codebase, because I have other things I want to use it for, and not having to do it all manually gave me enough time to get it to a far better state.
I feel like a lot of the split comes from people who are a whole lot less overcommitted. If you have way too many projects, you pick and choose which projects you want to lovingly care for and which ones you just want to advance the functionality of as fast as possible. Sometimes those are one and the same at different times.
I’d argue most businesses have had their start through yak shaving.
I’ve found that the overuse of AI papers over a lot of problems. Then if things start failing people have no idea where or what to start fixing. I’m very much a destination person, but I’ve been on enough rides which crashed and burned to be cautious about it.
In my experience it's not as simple and depends on a whole lot of circumstances: generally I am interested to learn and to build. Give me pressure through dysfunctional processes, understaffed teams, unrealistic standards, too strong peer opinions- etc - and I'll happily reach for the shortest path.
It makes me of the difference between the indie developer who labored over Stardew Valley vs. (for example) Square Enix putting out a farming sim because their committee of suits decided they wanted revenue from that genre.
Glad you gave yak-shaving a proper definition. I was always annoyed at my boss for insisting on a particular arrangement of import statements in typescript files. For him, it was a way of telling us to be more mindful of the code we typed. But mostly I’d have preferred a simple eslint config with autofix on save. This kinda yak shaving is no fun - trust me