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…
Are you Autistic per chance?
Never diagnosed, if I am.
Hardly scientific but I took one of those online tests and it said I was not, but it wouldn’t surprise me if I am at least a little on the spectrum.
When I was in highschool I started writing a game in Qbasic. Along the way, I wanted it to have a console (like Quake) where you could enter commands and modify the game as you were running it. This lead me to create a scripting engine in Qbasic, and long story short, I’ve been on a yak shaving epic quest now for almost 30 years now. No game, but I have a hybrid C / Lua game engine/general purpose application platfor…
This is a great thing, because along the way one learns tons of stuff, that other not so interested/involved people never learn. It is a means of becoming a more capable developer/engineer.
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.
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 ab…
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…
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 love to throw away code. It seems people are afraid because it feels like wasted work. But I'll rewrite code multiple times. I'm convinced it makes me faster. We're running marathons, not sprints
I don't know what either are. Is there something notable about them?
Different species, similar niche. Highland cows are a breed of small cow bred to thrive in the rough conditions of the Highlands of Scotland, but sometimes kept in England for interest. Very hairy, and placid enough that they are always allowed to keep their horns. Yaks are a small domesticated bovid bred to thrive in the Himalayas. Very hairy, and apparently placid enough to ride.
Does not really feel accurate to how yak shaving was to me. Yak shaving, as I experienced it - is when nothing works unless you do something else first, and something else needs it too. I need to fix a bug, but I have to reproduce it first. I cannot reproduce it, because there is an entire other bug that prevents me from doing it. So I have to take the other route. But the other route does not work because the infras…
This is exactly yak shaving as well.
The Urban Dictionary [1] defines it as:
"Any seemingly pointless activity which is actually necessary to solve a problem which solves a problem which, several levels of recursion later, solves the real problem you're working on."
Wonder if Knuth was trying to determine how much tech one could generate out of a block device and still have a consistant normal form. (vs. yak shaving) --- looks like an infinate amount, just as long as (NP != P) & (shrodinger's cat is alive[0]). aka. shrodinger's cat not alive means no more suppositions. np is now p, so !NP = P can happen. lisp users call that closure. The complete inverse of physics, maximum font size for given context of !
C type casting addresses the issue so much easier, either (&*(NP) = seg fault ? B) or (B = &*(NP) ? seg fault).
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…
Exactly how do you stop not losing interest because you suddenly realise you are just reinventing the wheel? On the contrary, how exactly do you generate interest in yak shaving because you know a solution is already out there and you should not waste your time?
For the specific topic of building a game engine, which I think fits the defintion of "yak shaving", it's fun because it relatively easy to do, there's a know set of things you need, each one is well known, each one can be done in steps, and each step shows progress, so it feels super productive, even if all you're doing is just reinventing the wheel. There might be 1000 steps but each one is small, well known, and doesn't require being all that novel. Conversely, game design is an open book and much much harder to feel like you made progress on each step.