Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Parable of the Two Programmers (1985)

csd.uwo.ca

Post reply on HN
Print view View original

131–140 of 169 posts

Re: The Parable of the Two Programmers (1985)

#131

Post by gwern »

jarcane wrote: post #70
webreac wrote: post #39

That is why I love perl: the manager can not understand it and can not say it was simple.

I wonder how much language popularity is affected by this effect. We Lisp/FP fans crow about how easy and quick dev in more expressive languages is, but to a clueless manager that's potentially exactly the problem. If it doesn't look like work, then the manager is apt to wonder what they're paying you for. Whereas JavaEE ...

APL should've been much more popular if prestige by intimidation was a major factor.

Re: The Parable of the Two Programmers (1985)

#132

Post by Periodic »

I dislike this strongly. It is attempting to demean a group of people without really giving them a fair chance. It exaggerates and vilifies the "enterprise programmer" while lionizing the young-but-inexperienced smart programmer. It's a very common theme here on HN. It's playing into the narrative of the young entrepreneur that can drop out of college and build the next successful start-up. The fact is that most people in that situation will fail the first few times as they gain experience. People who can operate like Alan, though obviously Alan does not deliver results, are very valuable in a company. Systems have a tendency to get more complex and you will need people who have experience dealing with that complexity, managing it, and reducing it.

Let me address the parable a bit more directly.

The parable is very hard for me to relate to because to me it seems like the two characters are cherry picked such that they're vastly different in terms of skills. It looks to me like Charles is either much better than Alan at design or got lucky. I think the only wisdom that can be gleaned from the story is to not over-complicate your design. Charles and Alan both spend time upfront designing their code, but it seems that Charles came up with the better design and saw the simple kernel of the problem. That's the only real difference between the two. Alan saw a problem that needed a lot of work and specs to get right, but Charles saw it was actually a very simple problem.

I would say the lesson is to make sure you understand the problem well enough, but Alan is an experienced guy who still couldn't figure it out, so it must have been a hard problem to know how to work with in the first place. Maybe Alan was working defensively to make sure he had all his bases covered in case the design turned out to be different than he initially anticipated. I can't say.

Re: The Parable of the Two Programmers (1985)

#133

Post by JohnHaugeland »

colomon wrote: post #90
jakobegger wrote: post #61

I don't believe some parts in the story. 1) In my experience people fresh out of college don't deliver well tested code that goes beyond the spec. I'd rather expect something that barely conforms to the spec, neglects a few edge cases, and crashes when you input typical data. 2) A coder that spends a few weeks all by himself to implement a spec and then delivers a perfect product seems implausible even for an experie…

It's explicitly labeled a parable: "a simple story used to illustrate a lesson." It's not meant to be literally true. The second programmer's inexperience is just another reason why his boss judges his work to obviously have been easy.

Unrealistic parables teach unrealistic lessons

That a thing is a parable does not render it immune to disagreement on realism grounds

Indeed if the defense is to point out that it's not meant to be realistic then it's probably not just valueless, but of negative value

Parables are not a good way to learn in my opinion

Re: The Parable of the Two Programmers (1985)

#134

Post by vegabook »

cshimmin wrote: post #77
ai_ja_nai wrote: post #67

This parable is somewhat untrue, as it pats over the "good students engineers" shoulders, while throwing "cowboy programmers" out in the cold. Unless you are producing libraries or frameworks, management don't care about internals of software. It's an engineers' problem next time they ask for a modification. Management care about having their problems solved. That's why relations between management and engineers are…

I think you missed the point.

...though the idea that "engineers want to produce art, while management wants to sell stuff" has a lot of truth, and does have oblique relevance to the post, in the sense that Charles' "goofing off" was about thinking about the best way to abstract the problem and write it elegantly and concisely.

Re: The Parable of the Two Programmers (1985)

#135

Post by frostmatthew »

EliRivers wrote: post #116
raldi wrote: post #112

Earlier quoted context omitted.

I don't understand; your numbers add up to 5400, not 300.

The final column isn't LoC written that day; it's LoC in total. Friday was spent refactoring (what we in the old days called "rewriting", before the hipsters made it cool); taking the code that was already working, and making it smaller, lighter, better.

