Yak shaving and fixing | Hacker News Reader

Yak shaving and fixing

sophiebits.com

98 pointsskellertor27 comments

Agree with the main point: Do regularly step outside "your" assigned work to fix problems.

I still think yak shaving is bad, but tautologically. It's only called yak shaving when you go too deep.

Not yak A: My build failed with no sensible error given, so I improved the build process to log errors better.

Not yak B: My build failed with no sensible error given, so I had to log into the build server to inspect it, so I had to run around asking people how to get remote desktop credentials. I then documented on the internal Wiki how and where to find credentials, and improved the build process to log errors better.

Yak territory: In scenario B, I found the remote desktop software is running an old version, so I set out to update it on the build server.

Deep Yak territory: While updating the remote desktop software, I realized that it would be good to update it on all build servers, so I make a script to do that. Such a script should also run automatically to upgrade to a newer version when it becomes available so I don't have to manually to this every time. I could run the script on the build master, but the script is in Python 3, and the build master only has Python 2 installed. Installing Python 3 I notice I need to keep Python 2 the default to not mess with execution of existing scripts. But the existing scripts are mostly thin layers above Python libraries that exist in Python 3, so it wouldn't be a big task to port them over and thus simplify everything.

The things you cite as "Yak territory" are just bad, anti-productive decisions.

Yak shaving, by definition, is a seemingly unrelated problem that _needs_ to be solved before progressing with the primary task. In other words, if it's merely an optional decision, it's not really "Yak shaving".

The only way you avoid Yak shaving is by an uncanny combination of careful planning and organizational flexibility. Sometimes Yak shaving can't be avoided, that's OK, it's a learning experience and it builds skills, character and funny stories.

> Yak shaving, by definition

Depends whose definition you choose to use. The apparent primary source[0] doesn't have it as a dependency, the later jargon file does[1], and then there are seem to be an approximate equal split of others.

[0] https://projects.csail.mit.edu/gsb/old-archive/gsb-archive/g...

[1] http://catb.org/jargon/html/Y/yak-shaving.html

My internal definition is something close to "7-steps removed"; yak-shaving is yak-shaving when you end up pretty far from the problem itself; whether its actually good or required is independent, just the fact that it might be time to start wondering if you went on too many tangents.

Eg quintessential example of knuth -- everything he did was good work, and in the end useful for his overarching goals... but at some point in the middle of that situation its time to start wondering if he's gone off the deep end. Whether you decide yes or no, it doesn't matter, you're still deep in yak territory

The problem is that nobody else is paying attention to the Yak. Its getting out of control and your house guest thought it was a rug the other day. All you need in order to shave it too is to sharpen your scissors, and the sharpener is at the hardware store. Easy.

The fact that that Seth Godins blog post that denigrates 'yak shaving' comes so prominent on web search for the term is really too bad - but he is not even a programmer! I believe that any healthy programmers culture supports yak shaving. The metaphor is an expression of how frustrating is to do the right thing, but it would not be a virtue if it was easy.

Yak shaving is the only sane way to maintain a big codebase. The more popular thing, and the root of all evil, is to add work arounds that mask the real problem instead of finding the right place for it somewhere deep down in the code. It is like: you discover a bug in a library that you use and instead of fixing it and sending patches to the author you just add a special case to deal with it. The result is that the code gets more and more irregular with special cases everywhere.

Indeed. If you don't shave your yak when you should, your yak(s?) will shed profusely and the hair will clog not only your shower, but also all the plumbing in your house. Thus, creating a kind of "kuldge debt".

Organizational culture matters here. There is little benefit to fixing things if you have a culture where speed matters above everything else and people are rewarded on how quickly they can do things.

I still remember the time I spent weeks working with a giant mess of undocumented (or, worse, documented incorrectly) code to get my job done as the first engineer at a startup. We had a new hire coming (and lots more coming after that), so I took the time to clean everything up and document all the fixes, then trained the person instead of leaving them to figure it all out. Result: they got up and running within a few days instead of a couple of weeks.

Of course, when review time came, I was told that the new hire had gotten up to speed much faster than I did, which was why they were being promoted over me...

Ouch. I learned that this was a management anti-pattern when I was younger from fiction of all places. I loved reading Piers Anthony, and I think it was in his Apprentice Adept series, there was a series of tests that a person had to take to become a citizen, and some of them were competitive. Of course, at one point the main character made the mistake of giving pointers to a competitor, and the competitor only got better as a result when they played a duet. It blew my mind as a teenager when the main character won the competition because his opponent played better when the two of them played together. It was such a foreign concept to me, that someone could act as a sort of force multiplier, and also be rewarded for it. After that, I don't think I ever hesitated to help bring people up. Even in college when grading curves meant others doing better could only hurt me, I'd still often try to explain things to people before a test.

