I hope I never have to work with someone like him. He sounds awful.
In a way I agree - someone programming like this right now without very good cause would be a bit of a nightmare if you ever had to tangle with their code. But it really was another world back then.
They were so resource constrained [1]. That "drum" wasn't the hard disk, it was the memory! Think about waiting for the rotation of a drum for each instruction read. Then the actual capacity of it was only 4K. The laptop I am typing this on has about 32 million times more memory and I don't like to think how much faster it is.
You either used clever tricks, or you wrote very limited programs. There was no room for any overhead. The author of that story wasn't astonished by clever tricks, just the degree of cleverness.
If your programs couldn't run on the machine you had, they were no good. Nobody was going to spend a quarter million dollars on equipment for the sake of source code beautification.
The CPU booted from an EEPROM and started running code. There was an FPGA on the board that controlled the memory. The FPGA needed to be loaded with a bit-stream that was also on the EEPROM. The trick was that I had to write a program to load the FPGA without referencing any memory -- I only had ROM and the CPU registers. Fortunately the MIPS had quite a few registers, but I had to abuse all the register-use conventions and the code jumped through some hoops in order to be able to get the FPGA loaded so we could start running from RAM.
There was all kinds of crazy stuff that was weird with that hardware that we had to fix in software... I didn't realize until switching jobs exactly how weird things were, I just thought it was normal.
https://news.ycombinator.com/item?id=679208
Back then, I was so new it bumped me down into negative score. I almost made a new account but decided to keep it and try and rebuild my damaged rep.
Nowadays, my score in the thousands, but Mel still sounds awful.
The rest of the stuff is entirely valid though. A programmer that cannot be managed is worthless, and someone who is unwilling to accept correction is a liability. I wouldn't refuse to work with him because unless I'm his superior I don't get to make that call, but I would probably go out of my way to avoid interaction. (And if I were his superior, unless he's got political juice or something, I'd have him shown to the door if he won't work with the team instead of against it.)
In the story,
The storyteller is tasked with maintaining Mel's code.
He can't do it. Mel hadn't left any documentation.
All sort of tricks.
No explanation of what's going on.That rubbed me the wrong way too. Even the hackers at MIT documented their hacks, they even wrote up a memo explaining a bunch of them so others could understand and build on them - see HAKMEM.
Documentation was much more extensive and available back then. Systems frequently came with full schematics, and you could call the design team on the phone if you wanted. DEC would get phone calls about the PDP-10's RIM10B bootloader right up until the retirement of the 36-bit processor line, and they did their best to explain its tricks.
The loader was made to fit entirely in the processor registers so it didn't touch the memory it was loading. To do this it made use of a specific and documented aspect of the processor - that being that the first thing it did when executing an instruction is to determine its effective address, and nothing the instruction can do will have any effect on its own effective address calculation.
They had two bold-print warnings about this in the processor manual, both before and after the RIM10B source code, but some people still required more explanation. For those people, the explanation was given.
In Mel's story, he grinds out a very well optimized program, and while I can appreciate the skill it takes to do that, he documented none of it. This was customer-facing code. That's unacceptable even by their standards, and even his own co-workers of the era would have thought he was an asshole. A skilled asshole, with skill worthy of respect, but an asshole nonetheless.
But your comment is just so dismissive of the point of the story, Mel’s cleverness. It comes across like you saying “This person sounds awful because they’re smarter than me.” I can assume that’s not what you’re trying to say, but that’s what it sounds like.
If you wrote a more nuanced comment acknowledging that, e.g. ‘while I would love the opportunity to learn from someone like that, I’m glad I don’t have to work with them or maintain their code.’ I would be more inclined to see your comment as contributing to the discussion.
I didn't read the comment that way, but then I share the opinion that Mel seems like a difficult person to work with or to manage. Wrote obscure code and apparently failed to document any of it. Took glee when said code worked the opposite of requested. The guy who took over seems to have had to waste countless hours trying to de-obfuscate the code in order to reverse the logic of the test.
I appreciate the cleverness, but there are some red flags here. Also, I got the impression that some of the cleverness was for its own sake, rather than out of necessity.
OP made a response indicating that his objection to Mel was that he left zero documentation.
To this, I agree 100% !!
Leaving no documentation is doing your future self a huge disservice (even a few weeks from now it'll be helpful if you've left yourself some good breadcrumbs to follow), and is pretty much a hostile act towards the team.
----- initial comment -----
Sure, if he's doing that kind of highly idiosyncratic stuff in the modern software & hardware environment, he'd be a hindrance to any team.
But this was not that situation, and sadly, this comment reveals a deep cluelessness about the technology underlying the computing industry.
The article shows a real genius at work, fully understanding that what he is doing is programming a computing machine, and using every available advantage to get to to yield a program that performs well.
Sadly, software now is optimized entirely for the convenience of the developer, and with literally billions to trillions of multiples of the computing power available to Mel, most software today is utter crap, taking tens of seconds to even load because it barely floats in an ocean of bloated abstraction and 'frameworks'.
The fact that you cannot at even recognize the obvious genius in that story indicates that you should really learn a lot more and seriously rethink your approach to computing. Learn how the hardware and software actually work. Work hard to strip out unnecessary dependencies, middleware, frameworks, etc., and make your applications snappy. With today's hardware, there is literally no excuse for software that does not respond faster than any human perception. But sadly, today, if you can make it work that way, you'll be the exception — so be that exception.
Indeed not at all what it first seemed.
edited (original had sat in writing for a while then submitted later w/o reacing new context comments)