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

121–130 of 169 posts

Re: The Parable of the Two Programmers (1985)

#121

Post by analog31 »

Hasu wrote: post #55
anaolykarpov wrote: post #35

There was a MOOC on Coursera called "Irrational Behaviour" and one of the stories there is about a locksmith who in the beginning of his career used to fix a door lock in more than an hour, with lots of effort and almost always destroying the door. His clients were happy to pay him the 70 dollars he charged for the operation and also tipped him most of the time. As time went by and his experience increased he got to…

>Conclusion: we don't want to pay related to the value we receive for a certain service, but to the amount of effort involved in the delivery of that service. I don't think that's a fair conclusion. There's much more going on here. Locks are security for people. If I call a locksmith and he takes over an hour to open or fix my lock, I think, "Oh, good, even a professional is going to take some time to get through thi…

The smart locksmith would open your door in 10 minutes, then offer to sell you a more expensive lock.

Re: The Parable of the Two Programmers (1985)

#122

Post by jqm »

jebediah wrote: post #4

Wow, as someone who is going to start doing Computer Science next year, I had already heard that most of programming is about thinking, but had no idea that is was to the point of 5 lines of code per day being exceptional.

For me, lines of code per day varies depending on what is being done and how.

If it's a meaty problem that is not well understood, or a language or framework I'm unfamiliar with, or I sense the situation is complex enough that an early bad decision could lead to unforeseen troubles later (and I should tread carefully), very few or no lines are written during the day.

On the other hand, if it is similar to a thing I have done many times before, and I'm comfortable with the problem, the language and framework then there is much less time thinking and StackOverflowing and I can go at nearly typing speed. (Likewise, if the code is quick "one of" type things for tests or throwaway stuff). More than several hundred lines of code a day (JS or Python) in cases like these is very achievable.

This doesn't count things like html templates, css etc (although sometime that take a bit of thought as well).

Re: The Parable of the Two Programmers (1985)

#123

Post by pmelendez »

Hasu wrote: post #55
anaolykarpov wrote: post #35

There was a MOOC on Coursera called "Irrational Behaviour" and one of the stories there is about a locksmith who in the beginning of his career used to fix a door lock in more than an hour, with lots of effort and almost always destroying the door. His clients were happy to pay him the 70 dollars he charged for the operation and also tipped him most of the time. As time went by and his experience increased he got to…

>Conclusion: we don't want to pay related to the value we receive for a certain service, but to the amount of effort involved in the delivery of that service. I don't think that's a fair conclusion. There's much more going on here. Locks are security for people. If I call a locksmith and he takes over an hour to open or fix my lock, I think, "Oh, good, even a professional is going to take some time to get through thi…

> If I buy a cabinet, I usually don't care if the carpenter took 10 hours or 20, I'm going to want to pay based on the quality of the cabinet.

I don't think that is true if you comissioned the cabinet or watched how to make it. I have seen the irrational behaviour several times in action in different scenarios: painters, landscapers, carpinters.

Re: The Parable of the Two Programmers (1985)

#124

Post by danschumann »

If there is a second sequel to this story, it's that the one guy goes on to start a successful company, and the other guy is entrenched in the politics of his company.

I think this would be a better comparison if space invaders was left out. Or perhaps if it were, "he scribbled for a while, then played space invaders, then scribbled some more.", as opposed to him starting with nothing but space invaders. The other guy began by inventing problems rather than solving them.

It comes down to, a direct, though outwardly puzzling, solution that is apt VS. an indirect, political, frustrating(for everyone), bloated, slow solution.

If it weren't a programming department, and it were two different companies, survival of the fittest would kick in, and the better faster guy would be more successful. And, it has. We now learn from the successful companies that are similar to the space invader guy and it doesn't seem so weird. The fact that people were catching on to this idea in 1985 is pretty striking.

This is anecdotal and doesn't really teach the bigger picture. It's also not encouraging, as it doesn't lead the user to the correct path of action.

It really needs a second sequel where the space invader guy goes on to be wildly successful to be a good story.

Re: The Parable of the Two Programmers (1985)

#125

Post by qb45 »

jakobegger wrote: post #82
greenyoda wrote: post #59

Earlier quoted context omitted.

"Can any of you actually relate a real-world case where a 4-month-long team-driven effort produced some code to solve a problem that could be solved by one cowboy in 3 months and 20% as many lines?" I've had the experience of refactoring my predecessor's code and ending up with 20% of the number of lines. Inexperienced programmers tend to write repetitive code instead of looking for abstractions to simplify the probl…

But sometimes you can see the possible abstractions only after the fact... I often end up deleting a lot of my own code that turned out to be unnecessary.

