NHacker Next
- new
- past
- show
- ask
- show
- jobs
- submit
login
▲But yak shaving is fun (2019) (parksb.github.io)self.__VINEXT_RSC_CHUNKS__=self.__VINEXT_RSC_CHUNKS__||[];self.__VINEXT_RSC_CHUNKS__.push("2:I[\"aadde9aaef29\",[],\"default\",1]\n3:I[\"6e873226e03b\",[],\"Children\",1]\n5:I[\"bc2946a341c8\",[],\"LayoutSegmentProvider\",1]\n6:I[\"6e873226e03b\",[],\"Slot\",1]\n7:I[\"3506b3d116f7\",[],\"ErrorBoundary\",1]\n8:I[\"a9bbde40cf2d\",[],\"default\",1]\n9:I[\"3506b3d116f7\",[],\"NotFoundBoundary\",1]\na:\"$Sreact.suspense\"\n:HL[\"/assets/index-BLEkI_5r.css\",\"style\"]\n")an>
Rendered at 21:47:18 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
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.
So from my perspective you still need to know how to do the thing to catch the errors. Also, are you not missing out on the unknowns?
If an ai does a thing, fair enough. But you haven't tried to work it out yourself, done the wrong thing, to realise why it's done that way.
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.
The problem/trap in that case is, a lot of throwaway code ends up not being thrown away in the end, up to and including the prototype becoming the product (even if it was never meant to be).
It's sort of like "premature optimisation is the root of all evil". That shouldn't imply you should use completely the wrong language and data type.
You need to think about where you are going. Just that you shouldn't be focussing on micro problems when you haven't finished the big picture as it were.
To my mind we should be talking about problems as fractals. Get the broad shape right, and then start zooming into the details. That doesn't mean you should start off with the wrong shape.
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)
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.
Hardly scientific but I took one of those online tests and it said I was not, but it wouldn’t surprise me if I am at least a little on the spectrum.
Stewart Butterfield shaved the shit out of two yaks at his video games company, which eventually became Flickr and Slack.
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
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.
The Urban Dictionary [1] defines it as: "Any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you're working on."
So it is a perfect fit for what you described.
[1] https://www.urbandictionary.com/define.php?term=yak+shaving
> When asked how he did research, the great Latinist and Historian of Religion Eduard Norden (1868-1941) explained: "I keep all my ties in one big shoe-box. Every time I try to pull out one specific tie, all the others come out as well, because everything in there is so entangled. This is also the way I do research."
Or perhaps Carl Sagan's, "To make an apple pie from scratch, you must first create the universe."
- 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.
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.
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.
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.
Also, Ren and Stimpy, there's a blast from the past!
[1] https://isaacfreund.com/software/river/
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
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
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.
They are yakocryphal. A real yakrilege to spread such nonsense.
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)
- 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.
> I could just use kubernetes
…billion years later still nothing operational
https://www.ulaandlia.com/collections/mongolian-baby-yak-woo...
Oh wait, you meant figuratively!
Building your own is great, but it's not yak shaving.
Yak shaving is fixing fractal brokenness that you notice while punching through layers of existing systems to finally fix the root cause of the original thing you cared about.
See, e.g. Hal replacing a lightbulb: https://www.youtube.com/watch?v=AbSehcT19u0