He spends 16 hour days fighting with browser incompatibilities, catching up with an ADHD-afflicted industry, answers massive amounts of emails, and does more SEO than coding.
This is all done at the threat of being replaced by a PHB's 16 year old "whiz-kid" nephew who "knows a lot about computers" and is "always playing with those things".
I do enjoy this story, even if it is oft repeated.
I worked with a fellow once who very much reminded me of mel. He once built a telephone controller with an intel 4004 because the office he was working in needed the features it provided.
There probably nothing this fellow couldn't program.
I've seen this story before, and I just don't get it. Mel doesn't sound to me like a "Real Programmer." He sounds like the kind of person I wouldn't even consider hiring or collaborating with. I would have spent most of the debugging process muttering curses at Mel for writing undocumented, unreliable, invalid, highly fragile code.
Here's my version of a "Real Programmer": When Melanie left the company, I dug into her code to try to add the cheat feature. Turns out she had split everything up by functionality so that all the parts of the complex application were carefully encapsulated, and I only had to modify a couple methods. They were carefully commented, so I was able to grok the code just by skimming it. Once I made the changes, I added a couple more unit tests to the thorough test suite Melanie had left behind, and confident that the program still worked, I went home early.
What you've said is the equivalent of saying Odysseus would have been so much better if only he'd brought a cell phone with him, so he could call his wife and let her know when he'd be back.
this is the first "humorous" comment that I have ever upvoted - purely because it is so true that the humor is implicit and not the main function of what was said. My god I have this vision now of mel wearing robes and fighting creatures with machine code.
HA, "methods". This was the late 50's, kiddo. OO was fifteen years off... hell, high level languages were not even there yet. You were lucky if your computer had a keyboard. Your precious "unit tests" would have also been written in hex, and "Melanie's" carefully factored code would spend most of its time thrashing the stack, if the LGP-30 had one. And it didn't.
I think you missed the part where it was 1983 (edit: actually even earlier, only the article is from 83).
I remember from "No Silver Bullet" (or was it "Mythical Man Month") how at one time it was a revolutionary idea to store documentation/comments along with the source code. It sounds crazy to ever have done it differently, but in earlier times, disk space was probably too scarce to do that. Likewise I suppose Mel's style was appropriate for the machines of his time.
I think both you and Mel missed Brian Kernighan's old adage:
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
But that only holds if Mel was working at the limit of his cleverness. I'm willing to assume, based on the evidence, that he still had some excess cleverness capacity reserved for debugging.
Indeed, back then, memory addresses were more expensive than programmers. "Wasting" a week writing "unmaintainable" code to save a few bytes was apparently cost-effective.
Now, programmers are the expensive part. It follows that our code is now optimized for programmers rather than the hardware it will run on.
Yes, times have changed, but that's mostly because 99% of businesses prefer to make tradeoffs that allow them to develop applications more quickly and cheaply, not because Real Programmers suck. Let's look at the criticisms.
Undocumented: This one sticks, although perhaps Mel just never got around to writing documentation for the same reason he never got around to fixing the cheat bug. In any case, Real Programmers may not write many comments, but they do write external documentation, and often far more documentation than code.[1]
Unreliable, highly fragile: The story doesn't imply that the program was unreliable, and in fact the ending implies that the program was still working for some time after it was written, even though no one could really maintain it. Writing code that is tightly coupled to certain hardware features is not a good idea for most programmers these days who build on software APIs, usually at the top of a huge stack, and who want to be portable, but Mel didn't live in that kind of environment and wasn't aiming for portability. Even today, there are still places where code is written for known hardware and not on top of a stack of software that is going to be updated and patched and changed continually until the day it is no longer maintained (at which point, of course, it rots furiously).
Given the assumptions Mel was working under, he might very well have written code that lasted much longer, with zero maintenance, than most maintained code lasts. There are many advantages to portability and huge software stacks, but most programmers are so used to them that they have only the vaguest notions of the tradeoffs involved (it's not just performance).
Invalid: Ah yes, the hotshot programmer who thinks he knows better than the business people and refuses to implement perfectly good features because they go against his "principles", or "aesthetic sensibilities" wrt the code, or some such nonsense that has nothing to do with making the largest possible amount of money by doing something that Other People Want. Well, guilty as charged, but I am going to defend Mel on general principle here.
This part of the story resonates with some programmers because 1) like anyone else, programmers prefer to work on things that make the world a better place, or at least make themselves some money, as opposed to making scumbag upper management types 0.n% richer, especially if it is at society's expense, and 2) they hate the fact that they are seen as replaceable cogs in an IT machine that provides a messy but necessary service that any bunch of monkeys could do, and 3) if they are doing what any monkey could do, they are working on getting a job, or starting a company, where the technical envelope is being pushed to the point where it actually does matter how things are implemented, and where the problems are interesting enough that you can't grok the code just by skimming it, no matter how well it's written, because understanding it properly requires specialized knowledge that is not shared by every single programmer who's ever half-assed their way to a sheepskin, knows how to use Google, and hasn't burned out yet.
Encapsulation: Who says Mel didn't write well factored code? You can split things up by functionality in any language. Besides, Real Programmers write their own languages,[2] and the languages they write are designed from the ground up to provide more fine grained separation of functionality than you'll get in any managed bondage language that Melanie and all the rest of the programmers you can hire have been spending their careers becoming experts in.
Unit tests: Not going to say anything bad about unit tests, but they aren't a panacea or a guarantee that a program does everything it's supposed to do.
So, yeah. Times have changed. The standard stack is good enough for 99% of what you want to do now, as are the programmers that you can hire, and the costs of living outside of that ecosystem are high.[3] Still, there's something to be said for the other 1%, and I'll bet you there are still Mels out there kicking ass (not posting on HN), and I, for one, salute them.
Mel was a requirements driven programmer that had the luxury of only having to write code for one platform at a time. None of his code as described sounds possible to abstract and maintain across platforms. I'm going to guess he evolved towards hardware engineering rather than software engineering.
The story of Mel 2.0:
He spends 16 hour days fighting with browser incompatibilities, catching up with an ADHD-afflicted industry, answers massive amounts of emails, and does more SEO than coding.
This is all done at the threat of being replaced by a PHB's 16 year old "whiz-kid" nephew who "knows a lot about computers" and is "always playing with those things".
I'm not the Mel in the story, but yea you've got me pegged.
Oh my god, that was my job before I realized that big companies like Yahoo actually pay good money for people who know javascript and CSS.
Being "The Web Guy" sucks a lot.
I do enjoy this story, even if it is oft repeated.
I worked with a fellow once who very much reminded me of mel. He once built a telephone controller with an intel 4004 because the office he was working in needed the features it provided.
There probably nothing this fellow couldn't program.
Since is this repost made #1 on the front page, two other links are worth noting.
The newline-mangled, and more fun free-verse version: http://catb.org/jargon/html/story-of-mel.html
The Wikipedia article about Mel: http://en.wikipedia.org/wiki/Mel_Kaye
The free-verse version really is better.
I've seen this story before, and I just don't get it. Mel doesn't sound to me like a "Real Programmer." He sounds like the kind of person I wouldn't even consider hiring or collaborating with. I would have spent most of the debugging process muttering curses at Mel for writing undocumented, unreliable, invalid, highly fragile code.
Here's my version of a "Real Programmer": When Melanie left the company, I dug into her code to try to add the cheat feature. Turns out she had split everything up by functionality so that all the parts of the complex application were carefully encapsulated, and I only had to modify a couple methods. They were carefully commented, so I was able to grok the code just by skimming it. Once I made the changes, I added a couple more unit tests to the thorough test suite Melanie had left behind, and confident that the program still worked, I went home early.
I think times have changed...
I got tears in my eyes reading your comment.
What you've said is the equivalent of saying Odysseus would have been so much better if only he'd brought a cell phone with him, so he could call his wife and let her know when he'd be back.
this is the first "humorous" comment that I have ever upvoted - purely because it is so true that the humor is implicit and not the main function of what was said. My god I have this vision now of mel wearing robes and fighting creatures with machine code.
HA, "methods". This was the late 50's, kiddo. OO was fifteen years off... hell, high level languages were not even there yet. You were lucky if your computer had a keyboard. Your precious "unit tests" would have also been written in hex, and "Melanie's" carefully factored code would spend most of its time thrashing the stack, if the LGP-30 had one. And it didn't.
Anyway, to understand the context of this article, you need to read the "parent post" called "Real Programmers Don't Use Pascal": http://www.pbm.com//~lindahl/real.programmers.html
And to understand that, check on the grandparent, not a post but a book: Real Men Don't Eat Quiche (http://en.wikipedia.org/wiki/Real_Men_Dont_Eat_Quiche).
Reading this honestly just made a huge smile come across my face, and a bit of a tear start coming into my eye.
There might be hope.
Wikipedia link missing an apostrophe: http://en.wikipedia.org/wiki/Real_Men_Don%27t_Eat_Quiche
I think you missed the part where it was 1983 (edit: actually even earlier, only the article is from 83).
I remember from "No Silver Bullet" (or was it "Mythical Man Month") how at one time it was a revolutionary idea to store documentation/comments along with the source code. It sounds crazy to ever have done it differently, but in earlier times, disk space was probably too scarce to do that. Likewise I suppose Mel's style was appropriate for the machines of his time.
I think both you and Mel missed Brian Kernighan's old adage:
"Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
But that only holds if Mel was working at the limit of his cleverness. I'm willing to assume, based on the evidence, that he still had some excess cleverness capacity reserved for debugging.
Mel likely wrote the blackjack program before Kernighan ever offered that advice.
I think times have changed...
Indeed, back then, memory addresses were more expensive than programmers. "Wasting" a week writing "unmaintainable" code to save a few bytes was apparently cost-effective.
Now, programmers are the expensive part. It follows that our code is now optimized for programmers rather than the hardware it will run on.
Yes, times have changed, but that's mostly because 99% of businesses prefer to make tradeoffs that allow them to develop applications more quickly and cheaply, not because Real Programmers suck. Let's look at the criticisms.
Undocumented: This one sticks, although perhaps Mel just never got around to writing documentation for the same reason he never got around to fixing the cheat bug. In any case, Real Programmers may not write many comments, but they do write external documentation, and often far more documentation than code.[1]
Unreliable, highly fragile: The story doesn't imply that the program was unreliable, and in fact the ending implies that the program was still working for some time after it was written, even though no one could really maintain it. Writing code that is tightly coupled to certain hardware features is not a good idea for most programmers these days who build on software APIs, usually at the top of a huge stack, and who want to be portable, but Mel didn't live in that kind of environment and wasn't aiming for portability. Even today, there are still places where code is written for known hardware and not on top of a stack of software that is going to be updated and patched and changed continually until the day it is no longer maintained (at which point, of course, it rots furiously).
Given the assumptions Mel was working under, he might very well have written code that lasted much longer, with zero maintenance, than most maintained code lasts. There are many advantages to portability and huge software stacks, but most programmers are so used to them that they have only the vaguest notions of the tradeoffs involved (it's not just performance).
Invalid: Ah yes, the hotshot programmer who thinks he knows better than the business people and refuses to implement perfectly good features because they go against his "principles", or "aesthetic sensibilities" wrt the code, or some such nonsense that has nothing to do with making the largest possible amount of money by doing something that Other People Want. Well, guilty as charged, but I am going to defend Mel on general principle here.
This part of the story resonates with some programmers because 1) like anyone else, programmers prefer to work on things that make the world a better place, or at least make themselves some money, as opposed to making scumbag upper management types 0.n% richer, especially if it is at society's expense, and 2) they hate the fact that they are seen as replaceable cogs in an IT machine that provides a messy but necessary service that any bunch of monkeys could do, and 3) if they are doing what any monkey could do, they are working on getting a job, or starting a company, where the technical envelope is being pushed to the point where it actually does matter how things are implemented, and where the problems are interesting enough that you can't grok the code just by skimming it, no matter how well it's written, because understanding it properly requires specialized knowledge that is not shared by every single programmer who's ever half-assed their way to a sheepskin, knows how to use Google, and hasn't burned out yet.
Encapsulation: Who says Mel didn't write well factored code? You can split things up by functionality in any language. Besides, Real Programmers write their own languages,[2] and the languages they write are designed from the ground up to provide more fine grained separation of functionality than you'll get in any managed bondage language that Melanie and all the rest of the programmers you can hire have been spending their careers becoming experts in.
Unit tests: Not going to say anything bad about unit tests, but they aren't a panacea or a guarantee that a program does everything it's supposed to do.
So, yeah. Times have changed. The standard stack is good enough for 99% of what you want to do now, as are the programmers that you can hire, and the costs of living outside of that ecosystem are high.[3] Still, there's something to be said for the other 1%, and I'll bet you there are still Mels out there kicking ass (not posting on HN), and I, for one, salute them.
[1] http://www.ultratechnology.com/forth2.htm (search for "documentation")
[2] http://www.gamasutra.com/view/feature/2985/postmortem_naught... (scroll down to the GOAL discussion)
[3] http://www.gamasutra.com/view/feature/2985/postmortem_naught... (right at the top)
I hope I never have to work with that guy. He sounds ghastly.
Mel was a requirements driven programmer that had the luxury of only having to write code for one platform at a time. None of his code as described sounds possible to abstract and maintain across platforms. I'm going to guess he evolved towards hardware engineering rather than software engineering.
Hey Mel, are you out there somewhere ? Are you here ?!