4 ms·

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 consid

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...

arakyd 17y ago
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 http://www.ultratechnology.com/forth2.htm (search for "documentation") [2] http://www.gamasutra.com/view/feature/2985/postmortem_naughty_dogs_jak_and_.php?page=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_naughty_dogs_jak_and_.php?page=3 http://www.gamasutra.com/view/feature/2985/postmortem_naught... (right at the top)
Cecil 17y ago
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.
- shaunxcode 17y ago
  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.
gamache 17y ago
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 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 http://en.wikipedia.org/wiki/Real_Men_Dont_Eat_Quiche).
- blhack 17y ago
  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.
- andreyf 17y ago
  Wikipedia link missing an apostrophe: http://en.wikipedia.org/wiki/Real_Men_Don%27t_Eat_Quiche http://en.wikipedia.org/wiki/Real_Men_Don%27t_Eat_Quiche
Tichy 17y ago
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.
- ubernostrum 17y ago
  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?"
  - michael_dorfman 17y ago
    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.
  - aardvark 17y ago
    Mel likely wrote the blackjack program before Kernighan ever offered that advice.
jrockway 17y ago
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.

arakyd 17y ago

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 http://www.ultratechnology.com/forth2.htm (search for "documentation") [2] http://www.gamasutra.com/view/feature/2985/postmortem_naughty_dogs_jak_and_.php?page=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_naughty_dogs_jak_and_.php?page=3 http://www.gamasutra.com/view/feature/2985/postmortem_naught... (right at the top)

Cecil 17y ago

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.

shaunxcode 17y ago
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.

gamache 17y ago

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 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 http://en.wikipedia.org/wiki/Real_Men_Dont_Eat_Quiche).

blhack 17y ago
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.
andreyf 17y ago
Wikipedia link missing an apostrophe: http://en.wikipedia.org/wiki/Real_Men_Don%27t_Eat_Quiche http://en.wikipedia.org/wiki/Real_Men_Don%27t_Eat_Quiche

Tichy 17y ago

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.

ubernostrum 17y ago
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?"
- michael_dorfman 17y ago
  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.
- aardvark 17y ago
  Mel likely wrote the blackjack program before Kernighan ever offered that advice.

jrockway 17y ago

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.