Talk like a systems engineer: Yaks all the way down

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.

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 this was more furry art than I expected to see on a technical blog post.

Loved the post and the art.

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.

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

For what it's worth, "yak shaving" [did originally mean](http://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gs...) what the author calls "rabbitholing"; see [the person who claims to have invented the term](https://en.wiktionary.org/wiki/Talk:yak_shaving#Etymology) in the 1990s.

Neat art on the post

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.

Why would someone go to all the trouble of producing all those illustrations for an article about "yak" jargon?

I wonder if the author does more of that for important writing, like documentation.

You've not yak shaved until you've Yacc shaved.

Oh, god; I just added this simple little variant of this phrase, and now there are 33 reduce/reduce conflicts and 6 shift/reduce ...

I have an organization on GitHub dedicated to reducing yak shaving. https://github.com/DontShaveTheYak

Another good addition would be the phrase "to open a can of worms"

In an alternative universe I call the "yak shaving" refactoring