Live data from Hacker News

But yak shaving is fun (2019)

parksb.github.io

51–60 of 100 posts

Re: But yak shaving is fun (2019)

#51

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 platfor…

> 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.

Re: But yak shaving is fun (2019)

#52

  > 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)

Re: But yak shaving is fun (2019)

#53
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!

[1] https://isaacfreund.com/software/river/

Re: But yak shaving is fun (2019)

#54
post #19

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…

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.

Re: But yak shaving is fun (2019)

#55
post #47

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.

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.

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.

Re: But yak shaving is fun (2019)

#56
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!)

Re: But yak shaving is fun (2019)

#57

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.

Agreed. (Controlled) yak shaving is a requirement for juniors IMO

Re: But yak shaving is fun (2019)

#58
post #19

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…

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.

> 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.

Re: But yak shaving is fun (2019)

#59
post #19

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…

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.

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.

Re: But yak shaving is fun (2019)

#60
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.

Post reply on HN