It's a shame how many people never learned this lesson. Or maybe it's just a testament to how many bad managers there are that these are common things people get passed over for. Though, truthfully, if I were a manager, I'm a little afraid that I'd still be susceptible to this bias as well.

I don't see fixing the tools everyone in the team is using as you go along as yak shaving. That's just good manners.

Well, yeah, up to a point.

But if the fixing process ends up being the equivalent in cost, time and resources as putting together an expedition lead by your favorite project manager to fly to Kabul Afghanistan and then find a Yak and shave it-- that's more like the type of disruption that "Yak Shaving" refers to. It's not just a few quick edits.

I've always wondered, how much would it take for a good team of workers to leave their cubicles and literally shave a Yak?

> To be able to fix effectively, you gotta be willing to dive into code that you didn’t write. And into lower layers of the stack than you might be used to.

Honestly, this is usually why I like to fix bugs in tools too. This, and because I don't like there being bugs in things I rely on.

I always seem to find these issues when I'm in a hurry. They always show up when things are on fire. And they seem to have magically disappeared/unable to repeat, or are no longer an prioritized issue - when you have time to fix them.

I just happened to be reflecting on the term "yak shaving" this morning. I saw Free Solo last week, and was motivated (by the funny scene of Honnold and Caldwell in the little hotel room) to start keeping a programming journal. Writing in it this morning I realized that my efforts yesterday were a classic shave: I forked a library, started converting the tests to my own testing framework, updated a terminal coloring module that the test harness to uses, then added an interactive mode to update failing test expectations on the command line (which I've been wanting for ages), which enticed me to port some old termcap code I had to enter `cbreak` mode gracefully for one-touch `y/N` interactions (totally optional but made it feel good).

I appreciate Deestan's comment: "It's only called yak shaving when you go too deep." However I personally find the term to be more subtle than a blanket pejorative. To me, the experience is of working with a big mental stack of contexts, where I spend the day toiling on various far-removed dependencies in an effort to achieve some goal well (whatever "well" means that day). In this light, it's not that yak shaving is bad, but that there is some aspect of personal pride, and that it is hard to do without getting lost, working on things that end up not mattering, or losing momentum and motivation.

My efforts yesterday feel worthwhile. The detours I took succeeded, and yielded results that I have long desired. Other times I'm not so satisfied. Knowing when to start shaving seems to be an intuitive choice, because the payoff is too disparate and subtle to be calculated.

(There was an article on HN a while ago calling Knuth the patron saint of yak shaving, which I enjoyed, and which gave me the ideas that a) the term has something to do with pride in quality, and b) maybe it should not be used in a judgmental way. I also recall my late colleague James Golick, whom I miss dearly, using the term, with varying implications, to describe our daily work of untangling a web/mobile app that we inherited as contractors.)

I work in a place filled with broken yaks where only new projects have privilege and everything else is denigrated as maintenance and often shuffled to outsourced teams. Only when a yak causes major customer complaints does it get "shaved". There is no encouragement or reward in fixing things that are broken or to avoid them breaking eventually. Maybe we as technologists only like new and exciting things and keeping older (not necessarily all that old) things working well is considered beneath us.

I think it's helpful to split 'yak shaving' scenarios into 3 kinds, of which only 1 implies you should shave yaks as you encounter them: https://www.lesswrong.com/posts/nbiZc7KM2KEyCAaCP/in-support...

I don't look at Yak shaving any differently than a normal feature/bug workflow. If something crops up during development or fire-fighting I will make a note and continue on with what I was doing.

Later, the notes get written up into proper bug reports during the time I've set aside for this type of work.

These are added to the normal pipeline and prioritised the same as any other feature or bug. Important tasks rise to the top. Others are reserved for "cleanup sprints".

This does add some overhead but it means all tasks get careful consideration.

It also gives us a great list of short tickets to do on a Friday afternoon. Since these kinds of tasks usually don't need the kind of focus that normal development does.

On fixing bugs, the author writes: “...there is always a logical explanation for why a computer is behaving in a certain way...”

I agree. Determining the logical explanation for why a bug exists is required in order to fix a bug correctly. Any fix made without doing so is pure conjecture. That said, it can sometimes be acceptable to write a fix based on conjecture, but it should at least be documented as such.

When things are sane, I'll generally add a few hours to a day or so to each ticket to spend on improving process, refactoring, or just deep thinking about the domain and the stack. Nobody notices and the effort improves everything I do in the future.

I use this chart from XKCD https://xkcd.com/1205/ to decide how much time to spend on something. Sometimes you need to do something that takes longer if there is a broken process that is only going to get worse.

I'm like the author, I do fix things as I find them, but only if there is test cases to run afterwards. I'm unlikely to mess with something if it's not fully hooked into our test environment.

Reply on news.ycombinator.com