[HN Gopher] Don't Shave That Yak (2005)
___________________________________________________________________
Don't Shave That Yak (2005)
Author : Brajeshwar
Score : 34 points
Date : 2024-01-28 15:45 UTC (7 hours ago)
(HTM) web link (seths.blog)
(TXT) w3m dump (seths.blog)
| dgacmu wrote:
| This post has the wrong original source for the term, it didn't
| come from the media lab, it came from the AI lab, popularized
| when Jeremy Brown sent a delightful email to the GSB list:
| https://projects.csail.mit.edu/gsb/old-archive/gsb-archive/g...
|
| (For context, GSB stood for Girl Scout Benefit, and absolutely
| not for grad student beer, which was consumed Friday afternoons.)
| jwilk wrote:
| Also it says the term was coined in 2010, which is a weird
| thing to say in a 2005 article.
| wodenokoto wrote:
| This is the first time I've seen yak shaving explained with an
| example that actually ends with someone shaving a yak.
| paddez wrote:
| I've always considered this Malcolm in the Middle scene to
| perfectly explain Yak Shaving (a number of years before Yak
| Shaving was a thing).
|
| https://www.youtube.com/watch?v=AbSehcT19u0
|
| But as you mentioned, _No Yaks included_ however
| rvbissell wrote:
| I knew the exact scene you were going to link to.
| philwelch wrote:
| Yak hair has a number of uses:
|
| > 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...
| Aerbil313 wrote:
| "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.
| pjio wrote:
| 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.
| huijzer wrote:
| 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).
| klysm wrote:
| Some yaks may have valuable coats
| tired-turtle wrote:
| This is a great example of a garden path sentence. My mind
| tripped over "please do so" several times.
| abetusk wrote:
| 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".
| mooreds wrote:
| > "be OK with things not getting fixed"
|
| 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
| abetusk wrote:
| 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.
| crq-yml wrote:
| 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.
| blackoil wrote:
| 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.
| neonsunset wrote:
| You can't stop me
| zilti wrote:
| That's the spirit!
| habitue wrote:
| I've always thought of having a yak shave level, and then you
| decide how many yals deep you are and cut it off at some point.
|
| 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)
| lemmsjid wrote:
| 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.
| zilti wrote:
| Well said, thanks!
| jt2190 wrote:
| I'm having trouble understanding your example.
|
| 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?
| lemmsjid wrote:
| 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.
| ithkuil wrote:
| The yak hair is bad.
|
| The act of shaving it is good
| lionkor wrote:
| 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.
| klysm wrote:
| 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.
| rzzzt wrote:
| That "mental handle" makes it way too easy to push or pull on
| the "mental door" behind which the concept lies. "That's an
| XY problem".
| silasdavis wrote:
| For me an essential aspect of a yak shave is that I don't usually
| know that I was in one until after I've exited.
| Lightbody wrote:
| If you need a visual presentation of this, enjoy this classic
| scene from Malcolm in the Middle:
|
| https://www.youtube.com/watch?v=AbSehcT19u0
___________________________________________________________________
(page generated 2024-01-28 23:01 UTC)