Rendered at 10:34:15 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
chaoticmass 14 hours ago [-]
When I was in highschool I started writing a game in Qbasic. Along the way, I wanted it to have a console (like Quake) where you could enter commands and modify the game as you were running it. This lead me to create a scripting engine in Qbasic, and long story short, I’ve been on a yak shaving epic quest now for almost 30 years now. No game, but I have a hybrid C / Lua game engine/general purpose application platform. Still tinkering and still no end in sight. I’m having fun though!
aylmao 1 hours ago [-]
I like electronic music production and mixing, and at some point embarked on the quests of writing a DAW (for which I wrote my own state library too) and a dj application. The DJ application I started this year, the daw has been going on for 5 years now.
I think it's helped me at work. Even though I don't have a job with anything related to music or audio, getting in the weeds of building a complex app like this has a way of teaching you all sorts of things. But even if it weren't, it's fun! When work is stressing, for some reason I find coding something completely unrelated, fun and fully my own de-stressing too.
I find you working 30 years on this game engine/application platform very cool and admirable! I hope this or some other project of mine accompanies me for that long.
bluedino 12 hours ago [-]
> I wanted it to have a console (like Quake)
Hah!
I couldn't figure out the 3D math for quake, or write a fast texture mapper, so I stuck to working on things like Doom level editors.
But, I loved the quake console so I made a similar thing for my editor, basically just a hot key that swung it down and I could change a few hard-coded variables and added some commands like loading/saving files.
sedatk 8 hours ago [-]
Thanks to the flexibility that Quake console provided, we were able to set up a three computer null-modem cable network using an additional serial port card on one computer, and play Quake multiplayer like that. We’d felt like we’d hacked the planet at the time.
d3Xt3r 5 hours ago [-]
We did that too, except it was for playing OMF2097, because sharing a keyboard sucked (and we'd always fight over who'd get to use the right side of the keyboard, which was obviously the best side in those days).
bandrami 8 hours ago [-]
We did that exact setup in college! We ran serial cables out our windows and along the outer wall to the other two rooms. It was triumphant.
Cthulhu_ 2 hours ago [-]
I've been using quake-style terminals for... pretty much as long as I've been using terminals so about 15 years now and I can never go back. Sometimes I open a new terminal window to e.g. run my application but I always forget it exists.
thimabi 17 hours ago [-]
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!
mordymoop 16 hours ago [-]
Personally, I find it difficult to competently reason about a system unless I've built my own version of that system. So if you make a practice of building your own versions of things, you end up with a more robust mental library of how stuff works. For this reason, I've never seen yak shaving as a waste of time. The yak shaving was at least 50% about loading the abstractions into my brain fully.
mrandish 10 hours ago [-]
> I find it difficult to competently reason about a system unless I've built my own version of that system.
You're in excellent company from Feynman onward.
> The yak shaving was at least 50% about loading the abstractions into my brain fully.
I haven't always made a version of new kind of system I'm trying to understand but I always try to at least find a toy model that I can play with to confirm understanding.
godelski 10 hours ago [-]
Same with me. Made me also learn a lot of bash and Linux. I'm not expert (better than average but I'm not fucking around with kernels or deep stuff) and have found that very beneficial to my career, even (especially!) with agents.
Even if I ended up moving to something not hand written the learning helped me find which tools are actually the tools I want to use. Helps me reason about what's necessary.
I fully believe you can't reason about things unless you have some understanding beyond the minimum needed to reason about them. Otherwise you just have unknown unknowns.
flawn 11 hours ago [-]
I wonder, how well does Yak-Shaving work for you with AI, how does it look for you specifically and how do you make sure it's not undermining the friction for learning things properly? I want to try some more yak-shaving soon too.
thimabi 10 hours ago [-]
Yak shaving with AI allows me to function more as a systems designer, code reviewer and tester than a coder per se.
AI is great if you simultaneously guide it and let it guide you. I take my time building a very detailed spec for what I want, then run it through the AI looking for contradictions, misconceptions, edge cases, performance bottlenecks, potential optimizations… anything that might cause problems in the future. Usually these discussions lead to multiple spec-improvement journeys, and that’s where the bulk of learning in a project comes from. Sometimes the AI will flag actual issues, while other times I might need to rein in its proposals — mostly in terms of feature creep and finding non-existing problems. I believe this back-and-forth is the most significant aspect of making the best out of yak shaving.
By the time the spec is “final”, it can be quickly implemented by an AI as I watch, review and test, with practically zero code banging on my part. This way, I get to understand precisely how the project works, make it tailored to my needs, and still not waste time, muscles or even mental bandwidth with menial coding.
chorizo 14 hours ago [-]
Downside: Code is not mature; can have edge cases, bugs and security issues. Likely limited config options without hardcoding features
Upside: Only the features you actually need. Likely fewer dependencies. You know exactly what your yak looks like under the fur.
dfee 6 hours ago [-]
the downside is mitigated by the amount of yak shaving you do. see?
danielrmay 17 hours ago [-]
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.
argee 14 hours ago [-]
This is one of the reasons I’ve never liked the aphorism "make it work, make it right, make it fast." By the time you get to the last point, say, having used Electron to build your graphing calculator, it is far too late to magically make it fast, like trying to make a Boeing 787 into a Cessna.
hatthew 11 hours ago [-]
It's a bad aphorism if you take it literally and don't think about any nuance, but it's the correct priority. In many cases each of the three steps can take longer than the last, and each step is useless if the previous step isn't possible. The lesson is supposed to be to focus on each step at a time, not to completely ignore the other steps.
If you're making a complicated webapp, use your favorite framework to make it functional, and then if it's functional and not already fast enough, look at the slowest parts and replace them with faster alternatives. It's not going to result in the most elegant solution, but in most cases it will be good enough. Better to have something that works than to spend an extra year reinventing the wheel.
godelski 10 hours ago [-]
Similarly "move fast and break things" is a great strategy for learning. But it's terrible for creating production grade software. You break things to learn how they work, but then you got to go back and clean everything up or else you're just living in a dumpster. It's quite impressive how proudly people defend their dumpsters and actively criticize anyone who wants to clean it up. "Waste of time!" Cries the programmer struggling to implement a new feature through a mountain of tech debt
godelski 10 hours ago [-]
I like that aphorism. But if it leads you to building a graphing calculator with Electron then I think it doesn't work, it isn't right, and it isn't fast.
There's also the old saying about how a good programmer is lazy. There's two ways to interpret that. Seems we've shifted to the bad kind of lazy (i.e. easy/minimal upfront work)
nunez 11 hours ago [-]
Agreed. (Controlled) yak shaving is a requirement for juniors IMO
monocultured 16 hours ago [-]
I was taken by Christopher Priests book The Extremes and sat down to write a blog post about what compelled me so much about it, and wanted to add some gifs to it. In particular the "deja vu" scene from The Matrix, but I couldn't find it, and I no longer have an old version of Photoshop around to create the gif myself, and three weeks (and many tokens later) I'm finishing up an xcode MacOS native app that is dedicated to generating gifs. I've still not written the blog post.
beAbU 15 hours ago [-]
Call it a pivot and away you go!
Stewart Butterfield shaved the shit out of two yaks at his video games company, which eventually became Flickr and Slack.
tombert 17 hours ago [-]
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.
socalgal2 50 minutes ago [-]
I agree 100% that yak shaving is fun.
That said, I've seen so many developers, especially indie game developers, waste their time yak shaving (having fun) and then running out of funds and having to give up their dream because instead of achieving their goal,ship an indie game and have income for the next one, they shaved yaks work on a custom game engine or custom UI system or some other thing that's a solved problem and not the actual goal.
I have a friend doing it now. I know he's having fun so I don't want to tell him to stop. But I also know he'll likely hit a point where he needs to take a job and give up his dream because he's not actually pursuing it, it's having too much fun yak shaving.
navigate8310 8 minutes ago [-]
Exactly how do you stop not losing interest because you suddenly realise you are just reinventing the wheel? On the contrary, how exactly do you generate interest in yak shaving because you know a solution is already out there and you should not waste your time?
(Non short video format - https://youtu.be/AbSehcT19u0 ... When in the office I had a QR code of that so people could scan it and understand what I was working on)
jbonatakis 17 hours ago [-]
I’ll never not watch this when it’s posted
dan_sbl 18 hours ago [-]
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.
vidarh 18 hours ago [-]
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.
hankbond 7 hours ago [-]
This was well put. Some things I just want done because I need to use them now. Some things I want to take my time because it's an opportunity for me to expand my knowledge graph and/or something I want to be durable (so it can't be slopped up).
Sometimes one turns into the other. For instance I started building an agent based wiki generator fully vibed. I just wanted to test out if it was possible to mostly automate information extraction and conceptualization. Tried three times before realizing that the path I was attempting to travel was just not going to get me the results I wanted (fully automated meant I was not reflected in the wiki). So I finally started more carefully vibing out an application that implemented some of what I learned would be useful, at the same time I was developing a structurally similar app for local dev harnessing. Realizing that they had a lot in common, I started yak shaving and focused on building a framework that would make it much easier to whip up these types of agent based apps. This is the thing I started from the ground up building much more intentionally and thoroughly.
AI is used all throughout, but the amount of leash differed from holding without looking to wrapped around my wrist twice I'm basically holding the collar at this point.
gavmor 17 hours ago [-]
Riding horseback saves time over walking but it's harder to smell the roses along the way. Nevertheless, millions now ride horses recreationally.
Bukhmanizer 17 hours ago [-]
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.
add-sub-mul-div 18 hours ago [-]
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.
keybored 14 hours ago [-]
Speaking of things that I don’t buy. Metaphorically yesterday this site would gatekeep over enjoying the process of coding itself. People who merely programmed for a 200KUSD paycheck, pphew, disgusting.
Made a post about how you learned to touch type? Or improved something keyboard-related? “I don’t think that typing code was ever the bottlenck”.[1] Now we’re supposed to be grateful for non-deterministic code completion, ah it saves us millions of keystrokes a year.
Some will cry Goomba Fallacy. Yeah of course. Could be that many lurker accounts started posting more, displacing the gatekeeper typist hackers. Now it’s all of a sudden an even split. Huh.
The OP was not about AI. But thankfully there was a top-level meta comment to drag us down into that pit.
[1] The non sequitur of it all is a separate topic
pydry 18 hours ago [-]
i think what's really splitting it might actually be differing levels of slop tolerance.
_def 17 hours ago [-]
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.
jihadjihad 16 hours ago [-]
OT, but the image in TFA is not of a yak, but Highland cattle [0].
The fact that programmers can be nerd sniped into yak shaving some random libraries is the only thing that keeps Open Source running.
mft_ 2 hours ago [-]
Often, the experience is of initially trying to avoid shaving the yak, but finding all of the available alternatives are unusable or unsatisfactory for some reason or other.
So yes, you shave the yak, but at least the clippings are precisely the length and colour you need, and the yak’s resulting hairstyle is pleasing to your eye.
spelunker 18 hours ago [-]
I can do a LOT more yak shaving on personal projects now. I still haven't managed to finish anything though.
cryptonector 15 hours ago [-]
This so much.
nunez 11 hours ago [-]
My dotfiles in a nutshell.
- I want to add a shell function that invoked Claude in a VM via Lima using API keys stored in 1Pass
- But that means I need a way of templating the YAML file that will define Claude's VM and a reliable way of syncing state between it and my machine
- I could use a templating language like Jinja or Starlark, but that's another dependency for a relatively simple job
- Also, what if I want to use Pi or opencode someday?
- So I spent more time than I care to admit hacking a Bash function that replaces template variables in Lima YAML files that doesn't throw a cow when you throw in single or double quotes.
(I got my Claude VM function thing working, and it works really well!)
fc417fc802 9 hours ago [-]
> and a reliable way of syncing state between it and my machine
What was your solution for this? Keeping hosts reliably synced across the network is a perpetual source of frustration for me.
slovenlich 10 hours ago [-]
Does not really feel accurate to how yak shaving was to me.
Yak shaving, as I experienced it - is when nothing works unless you do something else first, and something else needs it too.
I need to fix a bug, but I have to reproduce it first.
I cannot reproduce it, because there is an entire other bug that prevents me from doing it. So I have to take the other route.
But the other route does not work because the infrastructure is busted, and there's a problem on the server.
To get the server to work, I need to contact John.
But I need to do it through the ticket filing system and it is not behaving well today, so I need to find a workaround first.
And after getting the ticket filing system to work I'm finding that John is not on the job today, because he took PTO.
But some say Jim might help me. Jim is just some guy, he is in the other depratment, and I cannot get to him through the ticket system.
And so I send an email to Jim, but Jim is not responding. And I need to find him physically in the building. So I need to know where his desk is.
And there's an entire other system to find where Jim's desk is and I don't have the authorization to use it. So apply for the authorization and wait a bit.
And then I learn where Jim's desk is, and then I go there and it is empty.
fc417fc802 9 hours ago [-]
That's not yak shaving that's just how working on a complex system that has technical debt is.
Xirdus 14 hours ago [-]
> This blog doesn’t use a static site generator or framework like Jekyll, Hugo, or Gatsby.
I guess that's why the blog name stays on screen and covers the text when I scroll down, with fully transparent background so it doesn't even cover the article text, it blends with it which distracts my eyes a little too much. If it was any other blog post I'd be certain it's a bug, but here I'm not sure if it isn't intentional, and one of those customization a ready-made software wouldn't let them do.
yakkomajuri 16 hours ago [-]
I love this. My very own static site generator, Teeny [1], is going on five years now. It's 350 lines of hand-written JS and has powered all my blogs and personal websites for years. It currently powers https://yakko.dev.
I added plugins this year which made it really powerful and allows me to keep the core small.
Markdown to html was a fun project. I wrote a tool like pandoc, with far fewer features, for school about 10 years ago.
I needed pandoc, but the internet and electricity were both out, so I built my own in a race against my dying ebay laptop battery.
bigfishrunning 18 hours ago [-]
Good article, I even remember the Yak Shaving Day episode of Ren and Stimpy but never made the connection with the slang term
NoboruWataya 12 hours ago [-]
My current after work activity is building a basic window manager (on top of river[1]) and asking myself what I am doing with my life. I'm not sure if I needed to read this or if this is the last thing I needed to read. It's not even so much fun as a kind of burning curiosity. "Shaving this yak would be stupid and unnecessary, I'm not going to waste my precious time doing it. ...but if I were to shave this yak, I wonder what would it look like?"
Also, Ren and Stimpy, there's a blast from the past!
I can't blame them. I instantly know what they mean when they use that phrase, but I have to think just a little bit to remember what "yak shaving" means. It's a cute name, but it's not intuitive at all. You have to learn it.
hankbond 7 hours ago [-]
This was a very well written piece that contains just the right amount of context to understand how to place the concept, an easily digestible length, and a sort of to the point whimsy that's not overbearing. Saving this as a reference for writing style!
pyrolistical 14 hours ago [-]
I’ve been yak shaving the interfaces not the implementation.
I used ai to convert c headers into in nice zig code. Then I link to the library.
It’s cheap to use zig translate-c to convert c headers but the output isn’t nice.
You can give ai c++ source which usually has more documentation than the compromised flat c header. It allows you to do a better zig port. Zig greatly cuts down the noise in c headers as everything needs to have long prefix for namespacing. But in zig we can just nest things properly.
We can introduce intermediate layers to use proper tagged unions and distinguish ?T, *T, [*]T
dblohm7 15 hours ago [-]
Yak shaving is only fun when you don't have managers who don't care about the circumstances breathing down your neck.
jeltz 15 hours ago [-]
That is true for software engineering in general. If you have a manager like that nothing is fun. And the products you build are likely to be bad.
kccqzy 9 hours ago [-]
Better yet, find a manager like my own manager who spent a literal quarter yak shaving!
oooyay 15 hours ago [-]
As in most things I think it's a mixture of quantity and set and setting.
I enjoy a yak, but right sizing my yak is pretty important to my enjoyment of it. Maybe the yak doesn't get a full shave but gets a trendy hair cut, and that's okay.
I leave my yaks at home when I go to other engineers decision meetings, project kickoffs, or RFCs.
godelski 12 hours ago [-]
> Of course, this is an extreme success story; most yak shaving fails.
To be fair, this is true for most things. Though that doesn't mean it's useless or not a worthwhile endeavor.
I think we often make a mistake by assuming that when there's no visible output that time was wasted.
When I was in grad school this hit me, and everyone I knew, pretty hard. But when looking back I think most of the progress I made was entirely invisible. Those "failures" are not so much failures as narrowing the search space. Unless you have a full understanding of the problem before you begin (lol[0]), then this is always going to be true.
Which made me change my view on a lot of things and realize you just need to trust people. Help people get unstuck and out of rabbit holes but just because there isn't visible progress doesn't mean there isn't progress. If we try to make all progress visible then the reality is we just misalign from our actual goals.
So Yak Shave. There's lots of hidden treasures, even if you don't think it's a treasure at the time
[0] bahahaha I'd love to live in that fantasy world. Nothing is so well defined, even when using formal languages like math. Exploration is always required (yes, even in research. No one plans everything before they start working. The difference between researchers and industry is just how much up front strategizing they do. But exploration always happens, even if through different mediums)
jemiluv8 17 hours ago [-]
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
kazinator 16 hours ago [-]
> Both stories came after the term yak shaving was coined
They are yakocryphal. A real yakrilege to spread such nonsense.
zem 16 hours ago [-]
the version I learnt the phrase from had the end of the chain as
- oh we should paint it
- we need a paintbrush
- I hear yak hair makes the best paintbrushes
- here I am, shaving a yak
made more sense than the examples given in the op
rzzzt 14 hours ago [-]
Internet Search Thing now tells me sable (for soft brushes) and hog hair (for wire-like brushes) is the best hair for this purpose. Oxen occasionally show up. Yaks nowhere to be found.
Coincidentally, this is also the first time I'm hearing about sable.
clscott 14 hours ago [-]
So yak shaving comes after bike shedding?
18 hours ago [-]
hippopotenuse 17 hours ago [-]
... but it's a highland cow
18 hours ago [-]
dance2die 14 hours ago [-]
Living like Leornado Da Vinci.
Triphibian 9 hours ago [-]
In another universe he called it "Whizzing on an electric fence."
dhosek 8 hours ago [-]
But the name of the game is, “Don’t whiz on the electric fence”!
Cider9986 17 hours ago [-]
That is a beautiful animal.
nephihaha 14 hours ago [-]
Except it's a Highland cow not a yak.
hankbond 7 hours ago [-]
Sometimes I think yak shaving is mostly just ADHD I self delude into being productivity.
wizardforhire 15 hours ago [-]
Maybe the most beautiful examples of the joy and importance of yak shaving that I’ve ever come across is inheritance machining on youtube. [1]
But truthfully part of the process of creating in general is yak shaving… as is so often said “trust the process”.
Arguably, the entire concept of tech debt is owed to the lack of yak shaving.
I wonder if there ever has been a person who wanted yak hair, and had a hairy yak in the backyard, but though "I don't want to engage in yak shaving, I'll buy prepackages yak hair from Steppe Depo."
I think it's helped me at work. Even though I don't have a job with anything related to music or audio, getting in the weeds of building a complex app like this has a way of teaching you all sorts of things. But even if it weren't, it's fun! When work is stressing, for some reason I find coding something completely unrelated, fun and fully my own de-stressing too.
I find you working 30 years on this game engine/application platform very cool and admirable! I hope this or some other project of mine accompanies me for that long.
Hah!
I couldn't figure out the 3D math for quake, or write a fast texture mapper, so I stuck to working on things like Doom level editors.
But, I loved the quake console so I made a similar thing for my editor, basically just a hot key that swung it down and I could change a few hard-coded variables and added some commands like loading/saving files.
You're in excellent company from Feynman onward.
> The yak shaving was at least 50% about loading the abstractions into my brain fully.
I haven't always made a version of new kind of system I'm trying to understand but I always try to at least find a toy model that I can play with to confirm understanding.
Even if I ended up moving to something not hand written the learning helped me find which tools are actually the tools I want to use. Helps me reason about what's necessary.
I fully believe you can't reason about things unless you have some understanding beyond the minimum needed to reason about them. Otherwise you just have unknown unknowns.
AI is great if you simultaneously guide it and let it guide you. I take my time building a very detailed spec for what I want, then run it through the AI looking for contradictions, misconceptions, edge cases, performance bottlenecks, potential optimizations… anything that might cause problems in the future. Usually these discussions lead to multiple spec-improvement journeys, and that’s where the bulk of learning in a project comes from. Sometimes the AI will flag actual issues, while other times I might need to rein in its proposals — mostly in terms of feature creep and finding non-existing problems. I believe this back-and-forth is the most significant aspect of making the best out of yak shaving.
By the time the spec is “final”, it can be quickly implemented by an AI as I watch, review and test, with practically zero code banging on my part. This way, I get to understand precisely how the project works, make it tailored to my needs, and still not waste time, muscles or even mental bandwidth with menial coding.
Upside: Only the features you actually need. Likely fewer dependencies. You know exactly what your yak looks like under the fur.
If you're making a complicated webapp, use your favorite framework to make it functional, and then if it's functional and not already fast enough, look at the slowest parts and replace them with faster alternatives. It's not going to result in the most elegant solution, but in most cases it will be good enough. Better to have something that works than to spend an extra year reinventing the wheel.
There's also the old saying about how a good programmer is lazy. There's two ways to interpret that. Seems we've shifted to the bad kind of lazy (i.e. easy/minimal upfront work)
Stewart Butterfield shaved the shit out of two yaks at his video games company, which eventually became Flickr and Slack.
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.
That said, I've seen so many developers, especially indie game developers, waste their time yak shaving (having fun) and then running out of funds and having to give up their dream because instead of achieving their goal,ship an indie game and have income for the next one, they shaved yaks work on a custom game engine or custom UI system or some other thing that's a solved problem and not the actual goal.
I have a friend doing it now. I know he's having fun so I don't want to tell him to stop. But I also know he'll likely hit a point where he needs to take a job and give up his dream because he's not actually pursuing it, it's having too much fun yak shaving.
https://youtube.com/shorts/kSJgLA1frS4?is=2RA7C0EDEe7Mg8Fp
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.
Sometimes one turns into the other. For instance I started building an agent based wiki generator fully vibed. I just wanted to test out if it was possible to mostly automate information extraction and conceptualization. Tried three times before realizing that the path I was attempting to travel was just not going to get me the results I wanted (fully automated meant I was not reflected in the wiki). So I finally started more carefully vibing out an application that implemented some of what I learned would be useful, at the same time I was developing a structurally similar app for local dev harnessing. Realizing that they had a lot in common, I started yak shaving and focused on building a framework that would make it much easier to whip up these types of agent based apps. This is the thing I started from the ground up building much more intentionally and thoroughly.
AI is used all throughout, but the amount of leash differed from holding without looking to wrapped around my wrist twice I'm basically holding the collar at this point.
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.
Made a post about how you learned to touch type? Or improved something keyboard-related? “I don’t think that typing code was ever the bottlenck”.[1] Now we’re supposed to be grateful for non-deterministic code completion, ah it saves us millions of keystrokes a year.
Some will cry Goomba Fallacy. Yeah of course. Could be that many lurker accounts started posting more, displacing the gatekeeper typist hackers. Now it’s all of a sudden an even split. Huh.
The OP was not about AI. But thankfully there was a top-level meta comment to drag us down into that pit.
[1] The non sequitur of it all is a separate topic
Yaks [1] have a shoulder hump you can't miss.
0: https://en.wikipedia.org/wiki/Highland_cattle
1: https://en.wikipedia.org/wiki/Yak
So yes, you shave the yak, but at least the clippings are precisely the length and colour you need, and the yak’s resulting hairstyle is pleasing to your eye.
- I want to add a shell function that invoked Claude in a VM via Lima using API keys stored in 1Pass
- But that means I need a way of templating the YAML file that will define Claude's VM and a reliable way of syncing state between it and my machine
- I could use a templating language like Jinja or Starlark, but that's another dependency for a relatively simple job
- Also, what if I want to use Pi or opencode someday?
- So I spent more time than I care to admit hacking a Bash function that replaces template variables in Lima YAML files that doesn't throw a cow when you throw in single or double quotes.
(I got my Claude VM function thing working, and it works really well!)
What was your solution for this? Keeping hosts reliably synced across the network is a perpetual source of frustration for me.
Yak shaving, as I experienced it - is when nothing works unless you do something else first, and something else needs it too.
I need to fix a bug, but I have to reproduce it first. I cannot reproduce it, because there is an entire other bug that prevents me from doing it. So I have to take the other route. But the other route does not work because the infrastructure is busted, and there's a problem on the server. To get the server to work, I need to contact John. But I need to do it through the ticket filing system and it is not behaving well today, so I need to find a workaround first. And after getting the ticket filing system to work I'm finding that John is not on the job today, because he took PTO. But some say Jim might help me. Jim is just some guy, he is in the other depratment, and I cannot get to him through the ticket system. And so I send an email to Jim, but Jim is not responding. And I need to find him physically in the building. So I need to know where his desk is. And there's an entire other system to find where Jim's desk is and I don't have the authorization to use it. So apply for the authorization and wait a bit. And then I learn where Jim's desk is, and then I go there and it is empty.
I guess that's why the blog name stays on screen and covers the text when I scroll down, with fully transparent background so it doesn't even cover the article text, it blends with it which distracts my eyes a little too much. If it was any other blog post I'd be certain it's a bug, but here I'm not sure if it isn't intentional, and one of those customization a ready-made software wouldn't let them do.
I added plugins this year which made it really powerful and allows me to keep the core small.
[1] https://github.com/yakkomajuri/teeny
I needed pandoc, but the internet and electricity were both out, so I built my own in a race against my dying ebay laptop battery.
Also, Ren and Stimpy, there's a blast from the past!
[1] https://isaacfreund.com/software/river/
> I could just use kubernetes
…billion years later still nothing operational
I used ai to convert c headers into in nice zig code. Then I link to the library.
It’s cheap to use zig translate-c to convert c headers but the output isn’t nice.
You can give ai c++ source which usually has more documentation than the compromised flat c header. It allows you to do a better zig port. Zig greatly cuts down the noise in c headers as everything needs to have long prefix for namespacing. But in zig we can just nest things properly.
We can introduce intermediate layers to use proper tagged unions and distinguish ?T, *T, [*]T
I enjoy a yak, but right sizing my yak is pretty important to my enjoyment of it. Maybe the yak doesn't get a full shave but gets a trendy hair cut, and that's okay.
I leave my yaks at home when I go to other engineers decision meetings, project kickoffs, or RFCs.
I think we often make a mistake by assuming that when there's no visible output that time was wasted.
When I was in grad school this hit me, and everyone I knew, pretty hard. But when looking back I think most of the progress I made was entirely invisible. Those "failures" are not so much failures as narrowing the search space. Unless you have a full understanding of the problem before you begin (lol[0]), then this is always going to be true.
Which made me change my view on a lot of things and realize you just need to trust people. Help people get unstuck and out of rabbit holes but just because there isn't visible progress doesn't mean there isn't progress. If we try to make all progress visible then the reality is we just misalign from our actual goals.
So Yak Shave. There's lots of hidden treasures, even if you don't think it's a treasure at the time
[0] bahahaha I'd love to live in that fantasy world. Nothing is so well defined, even when using formal languages like math. Exploration is always required (yes, even in research. No one plans everything before they start working. The difference between researchers and industry is just how much up front strategizing they do. But exploration always happens, even if through different mediums)
They are yakocryphal. A real yakrilege to spread such nonsense.
- oh we should paint it
- we need a paintbrush
- I hear yak hair makes the best paintbrushes
- here I am, shaving a yak
made more sense than the examples given in the op
Coincidentally, this is also the first time I'm hearing about sable.
But truthfully part of the process of creating in general is yak shaving… as is so often said “trust the process”.
Arguably, the entire concept of tech debt is owed to the lack of yak shaving.
[1] https://youtube.com/@InheritanceMachining
https://www.ulaandlia.com/collections/mongolian-baby-yak-woo...
Oh wait, you meant figuratively!