81–90 of 100 posts
If you shave a yak, you get yak hair. And this material is like $35 a skein! https://www.ulaandlia.com/collections/mongolian-baby-yak-woo... Oh wait, you meant figuratively!
I agree 100% that yak shaving is fun. That said, I've seen so many developers, especially indie game developers, waste their time yak shaving (having fun) and then running out of funds and having to give up their dream because instead of achieving their goal,ship an indie game and have income for the next one, they shaved yaks work on a custom game engine or custom UI system or some other thing that's a solved proble…
Earlier quoted context omitted.
I wonder, how well does Yak-Shaving work for you with AI, how does it look for you specifically and how do you make sure it's not undermining the friction for learning things properly? I want to try some more yak-shaving soon too.
Yak shaving with AI allows me to function more as a systems designer, code reviewer and tester than a coder per se. AI is great if you simultaneously guide it and let it guide you. I take my time building a very detailed spec for what I want, then run it through the AI looking for contradictions, misconceptions, edge cases, performance bottlenecks, potential optimizations… anything that might cause problems in the fu…
So from my perspective you still need to know how to do the thing to catch the errors. Also, are you not missing out on the unknowns?
If an ai does a thing, fair enough. But you haven't tried to work it out yourself, done the wrong thing, to realise why it's done that way.
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 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.
Tangential but it's a story that I find funny. At a previous job, my coworkers coined the term "Thomasing" [1], referring to me, as "the act of having a question explained so thoroughly, detailed, and long-winded that the asker has lost interest in the question that they were asking". I thought it was pretty funny, because that does basically describe me in a nutshell. [1] Lovingly, it was a good, fairly-tight-knit g…
Earlier quoted context omitted.
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…
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 program…
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).
Building your own is great, but it's not yak shaving.
Yak shaving is fixing fractal brokenness that you notice while punching through layers of existing systems to finally fix the root cause of the original thing you cared about.
See, e.g. Hal replacing a lightbulb: https://www.youtube.com/watch?v=AbSehcT19u0
This feels like what is really splitting the programming community right now- those that have typically enjoyed the journey, and those that just want to be at the destination as soon as possible.
> When asked how he did research, the great Latinist and Historian of Religion Eduard Norden (1868-1941) explained: "I keep all my ties in one big shoe-box. Every time I try to pull out one specific tie, all the others come out as well, because everything in there is so entangled. This is also the way I do research."
Or perhaps Carl Sagan's, "To make an apple pie from scratch, you must first create the universe."
This feels like what is really splitting the programming community right now- those that have typically enjoyed the journey, and those that just want to be at the destination as soon as possible.
Riding horseback saves time over walking but it's harder to smell the roses along the way. Nevertheless, millions now ride horses recreationally.