I wish! Using document.write to inject script tags is the most reliable way to insert code to run before another script tag. Here's an example where we might load some scripts then run some code before finally calling some main function.

  <script>
    // Load optimized or debug code.
    if (debugMode) {
      document.write('<script src="build-debug.js"></script>');
    } else {
      document.write('<script src="build-opt.js"></script>');
    }

    // Enable some runtime debug flags.
    if (enableTracing) {
      // This runs *after* loading the script above and
      // before main() is called below.
      document.write('<script>ENABLE_TRACING = true;</script>');
    }
  </script>
  <script>
    // This runs *after* the script tags injected in the section above.
    main();
  </script>

document.write isn't self modifying code - it's self-generating code at best.

What Mel was doing is the equivalent of document.edit.

This is a great link. I read this story a while ago, but missed a lot of meaning behind it. This explanation hits the spot explaining all of that.

The Story of Mel is a story about a ‘Real Programmer’ that came out in the early 1980′s on Usenet

I read this as a story of "coming out" on Usenet... thought it was going to be about sexual/gender identity or something.

Didn't the story go that Paul Allen wrote a loader for Altair Basic this way on pen and paper on an airplane?

That is the point - the term 'Real Programmer' is meaningless and is merely used to disparage languages / tools / platforms and boost egos. You can look at Mel, a 'Real Programmer', and realize that you can't make value judgements of what true programming is. Programming is using logic to solve problems, regardless of the tools and language.

In that context, "Real Programmer" means something like "someone who understands every minute detail about every part of the systems he's programming to the point that they can keep track of every variable, every system state, and every operation to make it do whatever they want". It's not about programming style or finesse. It's about raw mastery of the system to deeper levels than those not called "real programmers" could fathom.

From the Jargon File: http://www.catb.org/jargon/html/R/Real-Programmer.html

"Real Programmer" is derived from the name of Real Programmers Don't Use Pascal [0], which describes "Real Programmers" as being those who use FORTRAN or assembly or something similarly painful to write software in versus someone who used high-level languages. Nowadays it's generally understood to mean anyone who writes code either directly on "bare metal" or very close to it despite the use of higher-level tools; nowadays, the term's used more-or-less ironically (since modern compilers have gotten much better about proper optimizations), but Mel Kaye - the "Mel" of "The Story of Mel" - was (is?) the archetypal definition of a true "Real Programmer".

The term "Real Programmer" predates "The Story of Mel" by about a year; "The Story of Mel" was written as a direct response to "Real Programmers Don't Use Pascal" (namely, its claim that "Real Programmers write in FORTRAN"). Mel makes FORTRAN programmers look like quiche-eating Pascal programmers in comparison.

[0]: https://en.wikipedia.org/wiki/Real_Programmers_Don%27t_Use_P...

3600 rpm, with 64 words per track, so reading a word took 260 µs. Minimum cycle time (the address is up next) was 9 × 260 µs = 2.34 ms. Worst case then (just missed it) was (9 + 63) × 260 = 18.75 ms.

I always understood it as intentional on Mel's part.

It seems pretty identical to me. In Blackjack, the easiest way to make someone win is to give them 21, and make sure no one else gets 21.

So if the pseudocode is something like:

    if cheat_switch:
        if active_player == "COMPUTER": #this should be "HUMAN"
            make_current_player_get_21()
        else:
            make_current_player_get_20_or_busts()

Then the computer will always get 21, and the human player will get 20. Assume for the moment that it deals with dealing multiple cards for both the human and computer; this can be done, but isn't worth getting into.

And this could all be switched in the `active_player` check.

Deliberately ignoring the instructions :)

The manual for the game says:

  If SENSE SWITCH 32 is depressed, there is a better than normal chance
  of an ace being dealt as the player's first card.

Presumably the story didn't get that quite right. Sadly the code hasn't turned up.

Along the same lines as some of the other responses, it's possible that the "test" in question was testing whether the affected player was the human or the computer; getting that particular test backwards would certainly have the described effect.

To summarize, Mel enabled the index register bit (despite not using the index register) to cause an integer overflow, and because the instruction was at the very top of memory, it had the side-effect of also incrementing the instruction’s opcode, modifying the instruction to change into a JUMP command, in order to exit an infinite loop.

Reading this made me thing of some of the crazy tricks I've pulled in TIS-100. And while it worked well in a game, it would be a nightmare for that to be my day job.

I think the assumption is that The Story of Mel has been circulated enough that finding a copy of it isn't a problem.

For everyone else, though, it's part of the Jargon File: http://www.catb.org/jargon/html/story-of-mel.html