6 ms·

A Tale of Two Programmers

125 points by frisco 17y ago

swombat 17y ago
I'm not sure what value this story adds. We're all (well, mostly) aware of the concept of hacker vs enterprise programmer, and this story doesn't add anything new to that idea. On the other hand, it does seem to be a nice passive-aggressive way to complain about getting demoralised by a manager who couldn't understand the hacker mindset.
- andrewtj 17y ago
  It doesn't offer anything new but it does offer an opportunity to reflect. This story has been around a long while (this dates from '99 but I suspect it's older) and I think comes from a time when hackers had a whole lot less options. Seems to me it's a pretty good time to be a hacker right now. EDIT: Couldn't beat curiosity, it's from March 20, 1985 according to http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audienc...
smanek 17y ago
I know it's old, but this is one of my favorite programming stories ... (Along with Mel, and a few other goodies)
- mattyb 17y ago
  For those that haven't read The Story of Mel: http://www.pbm.com/~lindahl/mel.html http://www.pbm.com/~lindahl/mel.html
  - ojbyrne 17y ago
    It was a better story than the OP.
noss 17y ago
I really dislike these kind of stories. A programmer that is not understood by management. First, they are anecdotal. Second, why are the programmers not taking control of management positions if they know so much better? I sure would like to get to play computer games at work, design software from scratch, always end up with clear and short code, make software with usability that users love, and be showered with money. But realistically, I think Alan created the best product for the company. He analysed what was needed, to avoid the risk of creating the wrong software. He got several programmers into the project so the bus-number was higher. He set up facilities for reporting bugs. He started testing early. Now imagine how good Charles would be if he could learn to cooperate and participate in a group like Alan's. Once the software has been written he could leave the maintenance to the others and move on to something more interesting than maintaining accounting software.
- cracki 17y ago
  you're joking, right? Charles did analysis too, but up-front, and apparently better than Alan.
- sofal 17y ago
  First, they are anecdotal. There is no inherent evil in anecdotes. This is obviously fiction and was not intended to be used as evidence. If it were, then you would have a reasonable complaint. The purpose of a little story like this is (from Wikipedia): "to reveal a truth more general than the brief tale itself, or to delineate a character trait or the workings of an institution in such a light that it strikes in a flash of insight to their very essence." Second, why are the programmers not taking control of management positions if they know so much better? I see this asked a lot and I don't understand why. First of all, the traits (not skills, but traits) or interests needed for taking control of management positions are different (vastly different depending on the company) than the traits/interests needed to be a good developer. Second, don't forget that our fictional hero Charles eventually quit the company and presumably found a better place. Finding a place that fits you more is sometimes better than trying to change yourself to fit the management mold in a particular company. I think Alan created the best product for the company. Did you read the same story I did, or are you rewriting it into your own parable? Now imagine how good Charles would be if he could learn to cooperate and participate in a group like Alan's. That would be good I think. Let's also imagine how good Alan could be if he could learn to see past the inflated corporate policies, procedures, and checklists and focus on the crux of the problem.
visitor4rmindia 17y ago
This just sounds like a wishful fairy-tale. Why is it the top item on hacker news?
- lallysingh 17y ago
  It's sunday, there's nothing else.
- sneakums 17y ago
  Because a lot of people clicked the up arrow.
Confusion 17y ago
Everyone can come up with parables that make some point of view look good. However, two diametrically opposite extremes are presented, instead of a more realistic situation, making the value of the parable zero and none. For instance, were the 'enterprise' team to be headed by a capable technical lead that forces his team to produce reasonably readable, reasonably documented, reasonably maintainable and futureproof code, then the situation would already be very different. If we add to that that the inexperienced hacker prodigy would produce working code much faster, but his code would turn out to be brittle when someone else has to take care of it, because he does not yet have experience in interacting with lesser gods via his code, then the match would be even more equal. We may still prefer the hacker, but we would be forced to think about the trade offs involved.
- sofal 17y ago
  I think that enterprise teams typically follow strict syntactic coding standards and then check off the "maintainable" and "readable" requirement from that alone. Additionally, they generate mountains of bloated Word and PowerPoint documents and then consider that responsibility fulfilled. They end up with an incredibly expensive, over-engineered mega-application that exacerbates rather than solves the intended problem. Don't think that this doesn't happen. There are only so many things that you can force upon a team of programmers, and overall quality and cohesiveness aren't among them.
  - ankhmoop 17y ago
    It's fairly easy to degenerate "enterprise developers" when you're defining what "enterprise" means.
    - sofal 17y ago
      My definition of "enterprise developer" comes directly from working in a gigantic financial company as well as an even more gigantic government defense contractor. Would you like some more anecdotes?
      - 17y ago
