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

81–90 of 169 posts

Re: The Parable of the Two Programmers (1985)

#81

Post by sudhirj »

iamwithnail wrote: post #66
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…

This is the mechanic story all over: Guy takes his car to a garage because it keeps breaking down, and the mechanic leans in and listens to the engine for a minute. He goes and gets a hammer and listens to the engine again, and then raps sharply on the engine casing. The engine goes back into sync and stops breaking down. The mechanic says "that'll be £500, please." The guy's outraged: "But all you did was tap it!" M…

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.

Re: The Parable of the Two Programmers (1985)

#82

Post by jakobegger »

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

Re: The Parable of the Two Programmers (1985)

#83

Post by arethuza »

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…

Absolutely, I finished (as in actually got the system to meet requirements) a system in 6 weeks that a team of ~15 (all gone by the time I had got there) had failed to do in a year.

Their system had many thousands of classes, mine probably had less than 50. Theirs used pretty much every technology in J2EE (this was a few years back) - mine used a very small set. I didn't even have to work very hard....

Re: The Parable of the Two Programmers (1985)

#84

Post by hotBacteria »

The story ends well because the project was actually simpler than what it looked at first. Unfortunately, more than often, things happen to be a lot harder than expected

What happens when, after 2 months of scribbling and playing space invaders, Charles realizes the project actually requires 3500 lines of code? He wants the project to succeed but now he doesn't have enough time, and he fears to ask for help because he knows he is labeled as a lazy and arrogant guy.

So he works long hours to fix the situation, then he burns out.

Source? This is somehow happened to me. Several times.

This story can be true, people like Charles and simple projects exist, but these are exceptions, not the rule. It's easy for a beginner to believe he is that guy and then experience a death march [1] Things can go wrong for Alan, but he has a team to support him and his managers know he is working at something complicated.

I'd like to be Charles one day, but for now I'm Alan.

[1] https://en.wikipedia.org/wiki/Death_march_(project_managemen...

Re: The Parable of the Two Programmers (1985)

#85

Post by woah »

chroma wrote: post #53
elpachuco wrote: post #38

Earlier quoted context omitted.

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

I'm curious to hear about how many problems you solve with these lines of code. I guess that's pretty much impossible to quantify though. Also, what languages do you work in?

I'm not that experienced, but I had a notable experience working with a 5000+ loc app that was a nightmare to maintain and extend. The last guy had basically reinvented every wheel. He was even, in my opinion, reimplementing the DOM in places with absolute positioning. Also, the code was poorly organized, with pieces of logic that could have been easily consolidated appearing throughout the app in multiple places so that they could not be abstracted out.

After about a month of trudging through his code and making almost no progress, I basically told my manager that we had to rewrite it (I had been thinking this the whole time, but I didn't want to be the junior dev who comes in and demands to scrap everything).

Me and a colleague paired on it for about 2 weeks and rewrote the whole thing entirely from scratch, leveraging several open source libraries and writing a few tested "internal libraries". The whole thing ended up being around ~800 loc when we were done, and it had the extra features that needed to be added, and was pretty bug free.

I'm not trying to blow my own horn here, in other instances I have spent way too long pondering about code and making it way more concise than necessary.

But unless you are a truly great coder who is cranking out 100 lines of good code per day (and I have no doubt that you are), I would be pretty suspicious about the amount that you are writing. I would worry that you are placing a great maintenance load on those who come after you.

Re: The Parable of the Two Programmers (1985)

#86

Post by alephnil »

hotBacteria wrote: post #84

The story ends well because the project was actually simpler than what it looked at first. Unfortunately, more than often, things happen to be a lot harder than expected What happens when, after 2 months of scribbling and playing space invaders, Charles realizes the project actually requires 3500 lines of code? He wants the project to succeed but now he doesn't have enough time, and he fears to ask for help because h…

If this story had happened in real life, and the problem had been more complicated than anticipated, and Charlie had realized this, it would be likely to fail, because he did not have enough leverage toward the upper management to get the resources required to succeed, so in that case the project would be likely to fail, or at least be severely delayed.

However, Alan was making the problem more complicated by introducing a lot of accidental complexity, and I have often seen that this is done even when the problem is more complicated than anticipated. Such a project could easily create enough work for 10-15 people in the hypothetical scenario in the article if the project had enough necessary complexity to be a four person project.

It is very hard to distinguish between what is necessary and accidental complexity, and that is precisely the point of the article. Prestige is very often bound to how many subordinates you have rather than how well you solve a particular task, so making your project artificially complex can be a strategy for climbing toward upper management. This may of cause be a conscious or unconscious from the employee/manager in question.

Re: The Parable of the Two Programmers (1985)

#87

Post by c54 »

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…

I think this is mostly true.

However, if you were watching someone prepare the most exquisite steak, and it took lets say a full hour to trim the meat, get the pan ready and properly buttered, cook off the edges of the steak, etc, and you were sitting there watching the chef go through this metiMaybe we just care about seeing the complexity in an operation for it to have value.culous process, then perhaps you wouldn't be upset that it took so long--and most likely would enjoy the steak more, having seen the entire complxex and careful process to cook the thing.

Similarly, if an oil change was a complex operation and you watched the mechanic half-dismantle your car to change whatever needed changing.

Or if you watched a programmer bounce around the screen in vim for 20 hours; coding, testing, tweaking, and debugging.

Re: The Parable of the Two Programmers (1985)

#88

Post by eludwig »

I think it's actually a great little story because in the end, everyone got what they wanted.

The lone programmer did his work, got paid for it and left, hopefully to find a company with a better fit.

The team was hired and got paid to do their work and, while doing so, created a process that the company felt comfortable with. Perhaps they are still working there today.

Everyone seems to have taken what they needed and got what they wanted.

There are an infinite number of ways to slice a thing. Choose one and figure out if it works for you. This applies to both sides, the worker and the management.

Re: The Parable of the Two Programmers (1985)

#89

Post by stestagg »

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…

Re 2) I've done this a few times.

The trick is to ignore the detail of the spec, and understand what they actually want better than they do.

If you get that right, then the actual coding becomes insignificant, and everyone is happy

Re: The Parable of the Two Programmers (1985)

#90

Post by colomon »

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.
Post reply on HN