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.
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.
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.
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.
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.
Tangential but it's a story that I find funny.
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.
My favourite Yak from Malcolm in the middle.
https://youtube.com/shorts/kSJgLA1frS4?is=2RA7C0EDEe7Mg8Fp
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.
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.
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.
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.
i think what's really splitting it might actually be differing levels of slop tolerance.
That is a beautiful animal.
I can do a LOT more yak shaving on personal projects now. I still haven't managed to finish anything though.
The fact that programmers can be nerd sniped into yak shaving some random libraries is the only thing that keeps Open Source running.
Good article, I even remember the Yak Shaving Day episode of Ren and Stimpy but never made the connection with the slang term
So is breeding harrier and harrier yaks!
... but it's a highland cow
If you shave a yak, you get yak hair. And this material is like $35 a skein!
https://www.ulaandlia.com/collections/mongolian-baby-yak-woo...
Oh wait, you meant figuratively!