Yak shaving sure... but bike shedding is a term I've only ever heard used to dismiss valid criticisms without any counter argument. I've seen plenty of projects where the simplest thing could have made all the difference, but it was hand-waved away as "bike shedding". So the project moves ahead, ignoring any feedback, and then people wonder why the project failed.
I've never encountered someone using the phrase "bike shedding" when it wasn't in relation to a project that was in the middle of failing and the speaker is looking for any excuse to ignore the real reason why. So instead they blame everyone around them for focusing on "trivial" things. How many times was Zune's exclusively brown color and "squirt" feature brought up and dismissed as bike shedding? And when it was released, all the tech press could talk about was that it looked like poop and squirted songs at you.
I can definitely see how it could be used to steamroll over objections, but I don't think that's a problem with the term so much as who/how it's being used. Having a simple term in a team's shared vocabulary to point out when excessive effort is being used on something trivial is important, because it can prevent a lot of time from being wasted.
Here's an actual example from recently: “Hey, I think this parameter [that we can't decide if it should be a boolean or an enum] is turning into a bikeshed.” “Good point, leave it as a boolean for the moment and we can always refactor later.” Something like that is not going to make or break a project, and being able to concisely point that out is useful.
This isn't really anything new. Sometimes, it's important to get that hose or whatever the real-world equivalent is. The real advice is to not waste time on things that aren't important. To poorly extend the metaphor, this is running to home depot to buy a pack of gum. I've caught myself a few times tweaking my i3 config or something to "increase productivity" to procrastinate something I don't want to do. The important thing is to not do that. This advice, however, is already well-known.
"Doing it well now is much better than doing it perfectly later"
That sounds fine until hundreds of developers make this choice every single day, and your project is so riddled with technical debt that forward progress becomes hard to muster. I'll be the first to admit that I postpone or neglect Yak Shaving myself.
If we think about it the other way around, if we shaved yak every single time, then the herd would be shaved, and we'd be able to work without so many distractions.
I guess the big problem with Yak Shaving, at least for a dayjob, is that it doesn't always count towards making forward progress toward your goals or OKRs, or whatever we want to call them. I think we need to recognize the importance of Yak shaving and reward the shavers.
That's where refactoring comes in. Start with simple, local things. Make sure all the variables are properly and consistently named. Fix the indentation. De-duplicate cut'n'paste code (carefully!) where appropriate. Expand out functions that are only called from one place, where appropriate. Convert awkward control flow into more natural flow. So on and so forth. Abstract out common functionality into its own functions/classes.
You'll be amazed how, after a few iterations of this approach, even the worst spaghetti turns into something that you can start to reason about. (In fact, I find myself mentally referring to this kind of refactoring as 'combing spaghetti'.) And if you're careful to make sure none of your changes alter the function of the code, you don't lose the 'tried-and-tested' advantage of the original code.
This is peephole refactoring. Architectural redesigns (the ones that result in 1/10th the code with the same functionality but more robust, maintainable, etc etc) aren't feasible to do incrementally like this. If you're resourceful and clever, you can sometimes get to a certain point with both the old and the new architecture in place at the same time, but at some point you have to make the hard cut-over, and redevelop all the old features/edge-cases in the new system.
Even if you're starting with a disgusting hairball, a bottom-up approach will still get you to something understandable. At this stage you'll probably find that you can fix it one subsystem at a time without doing a full blank-slate rewrite. And once all of your subsystems are nice and independent and well designed, changing up the high-level architecture is far, far easier and safer.
To be honest, most discussions about anti-Yak Shaving are about willfully ignoring the fact that you're going to have to shave a Yak, then asking people to strategically pluck single hairs whenever they're walking past the Yak because razors are expensive.
> If we think about it the other way around, if we shaved yak every single time, then the herd would be shaved, and we'd be able to work without so many distractions.
The boy scout rule is a good compromise. Whatever areas of code you touch, leave it cleaner than how you found it. It doesn't mean following every path that leads to or from it (yak-shaving), but it's also not introducing new tech debt.
In medium to large size orgs "not shaving the yak" means pressing ahead with your deliverables and sidestepping wider issues. Doing this makes you appear indispensable to most middle managers but encouraging this en-masse is a long-term disaster for the org.
The org culture compels the behaviour, and is not really an individual choice.
This is actually part of the business justification for using SaaS/PaaS instead of rolling your own. E.g. skip implementing auth when just starting and simply use Firebase.
The key is to shave the yak before you're forced to.
Lots of sellers get their start on e.g. Amazon marketplace, and they find it becomes progressively more awful as they scale up.
If they make the switch to their own site on their own schedule, this is fine.
If a competitor puts in false reviews on their product and gets them banned, or their search rankings mysteriously plummet, the loss of revenue can bankrupt them before they stake their own site.
I've been hearing this term probably since TFA was published, but it's only been recently, ~15 years into my career that I realized how much I'm guilty of this. It's so easy to get caught up in that PR for that upstream dependency so your code is a bit prettier.
I've also noticed that the low-level yak shaving I tend towards becomes much less tempting if I focus on decoupling what I'm writing. As long as a function/module I'm not super happy with is nicely isolated/decoupled, who cares? I can easily swap it out later if it becomes an issue.
I know nothing about waxing cars but don’t you actually need the hose? Wouldn’t the actual solution be to get to Home Depot without the EZ pass, or buying it instead of borrowing it.
This is to say that you should do the necessary steps but no more?
I think the idea in the analogy would be to just use a bucket and the broken hose as a good enough solution... Like find alternatives if the right path ends in a yak
> Like find alternatives if the right path ends in a yak
But taking his example at face value -- I mean, you are going to have to return that pillow someday, and to return the pillow you are going to have to go to the zoo and shave the yak. I mean, yeah, today day maybe you can just deal with the old broken hose. But if you'd shaved the yak last weekend instead of whatever other thing you were doing, you could have bought a new hose this weekend. The longer you wait to do what you need to do anyway, the more hassle you end up dealing with.
> Yak Shaving is the last step of a series of steps that occurs when you find something you need to do. “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.”
...
> So, what to do?
> Don’t go to Home Depot for the hose.
This analogy is rather awful. The takeaway I'm getting from this is "if you hit an obstacle, stop trying." Surely that isn't what the author is trying to tell us?
I think you may be taking away a different than intended lesson. The implication is that you can wash the car with a broken hose(tape it!), or with no hose at all(buckets/pans).
Yes, now we're getting somewhere. The fallacy is in recursively accepting the first solution to a given problem. Rather, it's worthwhile to ruminate[1] on multiple solutions before embarking on one that exceeds the apparent complexity of the problem.
Digging into the analogy, though, this is a story about maintenance failures. At some point, you're going to make good with your neighbor and also repair or replace your hose, and it sounds like getting a pass for that bridge could save time in the future. Waxing your car might be a vanity project. What's most important in this moment?
Yak shaving is "Any seemingly pointless activity which is actually necessary [...]". Yak shaving is necessary. It isn't an indicator that you shouldn't shave the yak.
Now, if you can't decide if yak shaving is necessary, ask yourself 4 questions:
- What am I really trying to do?
- Is this the best way to do that?
- Is it necessary to do that?
- Do I really need to do it right now?
But also, don't let progress get in the way of progress. Sure, over-perfecting can get in the way of immediate progress, but under-perfecting (quick-fixes, avoiding refactors, etc.) can get in the way of future progress. The question of "should I refactor this or can I get away with a quick fix?" really needs to be asked all the time. There is no silver bullet.
I used to find this quite an appealing analysis - don’t waste time on busywork after all. We’ve all heard that advice. I’m not sure it works in practice.
What happens if every time you go to solving one of these problems, you go about three layers deep in your analysis rather than to the root cause.
Sometimes it isn’t a Yak to be shaved but actually something that done right, can save you a lot of time and effort. Particularly in a field like software development where the cost of rework is very high.
As construction friends of mine like to say, concrete erasers are expensive.
Perfection is the enemy of good enough. BUT...technical debt does factor in when choosing the easier route that may incur longer-term problems with short cuts.
You should be careful about how you manage your time. There is an art to decide where to draw the line. For this super-contrived example that literally involves breaking into a zoo to get from an animal a part that can be bought off the shelf with same-day delivery... I am not sure that the answer is "don't buy a new hose." You could just pay the cash toll to drive across the Tappan Zee Bridge. Get a great hose, wash your car, and continue to ignore your neighbor whose pillow you ignored.
In general, you should have a cost and benefit attached to every action you are planning. Buying a hose is super easy and solves a lot of problems; you can start watering your garden again, you can wash your car, you can spray your kids. The cost is low, the benefit is high, so you should consider it today. At the bottom of the chain is "break into a zoo and shave a wild animal". The benefit is low, you can buy yak hair on Amazon. The cost is high, you're likely going to be maimed AND end up in prison. So don't do that!
This is a super dumb example and we shouldn't even be discussing it. Management consultants always have a contrived example where their advice sounds good because the example is bad. This is that.
That's the thing I'm discovering with recent new management. They've always got a clever sounding one liner to back up their directive. But a lot of the time it leaves me less convinced that their directive is the correct one because it doesn't actually reveal anything new about the issue.
This indicates both side of yak-shaving. The chain of requirements in the contrived example is (IMO) deliberately silly, and misses what you're (correctly) pointing out: it's not yak shaving if it's building capability...
...unless you know you won't - or don't know that you will - benefit from that boosted capability. Then it's back to yak shaving.
It's so weird that we have a group of people who tell us don't shave the yak, and then a group of people telling us to measure twice and cut once, and a group of people telling us that technical debt is bad, and a group of people telling us that we need to move fast and break things. Then you have Joel Spolsky telling us we should never rewrite our code, but the anti yak shavers telling us not to think too far ahead and just get the pen to the paper as quick as possible.
But I guess you're not going to sell many books by saying "think exactly as hard as you need to about the things you need to think about, make smart choices, pick relevant abstractions when you can, and choose the right tool for the job".
I don't think yak shaving is the same as planning ahead.
Instead, yak shaving is about putting in a bit of effort now to 'do things right' rather than quickly work around some issue.
The difference being that in planning ahead, the 'right long term thing to do' is hard to figure out. Whereas with yak-shaving, the 'right long term thing to do' is quite obvious, but the question is whether it is worth it.
> But I guess you're not going to sell many books by saying "think exactly as hard as you need to about the things you need to think about, make smart choices, pick relevant abstractions when you can, and choose the right tool for the job".
Eh, expand that out to 20,000 words and you could probably sell a few copies.
I think it'd mostly want to expand on mitigating problems that happen when you make dumb choices, can't find good abstractions or have poor tools. You're going to learn through failure, so you have to suffer through the failures.
It’s a shame we’ll likely never look forward to a time when we’re considered professionals who’ve spent decades mastering our craft and are the best qualified to determine what’s best when.
Agree 100% with what you're saying but an often unexplored dimension of this discussion is that in so many cases software solutions are so ridiculously better (more productive, less waste) than manual alternatives that it almost doesn't matter.
And fwiw - I think a book that helped walk you through the decision making process for everything would be a winner.
> “Technical debt is bad”
> This is an oversimplification. Perhaps dangerous is a better word than bad.
Technical debt is not dangerous or bad, it's just debt. It continues to compound the longer you don't pay it down. You have to be strategic with the resources you have, but often taking on debt is the right thing to do (provided you intend to pay it back later).
The definition of yak shaving is that shaving the yak is a prerequisite to the task at hand. You can't continue without doing it.
Of course, just because this appears to be the case doesn't always mean it's true. Plenty of times I've been waiting on X to do Y and I've managed to make significant progress on Y just by pretending that X is already done, and working on Y until X is actually necessary.
> you're not going to sell many books by saying "think exactly as hard as you need to about the things you need to think about, make smart choices, pick relevant abstractions when you can, and choose the right tool for the job".
You're right. That's exactly what needs to be done but it will NEVER be perfect. There's always going to be some Yak shaving in all but the most pedestrian of projects.
Project managers might call it "unplanned work". They know it happens. Savvy ones accept it to some extent and realize that's a important part of how people build grit, experience and good judgement-- sometimes it takes a few hard knocks.
One of the hallmarks of a senior engineer is knowing how much time to spend on something. It's easy to blow past an important decision carelessly, but it's also too easy to get lost in the woods overthinking, over-documenting, setting up meetings, blocking on other teams, etc. The expert knows when to advise caution vs. when to say, "this is getting ridiculous, let's just make a choice."
> "think exactly as hard as you need to about the things you need to think about, make smart choices, pick relevant abstractions when you can, and choose the right tool for the job"
"Just be good, and don't be bad" isn't technically wrong...
Yak shaving is an inevitable, unavoidable part of working in a large company with mature (or rather: conservative and safe) engineering practices.
A feature I’m working on right now involves a ridiculous amount of knowledge of the service component architecture and release process because making any change coordinated across two different hot services with different release schedules is absolutely hellacious. So even though customers will barely notice the change, I have to do all this release and flag and migration and analysis work simply because people actually use and depend on our service and we have to be really careful not to break it.
It’s not necessarily a bad thing. If we didn’t have to yak shave, it would mean we either weren’t making money, didn’t care about our customers, or didn’t do anything important. In 2005, maybe most people weren’t working on hot services with complex architectures that people depended on. But imagine what would happen if the tens of thousands of people working on AWS all collectively decided to not shave yaks when they updated their services.
On an individual basis, your decision to not shave a yak might save time and effort. At scale, it increases your error rate. If you have thousands of developers and hundreds of components/services to keep track of, issues are already an inevitability, and you’re increasing the rate at which issues would occur by a lot.
Software Developers will often be tempted to automate the yak shaving away so they don't really have to deal with it all. This is a good attitude to have, but when combined with automation it can also be dangerous. I've seen many automated solutions run off on their own doing entirely the wrong thing. It's very often safer to slow down, build tools to assist, but have a human there to push the go button. It's not as sexy, and if you're scale is large enough you're also building tools to help with analysis. But in the long run you'll avoid problems.
The problem is that when everybody avoids shaving the yak, the yak gets too hairy.
"Oh, the build server can't handle that one lib, I'll just commit the DLL directly"
"Oh that library is too confusing, I'll just roll my own for this one use-case".
The opposite of yak-shaving is technical debt. If you find yourself in "there's a hole in my bucket" territory, that's a sign that nobody is paying down that technical debt ever.
There are thankless jobs in software development that basically amount to "making sure the yak is already shaved".
I like the expression "Yak Shaving", but I don't really understand what it's supposed to mean.
In the story, obviously the guy should return his neighbor's pillow, whether or not he's going to immediately ask for another favor, and he probably ought to get a new hose also. So even if he thinks shaving the yak is way too much trouble to get his car waxed, shouldn't he shave the yak anyway?
A lot of people in this thread are talking about it in the context of technical debt, but I've always interpreted it as an allegory about time management: you find yourself shaving a yak when you've ‘gone down the rabbit hole’ and traversed several layers down the dependency chain of your to-do list. When you realize this is a good time to take a moment to reflect on the situation. Sometimes, the yak really does need shaving right now, but sometimes it's a result of performing a depth-first search, so to speak, and it's better to back up and take another tack, leaving the yak for later. And even if that yak really does need shaving, taking a moment to reflect on why you've found yourself shaving it can be useful to prevent frustration that the original task doesn't even seem to have been started yet.
Yeah, it seems the metaphor is about incorrectly performing a depth-first-search, when breadth-first-search is the right algorithm in general to find the optimal solution.
I've always interpreted yak shaving as "work that is neither necessary nor sufficient to complete a task."
Sometimes it's bikeshedding (looking through color swatches for your navbar when you dont even have a working CRUD system), sometimes it's indirect value add to you or your team (evaluating new ORMs or IDEs), sometimes it's just karma farming in the universe (sending PRs to a new GitHub repo you've found that almost solves your issues...)
I think of it as concentric circles: the center is the goal, the first ring is the tasks you need to complete, and so on ... and yak shaving is anything more than 2 layers away (or outside the circle entirely!)
> "And the next thing you know, you’re at the zoo, shaving a yak, all so you can wax your car."
I'm interpreting this as (maybe unintentionally) creating new forms of debt - next time you want to visit the zoo, you may need to resolve some favors to the zookeeper that let you into the yak exhibit.
I think it works better for every day life things, because in the context of work it amounts to making bad decisions. Building a new feature vs. fixing or refactoring old code.
I really tried to get into Seth Godin's work, blogs, books, video, the altmba. I just find there is no substance beyond wishy washy ideas and turns of phrase. I just read his latest blog where he tells us to look inside a box of infinity and 'dance with it'. What am I missing here? Isn't this nonsense?
I can speak to the blog. First, the daily posting rigor is inspiring. It makes you want to do something useful every day.
Second, many of his blog posts prompt you to ask questions of the work you are doing. They are not always the questions you expect and sometimes the pairing of your current situation and the current blog post are fortuitous.
Third, he has strong, uncommonly held about how to start, continue and finish, and find an audience for meaningful work. Unless you are particularly prolific, his writing should help you raise your expectations for yourself.
Fourth, he’s an executive and product creator and sometimes it’s worth understanding how those people think, whether to emulate them or just to sell to them.
That said, at this point I would start with his books because he’s had so much time to distill his blog ideas into longer writing and it’s better to catch up with a book than to read a lot of old posts.
For me, Seth Godin is about defining a vocabulary around being a productive and decent human-being and thinking about your approach and psychology. I think the ideas help the reader to navigate in this complex world without having a cynical worldview.
I have just read the last blog post and I believe it is about the amygdala and creative process.
"Dance with it." is probably a reference to a topic he has written in several blog posts and books. He just plants some ideas here and there. As an example, yesterday, I watched MIT OCW video "How To Speak by Patrick Winston" where he tells to repeat the subject at least 3 times. I immediately remembered this blog post: https://seths.blog/2010/12/you-will-be-misunderstood/
I agree with 1123581321's points. In addition, he always narrates his own audiobooks. The Dip is one of the first audiobooks I have listened to. He has a clear easy to understand voice.
While I can understand Seth's content may not work for everyone. It works for me. I like the man enough to regard him as a role-model so my channels are open for him(permission marketing maybe?). I also find his writing fun.
Look at the fruitful discussion his short blog post has created on HN. I found many comments to be very valuable here. I think that’s how his value is showing.
Yak shaving is so common in the industry that I started a company renting pre-shaved yaks, until I realized it was the fur they were after. So I pivoted, and my new elevator pitch is: "It's like Uber for yak fur".
86 comments
[ 5.2 ms ] story [ 150 ms ] threadI've never encountered someone using the phrase "bike shedding" when it wasn't in relation to a project that was in the middle of failing and the speaker is looking for any excuse to ignore the real reason why. So instead they blame everyone around them for focusing on "trivial" things. How many times was Zune's exclusively brown color and "squirt" feature brought up and dismissed as bike shedding? And when it was released, all the tech press could talk about was that it looked like poop and squirted songs at you.
Details matter.
Here's an actual example from recently: “Hey, I think this parameter [that we can't decide if it should be a boolean or an enum] is turning into a bikeshed.” “Good point, leave it as a boolean for the moment and we can always refactor later.” Something like that is not going to make or break a project, and being able to concisely point that out is useful.
That sounds fine until hundreds of developers make this choice every single day, and your project is so riddled with technical debt that forward progress becomes hard to muster. I'll be the first to admit that I postpone or neglect Yak Shaving myself.
If we think about it the other way around, if we shaved yak every single time, then the herd would be shaved, and we'd be able to work without so many distractions.
I guess the big problem with Yak Shaving, at least for a dayjob, is that it doesn't always count towards making forward progress toward your goals or OKRs, or whatever we want to call them. I think we need to recognize the importance of Yak shaving and reward the shavers.
Pretty soon, you are surrounded by nothing but yaks, and even yak shaving requires shaving ten other yaks first.
You'll be amazed how, after a few iterations of this approach, even the worst spaghetti turns into something that you can start to reason about. (In fact, I find myself mentally referring to this kind of refactoring as 'combing spaghetti'.) And if you're careful to make sure none of your changes alter the function of the code, you don't lose the 'tried-and-tested' advantage of the original code.
Do yaks not regrow their fur in this analogy?
The org culture compels the behaviour, and is not really an individual choice.
Lots of sellers get their start on e.g. Amazon marketplace, and they find it becomes progressively more awful as they scale up.
If they make the switch to their own site on their own schedule, this is fine.
If a competitor puts in false reviews on their product and gets them banned, or their search rankings mysteriously plummet, the loss of revenue can bankrupt them before they stake their own site.
I've also noticed that the low-level yak shaving I tend towards becomes much less tempting if I focus on decoupling what I'm writing. As long as a function/module I'm not super happy with is nicely isolated/decoupled, who cares? I can easily swap it out later if it becomes an issue.
This is to say that you should do the necessary steps but no more?
But taking his example at face value -- I mean, you are going to have to return that pillow someday, and to return the pillow you are going to have to go to the zoo and shave the yak. I mean, yeah, today day maybe you can just deal with the old broken hose. But if you'd shaved the yak last weekend instead of whatever other thing you were doing, you could have bought a new hose this weekend. The longer you wait to do what you need to do anyway, the more hassle you end up dealing with.
> “Oops, the hose is still broken from the winter. I’ll need to buy a new one at Home Depot.”
...
> So, what to do?
> Don’t go to Home Depot for the hose.
This analogy is rather awful. The takeaway I'm getting from this is "if you hit an obstacle, stop trying." Surely that isn't what the author is trying to tell us?
Digging into the analogy, though, this is a story about maintenance failures. At some point, you're going to make good with your neighbor and also repair or replace your hose, and it sounds like getting a pass for that bridge could save time in the future. Waxing your car might be a vanity project. What's most important in this moment?
[1] my first yak pun in 2020
Now, if you can't decide if yak shaving is necessary, ask yourself 4 questions:
And remember, perfect is the enemy of good.Don't let perfection get in the way of progress.
What happens if every time you go to solving one of these problems, you go about three layers deep in your analysis rather than to the root cause.
Sometimes it isn’t a Yak to be shaved but actually something that done right, can save you a lot of time and effort. Particularly in a field like software development where the cost of rework is very high.
As construction friends of mine like to say, concrete erasers are expensive.
In general, you should have a cost and benefit attached to every action you are planning. Buying a hose is super easy and solves a lot of problems; you can start watering your garden again, you can wash your car, you can spray your kids. The cost is low, the benefit is high, so you should consider it today. At the bottom of the chain is "break into a zoo and shave a wild animal". The benefit is low, you can buy yak hair on Amazon. The cost is high, you're likely going to be maimed AND end up in prison. So don't do that!
This is a super dumb example and we shouldn't even be discussing it. Management consultants always have a contrived example where their advice sounds good because the example is bad. This is that.
...unless you know you won't - or don't know that you will - benefit from that boosted capability. Then it's back to yak shaving.
But I guess you're not going to sell many books by saying "think exactly as hard as you need to about the things you need to think about, make smart choices, pick relevant abstractions when you can, and choose the right tool for the job".
The difference being that in planning ahead, the 'right long term thing to do' is hard to figure out. Whereas with yak-shaving, the 'right long term thing to do' is quite obvious, but the question is whether it is worth it.
Eh, expand that out to 20,000 words and you could probably sell a few copies.
I think it'd mostly want to expand on mitigating problems that happen when you make dumb choices, can't find good abstractions or have poor tools. You're going to learn through failure, so you have to suffer through the failures.
And fwiw - I think a book that helped walk you through the decision making process for everything would be a winner.
“Don’t shave the yak.”
- stay focused on the task at hand.
“Measure twice cut once”
- if the output cannot be easily fixed, double check yourself before committing.
“Technical debt is bad”
This is an oversimplification. Perhaps dangerous is a better word than bad.
“Move fast and break things”
- a hyperbolic response to perfectionism
Technical debt is not dangerous or bad, it's just debt. It continues to compound the longer you don't pay it down. You have to be strategic with the resources you have, but often taking on debt is the right thing to do (provided you intend to pay it back later).
> - stay focused on the task at hand.
The definition of yak shaving is that shaving the yak is a prerequisite to the task at hand. You can't continue without doing it.
Of course, just because this appears to be the case doesn't always mean it's true. Plenty of times I've been waiting on X to do Y and I've managed to make significant progress on Y just by pretending that X is already done, and working on Y until X is actually necessary.
You're right. That's exactly what needs to be done but it will NEVER be perfect. There's always going to be some Yak shaving in all but the most pedestrian of projects.
Project managers might call it "unplanned work". They know it happens. Savvy ones accept it to some extent and realize that's a important part of how people build grit, experience and good judgement-- sometimes it takes a few hard knocks.
"Just be good, and don't be bad" isn't technically wrong...
A feature I’m working on right now involves a ridiculous amount of knowledge of the service component architecture and release process because making any change coordinated across two different hot services with different release schedules is absolutely hellacious. So even though customers will barely notice the change, I have to do all this release and flag and migration and analysis work simply because people actually use and depend on our service and we have to be really careful not to break it.
It’s not necessarily a bad thing. If we didn’t have to yak shave, it would mean we either weren’t making money, didn’t care about our customers, or didn’t do anything important. In 2005, maybe most people weren’t working on hot services with complex architectures that people depended on. But imagine what would happen if the tens of thousands of people working on AWS all collectively decided to not shave yaks when they updated their services.
On an individual basis, your decision to not shave a yak might save time and effort. At scale, it increases your error rate. If you have thousands of developers and hundreds of components/services to keep track of, issues are already an inevitability, and you’re increasing the rate at which issues would occur by a lot.
Software Developers will often be tempted to automate the yak shaving away so they don't really have to deal with it all. This is a good attitude to have, but when combined with automation it can also be dangerous. I've seen many automated solutions run off on their own doing entirely the wrong thing. It's very often safer to slow down, build tools to assist, but have a human there to push the go button. It's not as sexy, and if you're scale is large enough you're also building tools to help with analysis. But in the long run you'll avoid problems.
If you do it incorrectly, it's more like Malcolm's dad [1], who is distracted by subtasks that are only minimally related to the initial goal.
Devs get the two mixed up quite often. Usually on Monday mornings...
1. https://youtu.be/AbSehcT19u0
"Oh, the build server can't handle that one lib, I'll just commit the DLL directly"
"Oh that library is too confusing, I'll just roll my own for this one use-case".
The opposite of yak-shaving is technical debt. If you find yourself in "there's a hole in my bucket" territory, that's a sign that nobody is paying down that technical debt ever.
There are thankless jobs in software development that basically amount to "making sure the yak is already shaved".
In the story, obviously the guy should return his neighbor's pillow, whether or not he's going to immediately ask for another favor, and he probably ought to get a new hose also. So even if he thinks shaving the yak is way too much trouble to get his car waxed, shouldn't he shave the yak anyway?
Sometimes it's bikeshedding (looking through color swatches for your navbar when you dont even have a working CRUD system), sometimes it's indirect value add to you or your team (evaluating new ORMs or IDEs), sometimes it's just karma farming in the universe (sending PRs to a new GitHub repo you've found that almost solves your issues...)
I think of it as concentric circles: the center is the goal, the first ring is the tasks you need to complete, and so on ... and yak shaving is anything more than 2 layers away (or outside the circle entirely!)
Consider my example of evaluating ORMs.
Option 1: Blindly choose first ORM from a Google search.
Option 2: spend 2 hours reading reviews, blogs, etc. to compare the 3 most popular ORMs.
Option 3: spend a day spinning up containers for each ORM, testing out a CRUD prototype for each, evaluating some basic cases.
Option 4: spend a week down the deep rabbit hole of ORM internals, query rolling, edge cases at scales your app will never see ...
And everything in between. None of it's necessary - even the ORM itself - but it's not all wasted effort either.
I'm interpreting this as (maybe unintentionally) creating new forms of debt - next time you want to visit the zoo, you may need to resolve some favors to the zookeeper that let you into the yak exhibit.
Second, many of his blog posts prompt you to ask questions of the work you are doing. They are not always the questions you expect and sometimes the pairing of your current situation and the current blog post are fortuitous.
Third, he has strong, uncommonly held about how to start, continue and finish, and find an audience for meaningful work. Unless you are particularly prolific, his writing should help you raise your expectations for yourself.
Fourth, he’s an executive and product creator and sometimes it’s worth understanding how those people think, whether to emulate them or just to sell to them.
That said, at this point I would start with his books because he’s had so much time to distill his blog ideas into longer writing and it’s better to catch up with a book than to read a lot of old posts.
I have just read the last blog post and I believe it is about the amygdala and creative process.
"Dance with it." is probably a reference to a topic he has written in several blog posts and books. He just plants some ideas here and there. As an example, yesterday, I watched MIT OCW video "How To Speak by Patrick Winston" where he tells to repeat the subject at least 3 times. I immediately remembered this blog post: https://seths.blog/2010/12/you-will-be-misunderstood/
I agree with 1123581321's points. In addition, he always narrates his own audiobooks. The Dip is one of the first audiobooks I have listened to. He has a clear easy to understand voice.
While I can understand Seth's content may not work for everyone. It works for me. I like the man enough to regard him as a role-model so my channels are open for him(permission marketing maybe?). I also find his writing fun.
HT to Seth :)
http://web.archive.org/web/20160818152109/http://rimantas.co...