I'll bet that sort of 10x programming has gotten rarer simply because hardware constraints have relaxed so much. Tricks that once would have made a program possible now just make it a headache to read.

An awful lot of game-development history was spent actively looking for 'clever' hacks that would verge on fireable offenses today. Pokemon Red was made barely-possible via the sorts of magic-number tricks most of us don't even like to think about, but at this point that sort hand-optimization is basically just code golf for its own sake.

It moves generationally, as new platforms are invented and people seek to capitalize on the platform before the performance is really all there. When you're doing anything at the bleeding edge, you really need to know the details of the platform and squeeze every ounce of performance out of it, because there's probably not enough performance to go around. When the edge moves to the center, stops bleeding, and the platform gets optimized, those sorts of hacks become silly anachronisms.

I remember doing Javascript games in 2007 (before V8 introduced a JIT to JS) and very carefully optimizing loops, avoiding DOM calls, eschewing JQuery, etc. to get acceptable performance. As late as 2009 we were counting bytes on the Google search results page (like literally; we'd do things like "for(var i=0,e; e=c[i++];)" to save a byte in a foreach loop). Solidity programmers on the Ethereum VM today use tricks like switching out opcodes and moving functionality into library contracts, sometimes at the expense of locking tens of millions of dollars worth of ETH forever.

Nobody counts bytes or manually moves common subexpressions out of loops in JS today; you just use Babel. But as computing matures, the bottleneck moves, and people seek out new domains that are just becoming possible, and then have to develop a new bag of tricks.

Agree, I will also add that technical debt != complexity.

As an example everybody uses an OS to code. An OS is incredibly complex. Maybe one of the most complex piece of software. But it doesn't mean that you should care about it. With the proper and clean interface it will have an abstraction of this complexity to its user (in your company or not) and they will be able to continue to code and never have to care about it.

So of course an OS - or like OP said anything creating value - doesn't mean that it creates technical debt only because it's complex.

Exactly: you may not be able to fully understand the OS you're working with, but you can abstract it away and use it anyway. This isn't "technical debt", it's something you need to actually get your job done: without the OS, you simply would not be able to actually create the thing you're making.

Similarly, whatever you're building likely uses a microprocessor somewhere. You probably don't really understand how that works, and would not be able to build one from scratch. But without that CPU, you wouldn't be doing your job at all.

The phrase "standing on the shoulders of giants" comes to mind here.

"The Thirty Million Line Problem" by Casey Muratori might change your mind.

Thank you! Most people I've worked with end up so afraid of complexity that they create tech debt through crazy simplifications that require constant work arounds.

It's not even that complex. Arguably it is simpler than the way that you would otherwise do inverse square root, you could write a 5-line comment that anyone who's understood high school calculus could decipher, it's drop-in/drop-out, and doesn't need to be maintained.

Highlight this and pin it to the top of this comment thread.