colomon 17y ago
The thing that really rings true in this story for me is the difficulty that management sometimes has understanding how hard the things we do are. It particularly shows up in cases that might sound like this one, where the solution is simple but hard to see. For instance, I recently corrected a bug in my code that had been there for a long time. The final code is dead simple. But it took years to detect the bug, and weeks of hard work and analysis to figure out that simple solution. (And of course, who knows -- maybe it's not as hard as I thought, and if I were just brilliant enough I would have instantly seen the solution. If I have no clue what the truth of the matter is, how is my (hypothetical) one step removed boss supposed to make sense of it?)
stonemetal 17y ago
I don't get it what is the take away of this story? If I play video games at work I am likely to get fired? If I follow company procedures I will get ahead? Seriously though work isn't track and field you don't win by being better than who ever came in second. You win by working to the best of your ability.
- berniemac 17y ago
  You clearly haven't worked at a large corporation. You get ahead by kissing up to the boss, holding large meetings, and creating fancy charts and graphs that explain why your project is 6 months behind.
  - gruseom 17y ago
    And getting promoted or transferred before the project is killed.
    - gvb 17y ago
      See also "Seven Stages of a Project" http://corry.ws/CorryBook-69.htm http://corry.ws/CorryBook-69.htm
- cabalamat 17y ago
  The point of the story is that it's not how well you do your job that counts, it's how well your manager thinks you do it. It's all about perceptions. If you're a crap coder, but suck up to your boss, wear a smart suit (or whatever the conventional clothing is at your place of work), always arrive at work on time, etc, then you'll do better than if you're a brilliant coder, but wear unconventional clothes, come in on work late, etc.
  - thetrumanshow 17y ago
    Your comment deserves to be a direct reply to the orignal posting. The current comments are tipping the scales in favor of Alan either by directly supporting overweight processes/solutions, or by demeaning the total comparative contribution of Charles (which has the same effect). For people who just cannot make the jump and understand what the author was saying, re-read the article, and instead of Charles playing Space Invaders, have him reading Hacker News instead. I think you'll see it takes on a whole new meaning for you.
mixmax 17y ago
Well, with a contrived made-up example you can prove just about anything.
- sofal 17y ago
  It's not intended to "prove" anything. It's an anecdote, used in the simple, appropriate way that anecdotes are always used. http://en.wikipedia.org/wiki/Anecdote http://en.wikipedia.org/wiki/Anecdote
  - mixmax 17y ago
    You're right, the problem with anecdotes is that they are told as innocent stories, but often serve a higher purpose, intentional or not. This one is no diffferent in that regard. An anecdote is usually written to convey a truth, a mindset or a "right way" to the reader. This is how religion gets many of its points across to the reader. It's also how a lot of racism works (I know this black guy/eskimo/Indian that never works, they're all like that) And the reader, unless he has an analytical mind which many don't, will perceive that truth or right to be exactly that. No proof required.
    - sofal 17y ago
      I agree somewhat. An anecdote is a tool, and has been shown to have a more powerful effect on the minds of a population than solid evidence. However, I think that anecdotes offer much more than just a way to avoid having to prove your point. They're not merely for gaining power over weak minds. They can be useful among intelligent, analytical folks as well. They can serve as a supplement to real data. They can illustrate a point of view more accurately. They can communicate a feeling or a sentiment, and can pack more meaning and generate more tangents of discussion than dry statements of fact. A startup begins with something like an anecdote, an idea that may be crazy, but stems indirectly from a myriad of past experiences. Our brains are not binary storage units, and therefore anecdotes and parables have historically been used to help people remember things. Similarly, you cannot bring to the table a hard set of data for every life lesson that you've learned, and therefore you have many beneficial things to teach others that you cannot directly prove. If you're a good teacher, you'll tell an anecdote to help people remember (nonfictional preferred of course).
sengan 17y ago
Finding the simplest solution to a problem is hard, but because it seems simple in hindsight, only those competent in the art can recognize a brilliant solution. This is just another example of "bullshit baffles brains" and that it takes competence to recognize competence.
- motoko 17y ago
  Like how it took your competence to recognize the competence of the example?
edw519 17y ago
This story is troubling for several reasons. - "Lines of code" is a meaningless metric. Please stop using it. - Charles obviously did something when he appeared to be doing nothing. What? Unfortunately, we're never told. - There is no treatment of the things that likely are important: analysis, design, prototyping, feedback, fine tuning, etc. Did either programmer try any of these? - The story infers that using modern magical brilliance is better than using tried and true methods, without ever mentioning what either one is. I can imagine this story being true. Just as likely, I can imagine the opposite being true. Nothing offered, nothing learned.
- sofal 17y ago
  * "Lines of code" is a meaningless metric. Please stop using it.* I can agree that LOC is a terribly abused metric, but it is not completely without meaning. It's just really rough and better left untouched in decisions involving money. I can imagine this story being true. Just as likely, I can imagine the opposite being true. Nothing offered, nothing learned. I think it's just an invitation to reflect on the ways that this story comes true. People mistake needless, unhelpful processes for "tried and true methods" and software "architects" frequently over-engineer and create solutions worse than the problems. I'm not under any illusions that you (and most people here) don't already understand this. It probably wasn't aimed at you. There are many programmers today who don't understand that this kind of story plays itself out every day to some degree. The fact that the opposite story can also happen doesn't detract from the point that is being made.
- TheSOB88 17y ago
  I took the 'lines of code' thing as satirizing management.
- mightybyte 17y ago
  No, "Lines of code" is not a meaningless metric. I recently had to take over an existing code base for a module in our system and upgrade it to support the next version of our system's ICD. After spending some time trying to wrap my head around the existing 8800 lines of code, I concluded that it would be better to do a complete rewrite. The rewrite took a week or two and ended with 1950 lines of code that did essentially the same thing! Now, if we make the reasonable assumption that my rewrite was not a candidate for the IOCCC or Perl Golf, I think it's pretty clear that lines of code is not meaningless. A >75% code reduction while maintaining the same functionality under reasonable development conditions is almost always going to make it easier to test, debug, and maintain the system/module. (This assumption isn't unsubstantiated either. In a code review, I was even complimented on the quality of my documentation.) You hear about these kinds of vast disparities among software developers all the time, but I still find myself shaking my head that I actually saw it in real life. Now I'll freely admit that "lines of code" is mostly meaningless the way it is usually used. But don't throw the baby out with the bath water.
xenophanes 17y ago
It's like with essays: shorter essays take longer to write, because you have to spend more time editing and wording things in a clear and simple way.
caustic 17y ago
The story has sequel: The parable of the two programmers, continued http://portal.acm.org/citation.cfm?id=1012623 http://portal.acm.org/citation.cfm?id=1012623
- nsoonhui 17y ago
  This article is guarded behind a user name and password.. any free version?
ilyak 17y ago
The morals of this story: If you're that smart as Charles is, do this program in two weeks and move on. You'll get respect and raise, and get to solve more interesting problems.
thetrumanshow 17y ago
Wow! Lots of people here don't identify with Charles. Let's change the story a little and see if the response is any different... "Back at Consolidated, Charles spent some time thinking about the problem. His fellow employees noticed that Charles often sat with his feet on the desk, drinking coffee. He was occasionally seen at his computer terminal, but his office mate could tell from the lack of typing (and his always-interesting commentary at lunch) that he was likely reading Hacker News."

125 points by frisco 17y ago

I'm not sure what value this story adds. We're all (well, mostly) aware of the concept of hacker vs enterprise programmer, and this story doesn't add anything new to that idea. On the other hand, it does seem to be a nice passive-aggressive way to complain about getting demoralised by a manager who couldn't understand the hacker mindset.

andrewtj 17y ago
It doesn't offer anything new but it does offer an opportunity to reflect. This story has been around a long while (this dates from '99 but I suspect it's older) and I think comes from a time when hackers had a whole lot less options. Seems to me it's a pretty good time to be a hacker right now. EDIT: Couldn't beat curiosity, it's from March 20, 1985 according to http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audienc...

smanek 17y ago

I know it's old, but this is one of my favorite programming stories ... (Along with Mel, and a few other goodies)

mattyb 17y ago
For those that haven't read The Story of Mel: http://www.pbm.com/~lindahl/mel.html http://www.pbm.com/~lindahl/mel.html
- ojbyrne 17y ago
  It was a better story than the OP.

noss 17y ago

I really dislike these kind of stories. A programmer that is not understood by management. First, they are anecdotal. Second, why are the programmers not taking control of management positions if they know so much better? I sure would like to get to play computer games at work, design software from scratch, always end up with clear and short code, make software with usability that users love, and be showered with money. But realistically, I think Alan created the best product for the company. He analysed what was needed, to avoid the risk of creating the wrong software. He got several programmers into the project so the bus-number was higher. He set up facilities for reporting bugs. He started testing early. Now imagine how good Charles would be if he could learn to cooperate and participate in a group like Alan's. Once the software has been written he could leave the maintenance to the others and move on to something more interesting than maintaining accounting software.

cracki 17y ago
you're joking, right? Charles did analysis too, but up-front, and apparently better than Alan.
sofal 17y ago
First, they are anecdotal. There is no inherent evil in anecdotes. This is obviously fiction and was not intended to be used as evidence. If it were, then you would have a reasonable complaint. The purpose of a little story like this is (from Wikipedia): "to reveal a truth more general than the brief tale itself, or to delineate a character trait or the workings of an institution in such a light that it strikes in a flash of insight to their very essence." Second, why are the programmers not taking control of management positions if they know so much better? I see this asked a lot and I don't understand why. First of all, the traits (not skills, but traits) or interests needed for taking control of management positions are different (vastly different depending on the company) than the traits/interests needed to be a good developer. Second, don't forget that our fictional hero Charles eventually quit the company and presumably found a better place. Finding a place that fits you more is sometimes better than trying to change yourself to fit the management mold in a particular company. I think Alan created the best product for the company. Did you read the same story I did, or are you rewriting it into your own parable? Now imagine how good Charles would be if he could learn to cooperate and participate in a group like Alan's. That would be good I think. Let's also imagine how good Alan could be if he could learn to see past the inflated corporate policies, procedures, and checklists and focus on the crux of the problem.

visitor4rmindia 17y ago

This just sounds like a wishful fairy-tale. Why is it the top item on hacker news?

lallysingh 17y ago
It's sunday, there's nothing else.
sneakums 17y ago
Because a lot of people clicked the up arrow.

Confusion 17y ago

Everyone can come up with parables that make some point of view look good. However, two diametrically opposite extremes are presented, instead of a more realistic situation, making the value of the parable zero and none. For instance, were the 'enterprise' team to be headed by a capable technical lead that forces his team to produce reasonably readable, reasonably documented, reasonably maintainable and futureproof code, then the situation would already be very different. If we add to that that the inexperienced hacker prodigy would produce working code much faster, but his code would turn out to be brittle when someone else has to take care of it, because he does not yet have experience in interacting with lesser gods via his code, then the match would be even more equal. We may still prefer the hacker, but we would be forced to think about the trade offs involved.

sofal 17y ago
I think that enterprise teams typically follow strict syntactic coding standards and then check off the "maintainable" and "readable" requirement from that alone. Additionally, they generate mountains of bloated Word and PowerPoint documents and then consider that responsibility fulfilled. They end up with an incredibly expensive, over-engineered mega-application that exacerbates rather than solves the intended problem. Don't think that this doesn't happen. There are only so many things that you can force upon a team of programmers, and overall quality and cohesiveness aren't among them.
- ankhmoop 17y ago
  It's fairly easy to degenerate "enterprise developers" when you're defining what "enterprise" means.
  - sofal 17y ago
    My definition of "enterprise developer" comes directly from working in a gigantic financial company as well as an even more gigantic government defense contractor. Would you like some more anecdotes?
    - 17y ago

colomon 17y ago

The thing that really rings true in this story for me is the difficulty that management sometimes has understanding how hard the things we do are. It particularly shows up in cases that might sound like this one, where the solution is simple but hard to see. For instance, I recently corrected a bug in my code that had been there for a long time. The final code is dead simple. But it took years to detect the bug, and weeks of hard work and analysis to figure out that simple solution. (And of course, who knows -- maybe it's not as hard as I thought, and if I were just brilliant enough I would have instantly seen the solution. If I have no clue what the truth of the matter is, how is my (hypothetical) one step removed boss supposed to make sense of it?)

stonemetal 17y ago

I don't get it what is the take away of this story? If I play video games at work I am likely to get fired? If I follow company procedures I will get ahead? Seriously though work isn't track and field you don't win by being better than who ever came in second. You win by working to the best of your ability.

berniemac 17y ago
You clearly haven't worked at a large corporation. You get ahead by kissing up to the boss, holding large meetings, and creating fancy charts and graphs that explain why your project is 6 months behind.
- gruseom 17y ago
  And getting promoted or transferred before the project is killed.
  - gvb 17y ago
    See also "Seven Stages of a Project" http://corry.ws/CorryBook-69.htm http://corry.ws/CorryBook-69.htm
cabalamat 17y ago
The point of the story is that it's not how well you do your job that counts, it's how well your manager thinks you do it. It's all about perceptions. If you're a crap coder, but suck up to your boss, wear a smart suit (or whatever the conventional clothing is at your place of work), always arrive at work on time, etc, then you'll do better than if you're a brilliant coder, but wear unconventional clothes, come in on work late, etc.
- thetrumanshow 17y ago
  Your comment deserves to be a direct reply to the orignal posting. The current comments are tipping the scales in favor of Alan either by directly supporting overweight processes/solutions, or by demeaning the total comparative contribution of Charles (which has the same effect). For people who just cannot make the jump and understand what the author was saying, re-read the article, and instead of Charles playing Space Invaders, have him reading Hacker News instead. I think you'll see it takes on a whole new meaning for you.

mixmax 17y ago

Well, with a contrived made-up example you can prove just about anything.

sofal 17y ago
It's not intended to "prove" anything. It's an anecdote, used in the simple, appropriate way that anecdotes are always used. http://en.wikipedia.org/wiki/Anecdote http://en.wikipedia.org/wiki/Anecdote
- mixmax 17y ago
  You're right, the problem with anecdotes is that they are told as innocent stories, but often serve a higher purpose, intentional or not. This one is no diffferent in that regard. An anecdote is usually written to convey a truth, a mindset or a "right way" to the reader. This is how religion gets many of its points across to the reader. It's also how a lot of racism works (I know this black guy/eskimo/Indian that never works, they're all like that) And the reader, unless he has an analytical mind which many don't, will perceive that truth or right to be exactly that. No proof required.
  - sofal 17y ago
    I agree somewhat. An anecdote is a tool, and has been shown to have a more powerful effect on the minds of a population than solid evidence. However, I think that anecdotes offer much more than just a way to avoid having to prove your point. They're not merely for gaining power over weak minds. They can be useful among intelligent, analytical folks as well. They can serve as a supplement to real data. They can illustrate a point of view more accurately. They can communicate a feeling or a sentiment, and can pack more meaning and generate more tangents of discussion than dry statements of fact. A startup begins with something like an anecdote, an idea that may be crazy, but stems indirectly from a myriad of past experiences. Our brains are not binary storage units, and therefore anecdotes and parables have historically been used to help people remember things. Similarly, you cannot bring to the table a hard set of data for every life lesson that you've learned, and therefore you have many beneficial things to teach others that you cannot directly prove. If you're a good teacher, you'll tell an anecdote to help people remember (nonfictional preferred of course).

sengan 17y ago

Finding the simplest solution to a problem is hard, but because it seems simple in hindsight, only those competent in the art can recognize a brilliant solution. This is just another example of "bullshit baffles brains" and that it takes competence to recognize competence.

motoko 17y ago
Like how it took your competence to recognize the competence of the example?

edw519 17y ago

This story is troubling for several reasons. - "Lines of code" is a meaningless metric. Please stop using it. - Charles obviously did something when he appeared to be doing nothing. What? Unfortunately, we're never told. - There is no treatment of the things that likely are important: analysis, design, prototyping, feedback, fine tuning, etc. Did either programmer try any of these? - The story infers that using modern magical brilliance is better than using tried and true methods, without ever mentioning what either one is. I can imagine this story being true. Just as likely, I can imagine the opposite being true. Nothing offered, nothing learned.

sofal 17y ago
* "Lines of code" is a meaningless metric. Please stop using it.* I can agree that LOC is a terribly abused metric, but it is not completely without meaning. It's just really rough and better left untouched in decisions involving money. I can imagine this story being true. Just as likely, I can imagine the opposite being true. Nothing offered, nothing learned. I think it's just an invitation to reflect on the ways that this story comes true. People mistake needless, unhelpful processes for "tried and true methods" and software "architects" frequently over-engineer and create solutions worse than the problems. I'm not under any illusions that you (and most people here) don't already understand this. It probably wasn't aimed at you. There are many programmers today who don't understand that this kind of story plays itself out every day to some degree. The fact that the opposite story can also happen doesn't detract from the point that is being made.
TheSOB88 17y ago
I took the 'lines of code' thing as satirizing management.
mightybyte 17y ago
No, "Lines of code" is not a meaningless metric. I recently had to take over an existing code base for a module in our system and upgrade it to support the next version of our system's ICD. After spending some time trying to wrap my head around the existing 8800 lines of code, I concluded that it would be better to do a complete rewrite. The rewrite took a week or two and ended with 1950 lines of code that did essentially the same thing! Now, if we make the reasonable assumption that my rewrite was not a candidate for the IOCCC or Perl Golf, I think it's pretty clear that lines of code is not meaningless. A >75% code reduction while maintaining the same functionality under reasonable development conditions is almost always going to make it easier to test, debug, and maintain the system/module. (This assumption isn't unsubstantiated either. In a code review, I was even complimented on the quality of my documentation.) You hear about these kinds of vast disparities among software developers all the time, but I still find myself shaking my head that I actually saw it in real life. Now I'll freely admit that "lines of code" is mostly meaningless the way it is usually used. But don't throw the baby out with the bath water.

xenophanes 17y ago

It's like with essays: shorter essays take longer to write, because you have to spend more time editing and wording things in a clear and simple way.

caustic 17y ago

The story has sequel: The parable of the two programmers, continued http://portal.acm.org/citation.cfm?id=1012623 http://portal.acm.org/citation.cfm?id=1012623

nsoonhui 17y ago
This article is guarded behind a user name and password.. any free version?

ilyak 17y ago

The morals of this story: If you're that smart as Charles is, do this program in two weeks and move on. You'll get respect and raise, and get to solve more interesting problems.

thetrumanshow 17y ago

Wow! Lots of people here don't identify with Charles. Let's change the story a little and see if the response is any different... "Back at Consolidated, Charles spent some time thinking about the problem. His fellow employees noticed that Charles often sat with his feet on the desk, drinking coffee. He was occasionally seen at his computer terminal, but his office mate could tell from the lack of typing (and his always-interesting commentary at lunch) that he was likely reading Hacker News."