I think the difference here is that Carmack was working in a space where fast inverse square root was the difference between the program working and it not working. At that point, it doesn't really how matter "clever" in any bad sense of the term the code is.

Carmack works in 3D engines, which even today is a space where people are trying to wring every last cycle out of them. It's perfectly appropriate when programming in a space where every last cycle counts to program as if you're in a space where every last cycle counts.

I don't work in such a space, so I don't program that way. But while I haven't got anything as "clever" as FISR, I have got some things like non-obvious database schemas for certain performance reasons that if my successors don't find and read the comments I've left about why the schemas are that way, they could well get themselves into some trouble if they try to "fix" it.

Pentium 3 released in January 1999. That CPU, along with all newer ones, support SSE which has RSQRTPS instruction, faster, also much more precise approximation.

AMD had it before, PFRSQIT1 / PFRCPIT2 in 3DNow from 1998.

Quake 3 Arena released in December 1999. The point of using that approximation is running on older hardware, like Pentium and Pentium 2.

FISR is a beautiful hack, but it hardly technical debt. This is the original code. Note how the trick has been hidden behind a normal API such as `Q_rsqrt`:

   float Q_rsqrt( float number ) {
        long i;
        float x2, y;
        const float threehalfs = 1.5F;

        x2 = number * 0.5F;
        y  = number;
        i  = * ( long * ) &y;                       // evil floating point bit level hacking
        i  = 0x5f3759df - ( i >> 1 );               // what the fuck? 
        y  = * ( float * ) &i;
        y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration


        return y;
  }

If the comment "what the fuck" were instead "estimate floating-point exponent with bit-wise arithmetic" and "SingleStep forward with Newton's Method", then the code would be better documented

The comment "what the fuck" and "evil floating point bit level hacking" don't help anybody. And "1st iteration" is only helpful if you knew it was an iteration of Newton's method.

What I would call technical debt is if he had inlined those tricks all over his code, making it very hard to debug a wrong result or move away from this technique.

Carmack didn't come up with that: https://en.wikipedia.org/wiki/Fast_inverse_square_root#Histo...

I think Elon Musk is another good example of this phenomenon.

Certainly, there are programmers vastly more productive than the average, but I think when you think of any legendary programmer (Linus, Carmack, Knuth), you're also likely impressed by their significant supporting cast.

Its been over 40 years and he's still writing "Art of Computer Programming" books, and fixing errors in the text. Its an exceptionally well-crafted piece of writing. His solutions to various programming problems are excellent too, great analysis and deep thought applied to them.

Definitely not the "10x programmer" of today's lore. Knuth is an older, gentler kind of genius that I have a huge amount of respect for.

---------

For those who haven't read Knuth's works yet, I suggest starting with Knuth's analysis into Alpha Beta pruning: https://pdfs.semanticscholar.org/dce2/6118156e5bc287bca2465a...

Knuth's writing style is just so much deeper and thorough than pretty much everything else. You have to give the guy mad respect.

Of course, I also recommend reading "The Art of Computer Programming", but that's far more material to read through. The ~34 pages on Alpha-Beta pruning are a quicker introduction to Knuth's writing style. Even if you think you know how Alpha-Beta pruning works, Knuth goes far deeper into the subject than you might imagine.

EDIT: In particular, the F -> F1 -> F2 algorithm (F being Minimax, F2 being Alpha-Beta, and F1 being an in-between algorithm to help describe F2) is brilliant writing. Only Knuth would spend so much effort describing F1. But all that effort into F1 helps both his analysis, as well as better describes what is going on in Alpha-Beta pruning (aka F2).

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.

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.

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.

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.

If you want people to accept and learn from your clever programming techniques, try to find ways to turn them into products that only you can make that lots of people will pay money for. Even if you don't succeed in convincing the rest of the industry, at least you'll have lots of money.

Doom would have been revolutionary even if it and all of the other games it inspired were free.

Similar to idea that it's hard to write simple, clear code, but easy to understand it.

Carmack didnt write it, 0x5f3759df constant landed at iD from 3Dfx/Silicon Graphics

https://medium.com/hard-mode/the-legendary-fast-inverse-squa...