Yak hair has also been used for wigs and costumes. The Chewbacca costume from the Star Wars trilogy was largely made of yak hair, as were Spock’s eyebrows on Star Trek.
“I want to wax the car today.”
“Oops, the hose is still broken from the winter. I’ll need to buy a new one at Home Depot.”
“But Home Depot is on the other side of the Tappan Zee bridge and getting there without my EZPass is miserable because of the tolls.”
“But, wait! I could borrow my neighbor’s EZPass…”
“Bob won’t lend me his EZPass until I return the mooshi pillow my son borrowed, though.”
“And we haven’t returned it because some of the stuffing fell out and we need to get some yak hair to restuff it.”
And the next thing you know, you’re at the zoo, shaving a yak, all so you can wax your car.
I'm missing some actionable advice. Obviously "just leave the primary requirement in the chain unfulfilled" is the first step. Maybe it resolves itself later or will not be required at all. But I often see situations, where the solution would be to "shave the yak so you and everyone else can do X". But probably this is part of the "maybe it resolves itself later" strategy, just from the other perspective.
Unless you're Donald Knuth, then please do so that people can format their math with your system for the next half a century (TeX was released in 1978).
Isn't this terrible advice? It's basically saying "be OK with things not getting fixed".
I've always heard of Yak shaving as essentially necessary steps in order to actually resolve issues. It's absurd that one needs to shave Yaks but necessary to complete projects.
Isn't being a founder actually Yak shaving? Dealing with the weird abstract minutiae that are needed to make a business run?
If the advice had been to find creative ways to resolve dependencies, that would be one thing, but the point of this post seems to be "just fail".
Actually, I think the job of an early stage founder is to fix things just enough.
You don't want them to be broken, but being okay with them being far short of perfect is what is needed to survive.
As far as employees, they too must decide how deep to go to fix a bug or add a feature. As a hyperbole, a naive employee might rewrite a functioning java program in rust to "fix it", taking far longer than correcting logic in the existing program would.
Ah, ok, so that's the good faith reading. It's not "don't fix things" it's to triage issues that do need to get fixed. That is, don't give in to competitionist tendencies or "fixing things right", but to fix them well enough and to make sure to prioritize well.
That makes a lot more sense, thanks.
The article didn't really say this all that clearly.
It's advice about prioritizing. You can go in any direction with work tasks and end up yak shaving, but if you are trying to "make the machinery move" as a founder would, you cannot go deep into that yet. You have to first clarify the larger Venn diagram of what you're solving and address just the stuff that has strong overlap. There are a lot of those problems as well.
Most advice to founders is terrible because it is such a low success area with a million unusual ways to fail that one advice won't work for all. You may prioritize wrong spending efforts on Yak Shaving while your competitor eats your business, or you may be focused on delivering without worrying about quality that when a competitor comes with a quality product, they toss you out.
A good example of 2nd is Windows Mobile, when iPhone launched and was being wowed upon a simple act would have been to copy key features/touch UI and capture the market. They had a year or two window before iPhone would be competitive. But CE and MS UI frameworks were dumpster fire compared to BSD/Linux that competition was based on and that it took 5 attempts to get something decent out and they had lost it all. If in early 2000s had MS did Yak Shaving to ensure CE is good, they would have few more trillions in that market cap.
I've heard the term used in a purely negative sense, while personally thinking it's often necessary and sometimes brilliant to do some yak shaving. Some of the best yak shavers I know are essential people, even in a "move fast" startup environment, because they effect significant change and improvement that can lift the whole team out of a local maximum of productivity.
Maybe for people who use it negatively, "refactoring" or "unplanned improving" isn't "yak shaving" until you've gone beyond what's reasonable. E.g. if you're doing some recursive refactoring, and improving the code base, great, but yak shaving is when you've truly gone off course.
Either way, I think this is where healthy team dynamics are so useful, because it's hard for the yak shaver to know if they've gone off course or are doing something unplanned but useful. If I think I'm deep in a yak shaving exercise, but I think the results will be beneficial, I announce that I'm yak shaving and explain why. If the rest of the team thinks it isn't truly a useful exercise, they can guide me out of it.
Clearly the way to improve things is to shorten the chain of preconditions as much as is reasonable.
In your example, it sounds like refactoring can “go off course”, but if we’re just shortening a chain of preconditions, how would it go off course? Wouldn’t we know what precondition we were eliminating?
Poor choice of words on my part. In my example one is going "off course" in the sense that one is spending more time on the yak shaving than is justified by the scope of the problem being solved (e.g. let's say refactoring a script that is only run once, and spending more time on the refactoring than if one had manually replicated the script's output). Maybe "too deep in the rabbit hole" would be a more illustrative phrase.
A great way to deal with things like this is to stop using weird analogies that everyone understands differently.
Dont call it yak shaving, call it what it actually is you're doing. Dont say "youre yak shaving lol stop", say "youre refactoring parts that worked fine" or something.
Not everything has to be a cool metaphor, sometimes that really doesnt work well. Same for technical debt. Ask four people to define it and youll get four pretty different answers.
I disagree. Yak shaving, bike shedding etc, are good because they capture something that’s a lot longer to describe in a short form and give you a “mental handle” to the concept.
That's not really yak shaving, though. Yak shaving, to me, is where you want to make a small improvement to something or test something out. But you're not currently working on that part of the project, so you pull it out of source control. However, it doesn't compile on your machine, you don't have a dependent library. So you get the library but it's not compatible with some version of something else. Yadda yadda yadda.
Since 2005 there have been a lot of tools to avoid yak shaving, although some of them are easy and some present a lot of potential yaks to shave if you're not already using them. For example, venv+pip+pinned versions is a good solution in python, and relatively easy to use. Docker is great if you're skilled with it but for a new user, it is basically yak shaving to get used to it. Nix could potentially eliminate a lot of yak shaving but also has a learning curve. Vagrant was/is useful for spinning up development machines that match production, especially if you're not super skilled in containers or not using them in production.
I find a lot of yak shaving in the Javascript ecosystem, and also when there is some third-party API or scripting language is involved. ETL is usually like this as well. As a casual programmer, this is the stuff that makes programming unfun and intimidating.
30 comments
[ 1.2 ms ] story [ 69.2 ms ] thread(For context, GSB stood for Girl Scout Benefit, and absolutely not for grad student beer, which was consumed Friday afternoons.)
https://www.youtube.com/watch?v=AbSehcT19u0
But as you mentioned, No Yaks included however
> Yak fiber wool has been used by nomads in the Trans-Himalayan region for over a thousand years to make clothing, tents, ropes and blankets.
https://en.wikipedia.org/wiki/Yak_fiber
Yak hair has also been used for wigs and costumes. The Chewbacca costume from the Star Wars trilogy was largely made of yak hair, as were Spock’s eyebrows on Star Trek.
However, this Stack Exchange answer suggests that yaks are typically combed and sheared rather than shaved: https://skeptics.stackexchange.com/questions/28217/do-yaks-g...
I've always heard of Yak shaving as essentially necessary steps in order to actually resolve issues. It's absurd that one needs to shave Yaks but necessary to complete projects.
Isn't being a founder actually Yak shaving? Dealing with the weird abstract minutiae that are needed to make a business run?
If the advice had been to find creative ways to resolve dependencies, that would be one thing, but the point of this post seems to be "just fail".
Actually, I think the job of an early stage founder is to fix things just enough.
You don't want them to be broken, but being okay with them being far short of perfect is what is needed to survive.
As far as employees, they too must decide how deep to go to fix a bug or add a feature. As a hyperbole, a naive employee might rewrite a functioning java program in rust to "fix it", taking far longer than correcting logic in the existing program would.
Source: have been both a founder and employee
That makes a lot more sense, thanks.
The article didn't really say this all that clearly.
A good example of 2nd is Windows Mobile, when iPhone launched and was being wowed upon a simple act would have been to copy key features/touch UI and capture the market. They had a year or two window before iPhone would be competitive. But CE and MS UI frameworks were dumpster fire compared to BSD/Linux that competition was based on and that it took 5 attempts to get something decent out and they had lost it all. If in early 2000s had MS did Yak Shaving to ensure CE is good, they would have few more trillions in that market cap.
Maybe 3 yaks is a reasonable limit in some places, other more urgent things can only support 1 yak
(Seth seems to be advocating 0 yaks, that... probably isn't possible? Sometimes shit just won't work until you do something else first)
Maybe for people who use it negatively, "refactoring" or "unplanned improving" isn't "yak shaving" until you've gone beyond what's reasonable. E.g. if you're doing some recursive refactoring, and improving the code base, great, but yak shaving is when you've truly gone off course.
Either way, I think this is where healthy team dynamics are so useful, because it's hard for the yak shaver to know if they've gone off course or are doing something unplanned but useful. If I think I'm deep in a yak shaving exercise, but I think the results will be beneficial, I announce that I'm yak shaving and explain why. If the rest of the team thinks it isn't truly a useful exercise, they can guide me out of it.
Yak-shaving is a chain of preconditions, e.g:
- In order to do Z, I must first do Y
- In order to do Y, I must first do X
- In order to do X, I must first do W
Etc.
Clearly the way to improve things is to shorten the chain of preconditions as much as is reasonable.
In your example, it sounds like refactoring can “go off course”, but if we’re just shortening a chain of preconditions, how would it go off course? Wouldn’t we know what precondition we were eliminating?
The act of shaving it is good
Dont call it yak shaving, call it what it actually is you're doing. Dont say "youre yak shaving lol stop", say "youre refactoring parts that worked fine" or something.
Not everything has to be a cool metaphor, sometimes that really doesnt work well. Same for technical debt. Ask four people to define it and youll get four pretty different answers.
Since 2005 there have been a lot of tools to avoid yak shaving, although some of them are easy and some present a lot of potential yaks to shave if you're not already using them. For example, venv+pip+pinned versions is a good solution in python, and relatively easy to use. Docker is great if you're skilled with it but for a new user, it is basically yak shaving to get used to it. Nix could potentially eliminate a lot of yak shaving but also has a learning curve. Vagrant was/is useful for spinning up development machines that match production, especially if you're not super skilled in containers or not using them in production.
I find a lot of yak shaving in the Javascript ecosystem, and also when there is some third-party API or scripting language is involved. ETL is usually like this as well. As a casual programmer, this is the stuff that makes programming unfun and intimidating.
https://www.youtube.com/watch?v=AbSehcT19u0