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

51–60 of 169 posts

Re: The Parable of the Two Programmers (1985)

#51

Post by greenyoda »

Iv wrote: post #45
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. But is that irrational? This seems to be a personal preference. By refusing to pay the same price for 10 minutes of work or one hour of work, we assert that we do believe in a certain income equality. "Disturbing someone for one hour vs 10 minutes" is not a ne…

It's irrational because the 10 minutes of work that doesn't destroy the door is worth much more than the hour of work that does - replacing a door is expensive and costs the homeowner additional time and aggravation.

Also, it's really more than 10 minutes of work, since the locksmith has to spend time driving to and from the customer. His fee needs to cover his travel time and expenses (gas, wear and tear on his truck, insurance, etc.). So $70 for a 10 minute house call doesn't seem unreasonable.

Re: The Parable of the Two Programmers (1985)

#52

Post by gknoy »

kylec wrote: post #20
[deleted] wrote: post #18

[deleted]

I don't know, maybe it took quite a bit of time and thinking to realize that the problem was simpler than it seemed. Maybe Charles was playing games to occupy his eyes and hands while he was thinking about the problem.

It's not that the problem was simple -- the other team's example shows that it was not. Rather, programmer C took the time to think about the problem enough, and write code that was elegant enough, that it __looked__ simple. Simple solutions almost always look easy in hindsight, but often are not simple to arrive at.

Re: The Parable of the Two Programmers (1985)

#53

Post by chroma »

elpachuco wrote: post #38
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.

100-500 LOC per day is normal. It is not. You are not writing a novel here. Yes, most of the time is spent thinking. Some days there is no coding because it is spent on just trying to figure out what to do.

While emotions may run high, it's important to remember that this is an empirical dispute. It can be resolved simply by looking at everyone's git history. For myself, the least code I've written on any day in the past year is 20 lines. My average is around 100. The most is a tad over 1500. Of course everyone's different and LoC is a terrible measure and it depends on the language, task at hand, etc. But in general, most of my time is spent "honing" code; testing/fixing corner cases and working around issues in other software. "Other software" includes browsers, filesystems, databases, JITs, but mostly browsers.

I personally don't spend much time thinking about software-related problems. At the risk of sounding conceited, I'll admit that most problems I encounter are pretty straightforward. Five minutes of uninterrupted thought is more than enough to get into diminishing returns.

It would be very interesting if GitHub pulled an OKCupid and published some statistical analysis of programmer behavior. They could put many of these disagreements to rest.

Re: The Parable of the Two Programmers (1985)

#54

Post by crdoconnor »

thaumaturgy wrote: post #36
raldi wrote: post #31

Earlier quoted context omitted.

Yes. I worked at a company that spent hundreds of thousands of dollars, and nearly a year, on a server monitoring system that never acheived a high enough timeseries resolution to actually solve the problem it was funded for. Then a 20-year veteran of the company stepped in and wrote a 50-line shell script, pushed it to the relevant machines, plugged it into the timeseries database, and solved the problem. He called…

Eww. Were there extenuating factors though? The monitoring system was somebody's pet project, or was purchased under contract on the hopes and dreams of sales, or the monitoring software did work but not in that specific environment, or...?

I've seen this exact same thing too. The "extenuating" (if you could call it that) factor was that the monitoring software was written in house and it was just shit. It might have been a pet project initially, but it didn't end up that way. It was just continued out of some combination of habit, risk aversion and not invented here syndrome.

When dumped and replaced by one of the better OSS versions in a few days by a developer who got fed up, things "magically" got much better, very quickly.

No praise or career boost at all for the developer in question, though. I think a large number of people (from management down) were embarrassed by the whole affair and wanted to forget about it. It seems that praise can only be dished out if you didn't embarrass somebody important.

Re: The Parable of the Two Programmers (1985)

#55

Post by Hasu »

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 this. It's pretty secure!" If the locksmith is done in 10 minutes, I think, "Holy shit! With the right tools and know-how, someone can completely bypass my security in ten minutes!" This isn't so shocking around here, because most people on HN know just how vulnerable most security systems can be. Many people will not have that knowledge and be comforted by a locksmith taking longer.

Also, when you hire a locksmith, you usually watch the locksmith do his work- either because you're locked out of something and have to stand around uselessly, or the guy is in your house and it shouldn't take too long. This makes you invested in his effort- if it takes an hour, you watched the locksmith work for an hour. It's hard not to pay, given that you saw how long it took, and how he was working at it.

The same standard doesn't seem to apply elsewhere- if my steak takes an hour rather than twenty minutes, I'm not going to pay more for it, I'm going to complain to the manager. If the oil change takes too long, I'm not going to be happy about that, either. 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 think your conclusion is true in some situations, but it's definitely not universal to all work.

Re: The Parable of the Two Programmers (1985)

#57

Post by greenyoda »

gknoy wrote: post #52
kylec wrote: post #20

Earlier quoted context omitted.

I don't know, maybe it took quite a bit of time and thinking to realize that the problem was simpler than it seemed. Maybe Charles was playing games to occupy his eyes and hands while he was thinking about the problem.

It's not that the problem was simple -- the other team's example shows that it was not. Rather, programmer C took the time to think about the problem enough, and write code that was elegant enough, that it __looked__ simple. Simple solutions almost always look easy in hindsight, but often are not simple to arrive at.

"It's not that the problem was simple -- the other team's example shows that it was not"

Not necessarily. It might show that the other team was either

(1) not smart enough to realize the problem's simplicity, or

(2) deliberately playing the political game of making the problem appear hard because they knew that in the end they'd get more recognition. The lead programmer, Alan, got to have three people working for him, which could have been a step up for him on the corporate ladder. The corporate world is full of this kind of empire-building.

Re: The Parable of the Two Programmers (1985)

#58

Post by greenyoda »

swatow wrote: post #33
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.

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.

It depends a lot on what kind of code you're writing. Don't expect to write 500 LOC/day if your project is to write a device driver or an improved computer vision algorithm.

Re: The Parable of the Two Programmers (1985)

#59

Post by greenyoda »

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…

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

Re: The Parable of the Two Programmers (1985)

#60

Post by frozenport »

greenyoda wrote: post #58
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.

It depends a lot on what kind of code you're writing. Don't expect to write 500 LOC/day if your project is to write a device driver or an improved computer vision algorithm.

>>an improved computer vision algorithm

I do this for remote sensing, and I might write 50 loc on the main thing, and often a bunch of python to test if the idea works.

Post reply on HN