Agree with the main point: <i>Do</i> regularly step outside "your" assigned work to fix problems.<p>I still think yak shaving is bad, but tautologically. It's
only called yak shaving when you go too deep.<p>Not yak A: My build failed with no sensible error given, so I improved the build process to log errors better.<p>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.<p>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.<p>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 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.<p>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.
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.<p>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.<p>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...
> 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.<p>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).<p>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 <i>well</i> (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.<p>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.<p>(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: <a href="https://www.lesswrong.com/posts/nbiZc7KM2KEyCAaCP/in-support-of-yak-shaving" rel="nofollow">https://www.lesswrong.com/posts/nbiZc7KM2KEyCAaCP/in-support...</a>
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.<p>Later, the notes get written up into proper bug reports during the time I've set aside for this type of work.<p>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".<p>This does add some overhead but it means all tasks get careful consideration.<p>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...”<p>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 <a href="https://xkcd.com/1205/" rel="nofollow">https://xkcd.com/1205/</a> 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.<p>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.