I can't understand what an organization could do to reduce yak shaving. If task X is required, and X is blocked by task Y, and Y is blocked by Z, then task Z is required too. That's yak shaving, and I don't know how a github organization could do anything to help.
Careful assuming these terminological subtleties are universally shared. Where I work now, 'ratholing' is something you do in conversations, where you go deep into a specific problem that isn't relevant to the real purpose of the meeting.
'rabbitholing' is more tumbling down a series of investigative avenues to see where they lead, to a single purpose - and it's not necessarily a bad thing! sometimes you come out of the rabbithole with a solution.
And 'yak shaving' is tedious work that is not obviously actually doing the task at hand, yet nonetheless, and in spite of your best efforts to find an alternative, it turns out to be necessary before the real work can begin.
None of which I think comport exactly with OPs definitions.
yak shaving had a widely understood meaning which is the one described here (at least within Google, where internal social networking systems share ideas like this quickly). I actually use the term "recursive yak shave".
See, a friend of mine suggested having some illustrations to go with the concepts to glue them in the mind of the reader. And since I have no artistic skills, I had to get them commissioned.
Since I grew up with Italian Disney comic books, an anthropomorphic yak sounded perfect, so I turned to a friend for suggestions on artists, and eventually contacted FurryViza (https://twitter.com/FurryViza).
I just gave her a prompt of what I had in mind and let her take it from there. I'm absolutely stunned by how it turned out!
I view "yak shaving" more as: I have X to do. I find I can't to X because of issue Y. I start to fix issue Y, but discover issue Z. I then start to fix Z but can't because of A. A "rabbit hole" to me is different: I have to do X, which I think is simple, but no, there's Y to consider, then Z, then A (think, oh, date processing).
Yup, though nobody I worked with saw it that way anymore.
There's a significant drift in its meaning, and there's also dissonance between different areas in the same industry. That's why I wanted to define how this jargon ends up used by me and my peers, and provide a reference point.
(There's a bigger point about value judgement -- I tried not to give too much negative or positive connotations to the whole yak situation, because I don't believe there's an objective mode for it.)
If someone claims to have coined a term but does not quite grasp its meaning, do you give them greater credibility?
More likely the author heard the term, made an assumption as to its meaning, and either misremembered its source, or it was coined and spread elsewhere.
I'm not sure what it means for the one who coined a term to not understand the term they coined. (At https://americanexpress.io/yak-shaving/ they are quoted as stating clearly that they coined it and attempted to spread it. Which need not be true, but if you're going to suggest that it's false, you'll also need some evidence.)
It's not always. Sometimes it's fixing overlooked bugs along the way. Or filling gaps in documentation (I consider bad docs bugs, but maybe everyone doesn't). Or upgrading components that are deprecated. I wouldn't consider any of that refactoring. It's more like maintenance.
Since the author is foreign, he can perhaps be forgiven for confusing idioms, but not for being so pedantically wrong about it.
Specifically, he claims that true yak shaving is not really yak shaving, but “rabbit holing”.
The term “going down the rabbit hole” comes from Lewis Carroll’s Alice in Wonderland, where she follows a white rabbit on a nonsensical series of adventures as she gets distracted from her school work.
The term “yak shaving” comes from the Ren & Stimpy Show, a nonsensical Canadian cartoon, and is about all the interdependent tasks that need to be done in order to accomplish your seemingly simple goal, and thus revealing why it is that the yak (a creature with notoriously long, tangled, dirty fur) never gets shaved and a cautionary tale about why it must not be neglected.
I think post-Matrix, Carrollian rabbit holes have an additional connotation of ‘seeing how deep the rabbit hole goes’ - ie that while the journey may be strange and full of distractions, truth might be found at the bottom. But as I said in my own response the cultural meanings of these terms are not universal.
Leaving the casual xenophobia aside, I never said anything about "real" yak shaving.
Indeed, as others noted already, I clarified that everything I'm writing is from the point of view of my niche, which (as the title implies) is systems engineering. In the SRE/PE/DevOps meaning of the name, since that's also an adopted job title that has quite different semantics in other fields.
I'm glad _someone_ keeps track of where bits and bobs of jargon come from, because they'll make great trivia in a future episode of QI, but to be perfectly honest, I'm not profoundly interested in the philology of our terms as much as I have an interest on providing a quotable reference to explain specific work.
This is genuinely going to be helpful for me to share this with my colleagues and management.
> From an engineer point of view, this may sound trivial, but the truth is that your career depends heavily on how your manager, and their peers, perceive your impact and your work.
> I have to admit my track record of convincing management about the importance of my work based on this particular idiom has been… spotty at best. I still believe in the concept, though.
The above are from “diagonal contributions” but to me also apply to rake collecting.
But I have to wonder, why is this the case in software engineering?
We go through K-12 school being told to make the world a better place and have a positive impact. Most religious teachings impart the idea of helping others.
In nearly every profession or job role from waiting tables to building houses, a common complaint is when someone doesn’t “help out” when needed.
So why in software engineering is the expectation warped such that “collecting rakes” to make sure others have a better chance at successful contributions often seen as rabbit-holing, or procrastinating, or just flat out wasteful?
And especially so when done diagonally across teams? Why am I expected to only own my own pieces and not improve others?
And most importantly, why does it feel like my reputation and career still hinges on the quality of my work and how it interacts with others’ work, if I then feel I need to ask for forgiveness every time I collect rakes or work diagonally?
There’s a lot of rakes. Some don’t bother anyone. Some are well-managed by others and don’t need your attention. Others you may not have the skill to pick up. Yet still exist others that shouldn’t be picked up now.
Knowing which ones you should pick up, how many, when to timebox it etc is a skill in and of itself. I’ve never felt unrewarded for that but:
a) I already work very quickly. I try to pick up rakes in my spare time (ie my main work is blocked for some reason)
b) I generally try to make sure no one else is tasked with picking up the rake
c) I identify the rakes that are relevant to my work (I’m generally not fixing rakes in the Linux Kernel)
There’s another problem and this one has to do with organizational pain. Most organizations are set up to not listen to your external opinion. So if you pick up rakes there the other manager will be relieved of solving the problem while your manager isn’t getting enough of your focus on your current job which isn’t helping anyone (the other manager needs to hire someone and won’t even if you’re telling them they should)
As I understood it, the original metaphor had you shaving yaks not for the shorn yaks but for the yak hair, which you needed for a thing, which you needed for a thing, etc, having passed up alternatives along the way that could have been acceptable but were rejected out of some unspecified combination of perfectionism and Not-Invented-Here.
35 comments
[ 2.1 ms ] story [ 77.0 ms ] thread'rabbitholing' is more tumbling down a series of investigative avenues to see where they lead, to a single purpose - and it's not necessarily a bad thing! sometimes you come out of the rabbithole with a solution.
And 'yak shaving' is tedious work that is not obviously actually doing the task at hand, yet nonetheless, and in spite of your best efforts to find an alternative, it turns out to be necessary before the real work can begin.
None of which I think comport exactly with OPs definitions.
Also that joke about how downing a single plane on the way to a furry convention could cripple a countries IT capabilities :P
His technical blog posts are top notch mixed in with furry drawings and content galore. Definitely unexpected for every first time reader.
Since I grew up with Italian Disney comic books, an anthropomorphic yak sounded perfect, so I turned to a friend for suggestions on artists, and eventually contacted FurryViza (https://twitter.com/FurryViza).
I just gave her a prompt of what I had in mind and let her take it from there. I'm absolutely stunned by how it turned out!
You can tell that friend that it worked! They’re a great addition to the post.
There's a significant drift in its meaning, and there's also dissonance between different areas in the same industry. That's why I wanted to define how this jargon ends up used by me and my peers, and provide a reference point.
(There's a bigger point about value judgement -- I tried not to give too much negative or positive connotations to the whole yak situation, because I don't believe there's an objective mode for it.)
More likely the author heard the term, made an assumption as to its meaning, and either misremembered its source, or it was coined and spread elsewhere.
Specifically, he claims that true yak shaving is not really yak shaving, but “rabbit holing”.
The term “going down the rabbit hole” comes from Lewis Carroll’s Alice in Wonderland, where she follows a white rabbit on a nonsensical series of adventures as she gets distracted from her school work.
The term “yak shaving” comes from the Ren & Stimpy Show, a nonsensical Canadian cartoon, and is about all the interdependent tasks that need to be done in order to accomplish your seemingly simple goal, and thus revealing why it is that the yak (a creature with notoriously long, tangled, dirty fur) never gets shaved and a cautionary tale about why it must not be neglected.
Indeed, as others noted already, I clarified that everything I'm writing is from the point of view of my niche, which (as the title implies) is systems engineering. In the SRE/PE/DevOps meaning of the name, since that's also an adopted job title that has quite different semantics in other fields.
I'm glad _someone_ keeps track of where bits and bobs of jargon come from, because they'll make great trivia in a future episode of QI, but to be perfectly honest, I'm not profoundly interested in the philology of our terms as much as I have an interest on providing a quotable reference to explain specific work.
I am impressed by your ability to appear both arrogant and a bit of a culture snob in one short sentence. Bravo!
This is genuinely going to be helpful for me to share this with my colleagues and management.
> From an engineer point of view, this may sound trivial, but the truth is that your career depends heavily on how your manager, and their peers, perceive your impact and your work.
> I have to admit my track record of convincing management about the importance of my work based on this particular idiom has been… spotty at best. I still believe in the concept, though.
The above are from “diagonal contributions” but to me also apply to rake collecting.
But I have to wonder, why is this the case in software engineering?
We go through K-12 school being told to make the world a better place and have a positive impact. Most religious teachings impart the idea of helping others.
In nearly every profession or job role from waiting tables to building houses, a common complaint is when someone doesn’t “help out” when needed.
So why in software engineering is the expectation warped such that “collecting rakes” to make sure others have a better chance at successful contributions often seen as rabbit-holing, or procrastinating, or just flat out wasteful?
And especially so when done diagonally across teams? Why am I expected to only own my own pieces and not improve others?
And most importantly, why does it feel like my reputation and career still hinges on the quality of my work and how it interacts with others’ work, if I then feel I need to ask for forgiveness every time I collect rakes or work diagonally?
Something feels culturally wrong about this.
Knowing which ones you should pick up, how many, when to timebox it etc is a skill in and of itself. I’ve never felt unrewarded for that but: a) I already work very quickly. I try to pick up rakes in my spare time (ie my main work is blocked for some reason) b) I generally try to make sure no one else is tasked with picking up the rake c) I identify the rakes that are relevant to my work (I’m generally not fixing rakes in the Linux Kernel)
There’s another problem and this one has to do with organizational pain. Most organizations are set up to not listen to your external opinion. So if you pick up rakes there the other manager will be relieved of solving the problem while your manager isn’t getting enough of your focus on your current job which isn’t helping anyone (the other manager needs to hire someone and won’t even if you’re telling them they should)
Both sides of the coin have merit.
I wonder if the author does more of that for important writing, like documentation.
But as it's visible above, my artistry leaves a lot to be desired. So for something like this I commissioned it.
The artist is https://twitter.com/FurryViza and she did a great job.
Oh, god; I just added this simple little variant of this phrase, and now there are 33 reduce/reduce conflicts and 6 shift/reduce ...