Mel placed each instruction to meet the drum's read head — and beat the assembler

In Ed Nather's 1983 USENET essay 'The Story of Mel, a Real Programmer', Mel is the programmer at Royal McBee Computer Corp., maker of the LGP-30 and the newer RPC-4000 — cheap drum-memory machines. Mel, who disapproved of compilers ('If a program can't rewrite its own code, what good is it?'), had written the company's most popular program in raw hexadecimal: a blackjack game that packed the LGP-30 booth at every computer show while IBM salesmen stood around talking to each other.

Mel's craft was timing. On a drum machine, code runs fast only if each instruction arrives at the read head just as the previous one finishes. An optimizing assembler existed for this, but Mel refused it because its placements were unpredictable and would force separate constants. Knowing the numeric value of every operation code and assigning his own drum addresses, he could treat any instruction as a numerical constant — pick up an earlier add instruction and multiply by it.

He wrote innermost loop bodies first so they claimed the optimum drum locations, and put deliberate delays just past the read head so they took a full revolution — the 'most pessimum'. Nather compared Mel's hand-optimized programs with the same code run through the optimizing assembler: 'Mel's always ran faster.' The essay closes with a Change Request in which sales wanted a sense switch to let customers win at blackjack.

Mel balked at the dishonesty, then complied — but wrote the test backwards, so the switch made the machine cheat and win every time. He declared his subconscious uncontrollably ethical and refused to fix it, and Nather's essay turned the episode into one of computing's most-reprinted pieces of folklore.

Write the innermost loops first and place each instruction to meet the read head exactly on time — using opcodes' numeric values as constants for self-modifying code.

Drum latency made instruction placement the difference between fast and glacial code.

The optimizing assembler optimized placement but destroyed the programmer's control over it.

Writing innermost loops first let the hottest code claim the best addresses before anything else.

Self-modifying code through opcode-as-constant arithmetic removed separate constants entirely.

Real optimization exploits the machine's physics, not the toolchain: the person who knows every opcode's numeric value can turn constants into code and timing into a design material.

The essay became one of the most-reprinted pieces of computing folklore, and 'not quite optimum' entered programmer vocabulary through Mel's 'most pessimum' coinage; the RPC-4000 and Royal McBee itself are long gone, remembered mostly through this story.