Yak-shaving-shaming puts limits on the creativity of talented engineers by constraining them to existing patterns and practices or building on top of abstractions, and practically, that results in engineers and teams with less breadth. In an applied software world that's exploded in framework and library complexity in recent years, I think there are always going to be yaks in dire need of a shave.
This is one of the reasons I’ve never liked the aphorism "make it work, make it right, make it fast." By the time you get to the last point, say, having used Electron to build your graphing calculator, it is far too late to magically make it fast, like trying to make a Boeing 787 into a Cessna.
It's a bad aphorism if you take it literally and don't think about any nuance, but it's the correct priority. In many cases each of the three steps can take longer than the last, and each step is useless if the previous step isn't possible. The lesson is supposed to be to focus on each step at a time, not to completely ignore the other steps.
If you're making a complicated webapp, use your favorite framework to make it functional, and then if it's functional and not already fast enough, look at the slowest parts and replace them with faster alternatives. It's not going to result in the most elegant solution, but in most cases it will be good enough. Better to have something that works than to spend an extra year reinventing the wheel.
Similarly "move fast and break things" is a great strategy for learning. But it's terrible for creating production grade software. You break things to learn how they work, but then you got to go back and clean everything up or else you're just living in a dumpster. It's quite impressive how proudly people defend their dumpsters and actively criticize anyone who wants to clean it up. "Waste of time!" Cries the programmer struggling to implement a new feature through a mountain of tech debt
I'd say it's also a great strategy for throwaway prototypes (which I'd count as a kind of learning anyway: learning about your future product, its requirements, obstacles, etc).
The problem/trap in that case is, a lot of throwaway code ends up not being thrown away in the end, up to and including the prototype becoming the product (even if it was never meant to be).
I like that aphorism. But if it leads you to building a graphing calculator with Electron then I think it doesn't work, it isn't right, and it isn't fast.
There's also the old saying about how a good programmer is lazy. There's two ways to interpret that. Seems we've shifted to the bad kind of lazy (i.e. easy/minimal upfront work)
I don't think "make it work" necessarily implies starting with the wrong language.
It's sort of like "premature optimisation is the root of all evil". That shouldn't imply you should use completely the wrong language and data type.
You need to think about where you are going. Just that you shouldn't be focussing on micro problems when you haven't finished the big picture as it were.
To my mind we should be talking about problems as fractals. Get the broad shape right, and then start zooming into the details. That doesn't mean you should start off with the wrong shape.