There are people who don't care to simplify the code even after the fact.

I worked on a project where half or so of the code was copy-pasted from somewhere else in the same codebase.

The original author claimed that this way is better as it allowed him to see what the code does without jumping around the whole codebase.

Re: The Parable of the Two Programmers (1985)

#126

Post by spiritplumber »

JoachimSchipper wrote: post #114
spiritplumber wrote: post #106

Earlier quoted context omitted.

Then there's the situation in industrial control systems where sometimes you really itch to do that, but you can't because the return statements mess up the tight timing :)

Can't you use stuff like gcc's __attribute__((always_inline)), or just straight-up C macros, for cases like those? Worst comes to worst, you can always use m4/cpp/some other preprocessor, although that does tend to hurt...

If the compilers you use have been updated this millennium, yes. However, that's a big if.

Re: The Parable of the Two Programmers (1985)

#127

Post by swatow »

gaius wrote: post #103
swatow wrote: post #33

Earlier quoted context omitted.

No, this is just an extreme example of the "don't try to be a smart guy" ideology. In practice 100-500 LOC per day is normal.

Firstly, any real working programmer has days where they write no code. You are writing documentation, meeting with users and sponsors to discuss new features and schedules, doing code-reviews and mentoring, merging branches, debugging race conditions, meeting vendors, chasing dependencies in other parts of the company, a million other things. That brings the average LOC/day down. I can't imagine anyone sustaining 10…

I realize that I was referring to number of LOC touched a day, not change to the total codebase size. I'm not sure what the first poster had in mind.

For reference, I count myself as writing about ~40 LOC a day for a greenfield project (which I spend about 50% of my time on), measured by total codebase size.

And no, it is not HTML templates, although it is a fairly verbose language. And I do all the things you describe in your first paragraph.

In my experience, a good programmer is almost always a fast programmer, and non-trivial programs usually require a lot of LOC to get the job done.

Re: The Parable of the Two Programmers (1985)

#128

Post by sanderjd »

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.

Yeah, but it's interesting - the parable would definitely work better if Charlie were the super-experienced engineer who knows enough to value simplicity and Alan were the fresh-out-of-school greenhorn still impressed by fancy one-size-fits-all methodologies.

Re: The Parable of the Two Programmers (1985)

#129

Post by gwern »

VLM wrote: post #98
sudhirj wrote: post #81

Earlier quoted context omitted.

Experience pays in other professions that require competency, though: a surgeon who can proficiently perform a bypass in a short amount of time is far more valuable than a fresh graduate who potters around in there for a while. No one ever complains that a surgeon finished too quickly.

The surgery marketplace is way too ignorant to be a real marketplace. Nobody has any idea how long my mother-in-law was under actually under the knife and nobody involved other than the surgeon, has any idea what the going rate is for gallbladder removal. Two minutes? Two hours? No one involved on the "purchase side" of the market can even guess. Without a functioning marketplace, numerical metrics don't mean much. A…

It gets worse, because it's such a probabilistic market. How does any patient tell the difference between a surgeon with a 10% fatality rate and a worse one with an 11% fatality rate? (At the usual estimates of the value of a life in the several millions USD, that 1% is worth a lot.) And if they somehow had that data, how would they adjust for the surgeons' working in different geographies or specializing in slightly different patient types?

This sort of problem is why making hospitals release medical data hasn't been very useful. And if you can't get much reliable signal out of large datasets with rigorous statistical analysis, how are ordinary people and gossip supposed to reach the right answers which could allow market mechanisms work?

Re: The Parable of the Two Programmers (1985)

#130

Post by gwern »

pm90 wrote: post #50
anaolykarpov wrote: post #35

There was a MOOC on Coursera called "Irrational Behaviour" and one of the stories there is about a locksmith who in the beginning of his career used to fix a door lock in more than an hour, with lots of effort and almost always destroying the door. His clients were happy to pay him the 70 dollars he charged for the operation and also tipped him most of the time. As time went by and his experience increased he got to…

It doesn't have to be amount of effort, even. In your example, the locksmith has so much experience, its easy for him to fix locks, so not much effort it required by him. But we do make this correlation between effort and time; so more time spent == more effort to our brain. That needs to change.

Nick Szabo has some writings on the economic shift to hourly wages and proof of work; because of the local knowledge problem (nobody can be an expert on everything, lots of information is hidden or inaccessible or tacit, and it's extremely difficult to determine value), looking at the labor or work which went into a product or service can be a simple fast heuristic for estimating the value of something - since if it was not at least that valuable, the actors who produced it and have more local or tacit knowledge would stop producing it.
Post reply on HN