
A Tale of Two Programmers - frisco
http://mail.linux.ie/pipermail/social/1999-October/000483.html
======
edw519
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.

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

~~~
szx0
What if your 1950 was less expressive and more cryptic to understand, and the
8800 was very verbose and easy for a newbie to pick up?

So you can't measure less LOC means it's better, it really depends on the
quality of the code from a maintainability standpoint not just the size of
code.

~~~
mightybyte
On the other hand, the instant a manager starts making salary/bonuses
proportional to the inverse of code size, you'll find that my assertion
becomes completely false. But if you start from an empty slate of two
developers making a genuine effort to code a good solution, the less LOC rule
will probably be pretty accurate. Especially when one program is 4x the size
of the other. (See <http://paulgraham.com/head.html> for a related take on the
same idea.)

There are no absolutes. But that doesn't make these metrics useless.

~~~
wglb
There is actually one point missing from his list. I would put it after #5 and
that is "write provable programs". I suspect Paul does this anyway, but it is
a good thing to mention. This is scary to some, but PAIP has some very nice
examples of this.

And rereading this essay again shows at least part of the motivation for
making arc a smaller language than lisp.

------
colomon
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?)

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

~~~
sofal
_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.

~~~
motoko
Let's also imagine many Alans (corporate engineers) and Charles (hackers) and
from this bigger sample, measure how consistently each approach produces an
acceptable outcome.

It may be that the Charles, on average, produce better solutions with less
resources than the Alans, but that individually, more of the Charles projects
fail catastrophically.

 _Now imagine how good Charles would be if he could learn to cooperate and
participate in a group like Alan's._

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

Both excellent, I think. But further, let's imagine an organization that
arbitrates the risk of each Charles by simultaniously working many cheap,
risky Charles on the same problem and managing the results with an Alan-like
process.

If the Charles are software startups and the Alan-like process is "the
Internet," this could work.

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

~~~
sofal
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>

~~~
mixmax
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
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).

~~~
joe_the_user
_Our brains are not binary storage units, and therefore anecdotes and parables
have historically been used to help people remember things_.

Yes, an anecdote is a tool. It's great for remembering things, poor for
proving things. It just so happens the only conceivable purpose of the
original story was proving something. Now, if he had anecdote which helped you
remember, say, the standard form of the quadratic equation or something else
_people just needed to remember_ , then it would be using the tool for its
proper purpose.

~~~
sofal
_It just so happens the only conceivable purpose of the original story was
proving something._

Absolutely wrong. The purpose of the original story was to provide an
illustration.

 _Now, if he had anecdote which helped you remember, say, the standard form of
the quadratic equation..._

There are ideas and lessons worth remembering that aren't mathematical facts.

------
sengan
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
Like how it took your competence to recognize the competence of the example?

------
Confusion
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
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
It's fairly easy to degenerate "enterprise developers" when you're defining
what "enterprise" means.

~~~
sofal
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?

~~~
ankhmoop
No, because an "anecdote", by definition, is not statistically relevant.

"Enterprise teams" are not, inherently, profoundly stupid in their practice of
software engineering, and not all "hackers" inherently produce worthwhile,
quality code.

This completely fabricated fable of software engineering is a simple straw man
argument, and I've flagged it accordingly.

~~~
sofal
Every life lesson that you learn from experience is just a statistically
irrelevant anecdote and results in the refinement of a crude heuristic or
generalization mechanism for your limited human brain. Never did this
fabricated fable state or even hint that this was the way all enterprise teams
and all hackers are like. That, my friend, is the straw man argument coming
from you.

~~~
ankhmoop
If this fable didn't hint at that, what was its point?

That convincing management regardless of your productive output is what
matters at the end of the day? Perhaps at some organizations, but it's not a
particularly accurate, nuanced world view.

I doubt this story would be conveyed in reverse -- the stereotypical "rockstar
hacker" produces vast reams of code that will fail catastrophically, but comes
out ahead by, upon 'completion', immediately pushing responsibility for the
disastrously buggy code to the "stodgy" enterprise engineers who get called in
to maintain the project. The "rockstar" moves on to the next project, where
he'll repeat this performance, and the stodgy developers get poor performance
reviews.

~~~
matt-kantor
I actually thought the story hinted at the opposite: that individual
programmers who from the outside may look like slackers can produce good,
simple code and that process isn't everything.

------
swombat
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
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_Audienc...](http://www.csd.uwo.ca/~magi/personal/humour/Computer_Audience/The%20Parable%20of%20the%20Two%20Programmers.html)

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

~~~
mattyb
For those that haven't read The Story of Mel:

<http://www.pbm.com/~lindahl/mel.html>

~~~
ojbyrne
It was a better story than the OP.

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

~~~
sneakums
Because a lot of people clicked the up arrow.

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

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

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

------
stonemetal
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
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
And getting promoted or transferred before the project is killed.

~~~
gvb
See also "Seven Stages of a Project" <http://corry.ws/CorryBook-69.htm>

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

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

