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

71–80 of 169 posts

Re: The Parable of the Two Programmers (1985)

#71

Post by scott_w »

If we pretend this was a real story, Charles's manager should really have spoken to Charles about playing Space Invaders for 2 weeks straight. While Charles may be getting some valuable thinking time in, I can imagine he's also pissing off his colleagues who will feel they're working to support a guy messing around.

The exact nature of that depends on Charles, his manager, and the company, but it is possible to have those conversations without diving in and accusing Charles of goofing off.

Also, the manager made a huge mistake in judging the code based on what he saw. He should have spoke to Charles about this and tried to glean some insight into how it came to look so easy. If I'm speculating, the manager was looking to punish Charles for his behaviour and went about it completely the wrong way.

Re: The Parable of the Two Programmers (1985)

#72

Post by ricefield »

scott_w wrote: post #71

If we pretend this was a real story, Charles's manager should really have spoken to Charles about playing Space Invaders for 2 weeks straight. While Charles may be getting some valuable thinking time in, I can imagine he's also pissing off his colleagues who will feel they're working to support a guy messing around. The exact nature of that depends on Charles, his manager, and the company, but it is possible to have…

And that is why this is a parable—not a real story, and not intended to be read as one.

Re: The Parable of the Two Programmers (1985)

#73

Post by motters »

This is a parable about whether you really understand the nature of the problem, or not. If you do then you can produce a concise definition (i.e. a better program in fewer LOC) and if you don't then it can get much more complex. It's like the difference between trying to make a machine fly by making wings out of feathers and having it flap, or understanding the principles of aerodynamics and making a fixed wing out of canvas.

However, for most non-trivial problems understanding everything up front isn't possible. To know what works you may need to create prototypes and iterate, abandoning things which don't work or which end in a hairball of complexity and getting opinions from testers. In that situation just intuiting a solution and then typing in the code won't work and the more formalised process might work better.

Re: The Parable of the Two Programmers (1985)

#74

Post by jacalata »

javert wrote: post #48
Iv wrote: post #45

Earlier quoted context omitted.

> 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…

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?

Re: The Parable of the Two Programmers (1985)

#75

Post by bottled_poe »

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…

That's because value is a nebulous term, and the common unit of measure which anyone can relate to is time.

Re: The Parable of the Two Programmers (1985)

#76

Post by rando289 »

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…

> I don't believe some parts in the story.

Cool story, but I have trouble believing parts of it.

Re: The Parable of the Two Programmers (1985)

#77

Post by cshimmin »

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.

Re: The Parable of the Two Programmers (1985)

#78

Post by jacquesm »

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…

If it even remotely conforms to the spec I'd say that's gold. More often than not 'barely' translates into 'does not bear any resemblance to'.

Re: The Parable of the Two Programmers (1985)

#79

Post by rkachowski »

The issue that seems to be overlooked here is the objective value of solving the problem itself. Instead it focuses on the developers and their rewards.

A does a thing, it takes a long time, solves the problem and he becomes System Analyst.

C does a thing, it's shorter in both time and effort, and he leaves the company a year later.

What about the value produced by the solution?

It's clear that if a single (inexperienced and poorly communicative) developer can produce a satisfactory solution in a fraction of the time of a majorly architected approach then the first view (A) is overvalued.

The moral of the story seems to be something about how huffing and puffing, self-importance is rewarded over a thought out appropriate solution to the task at hand.

How about going forward in the story? A sequel-sequel?

At Automated, their unrealistic approach to planning and development, and their focus on titles and rewards led to bloated and unmaintainable software, where everyone in the company fought to make something "smart" that demonstrated their intelligence and worthiness of being rewarded - the problem specifications being nothing more than a means to achieving this.

At C, Charles either gained the experience necessary to understand the reasons for communicating efforts and planning to the rest of his management and went on to design appropriate solutions in another company, or he decided that being rewarded for his efforts was more important than solving problems and gaining domain experience and joined the above.

Re: The Parable of the Two Programmers (1985)

#80

Post by jakobegger »

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…

I have a different experience. Our heating broke on two (unrelated) occasions.

In the first case, the repairman came, fixed the thing in 20 minutes, seemed competent, and I gladly payed him.

In the second case, the company sent an inexperienced employee, who couldn't figure out the problem, and spent 2 hours trying everything before finally deciding the most expensive component needed to be replaced. I was very unsatisfied, especially since they charged me for all the seemingly pointless troubleshooting time.

So maybe it's not only important to make a lot of effort, but to also appear competent while working?

Post reply on HN