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".
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."
“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.
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.
"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...
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.
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.
Comments
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".
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."
Most of this doesn’t seem in conflict to me.
“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).
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.
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.
"Just be good, and don't be bad" isn't technically wrong...
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.
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.
Hey, you could make a book out of that idea.
clearly someone needs to containerize the yak, then it would be easy to both shave and wax it.