> what we in the old days called "rewriting", before the hipsters made it cool

Calling it refactoring dates back to at least the early 90s[1], which I'm pretty sure predates "hipster hackers." If anyone "made it cool" it was probably Martin Fowler[2].

[1] http://www.ai.univ-paris8.fr/~lysop/opdyke-thesis.pdf

[2] http://www.amazon.com/gp/product/0201485672

Re: The Parable of the Two Programmers (1985)

#136

Post by Iftheshoefits »

thaumaturgy wrote: post #23

Oh god, this thing's actually getting traction here. Look, there's no moral to this story and very little to glean from it because it's about a situation that's ridiculous on its face. It's written to appeal to cowboy programmers to make them feel better about their prejudices in software development. Can any of you actually relate a real-world case where a 4-month-long team-driven effort produced some code to solve…

You're going to get a lot of "yes" responses to your questions that themselves are going to be embellishments (or outright lies), omit context, pretend that refactoring an existing set of code is the same as writing it from scratch under the same conditions, etc.

Our industry is filled with people who are "cowboy programmers" and think of themselves as Charlie when in reality they're more like Alan, and are attributing what is actually pure luck and circumstance to their own brilliance. There's an especially high concentration of this BS on HN. You only need review the HN threads about the HealthCare.gov website to see this in action.

That's not to say this sort of scenario doesn't exist, never occurs, etc. It's just that there is likely to be an extraordinarily high number of people who read HN who believe they have experienced it (on either side), even if an objective evaluation of the circumstances would reveal they haven't.

Re: The Parable of the Two Programmers (1985)

#137

Post by moca »

I have seen this kind of problems many times in real life. By start writing design doc and prototype code from very beginning, you demonstrate effort and progress. You most likely get hold of the project and eventually deliver it along with all the incremental complexity during the process.

On the other hand, if you spend 2 months iterate through the requirements and alternative design choices, you are far more likely to come up better design, but your manager (or the entire company) would have no patience to watch you thinking in your head. As the result, I have seen software designs could have been 10x or even 1000x better, but most people prefer to get something out first (this is especially necessary for startups).

Another random comment is LoC per day. I worked at a few large companies. The statistics show the residual code is about 6-16 lines of code per business day per software engineer. A lot of time goes into design, debugging, testing, iterations, redesign, refactoring.

Re: The Parable of the Two Programmers (1985)

#138

Post by ai_ja_nai »

cshimmin wrote: post #77
ai_ja_nai wrote: post #67

This parable is somewhat untrue, as it pats over the "good students engineers" shoulders, while throwing "cowboy programmers" out in the cold. Unless you are producing libraries or frameworks, management don't care about internals of software. It's an engineers' problem next time they ask for a modification. Management care about having their problems solved. That's why relations between management and engineers are…

I think you missed the point.

tell me, please

Re: The Parable of the Two Programmers (1985)

#139

Post by javert »

jebediah wrote: post #111
javert wrote: post #8

Earlier quoted context omitted.

Don't wait until next year. Start programming now. School is good to learn computer science; school is not needed to learn how to program. Don't read anything into the 5 lines of code per day. This is a pretty old article and even then, that would only be a reasonable figure if you take a large number of people on a large project and compute an average for everyone. In other words, counting refactoring, fixing bugs,…

I have already started programming, it is just that all the problem sets I have solved were easy enough that I could get to coding right away, and when I couldn't I just thought I was dumb

Don't ever let yourself think you are dumb. It's a lot more harmful to your psychology and to learning than it may at frist appear.

If you can't figure something out, you are just lacking some knowledge you need. I wish I had learned that a long time ago.

Being dumb is never the explanation for not understanding or figuring out something.

Re: The Parable of the Two Programmers (1985)

#140

Post by wolfgke »

jacalata wrote: post #74
javert wrote: post #48

Earlier quoted context omitted.

No, people get angry at being charged $70 for 10 minutes of work because they think they're getting cheated, even though in this case they aren't. You're not going to find your rationalization for socialism here.

And why do they think they're getting cheated?

Because the hourly rate looks very high.
Post reply on HN