Live data from Hacker News

Ask YC: Code Digesting

news.ycombinator.com

11–15 of 15 posts

Re: Ask YC: Code Digesting

#11
post #2

Makes no sense to me. Never did. The speed which the code can be understood says much more about the writer than the reader. I have business analysts, project managers, and users that can read and understand my code. Do you really think that's a valid test of "programming ability"? Also, consider: 1. 30 pages of well written code != 30 pages of poorly written code 2. 30 pages of well documented code != 30 pages of po…

I disagree, for the most part. I think that in most large development shops, more time is spent reading code than writing code (think of the number of minutes each day spent actually typing versus those spent looking at the monitor) and that being able to clearly comprehend what has been written is extremely important. .

It is clear that well written, well documented code is easier to read than poorly written, poorly documented code. But, for the purposes of Bill's argument, we can assume the code in question is of average quality.

We know enough of Bill's 1986 context to assume that the code he is referring to would be C++ or Assembler. (Included in the book are some pages of the 8080 code for BASIC, written by Bill.) Naturally, the number of pages would vary for different languages, but the argument can be adjusted accordingly.

Finally: building code that satisfies requirements and works perfectly is a noble goal. The question is: is there any test than can be given quickly that acts as decent predictor for this ability? I think Bill's test is not too bad in this regard.

Re: Ask YC: Code Digesting

#12
post #2

Makes no sense to me. Never did. The speed which the code can be understood says much more about the writer than the reader. I have business analysts, project managers, and users that can read and understand my code. Do you really think that's a valid test of "programming ability"? Also, consider: 1. 30 pages of well written code != 30 pages of poorly written code 2. 30 pages of well documented code != 30 pages of po…

I disagree, for the most part. I think that in most large development shops, more time is spent reading code than writing code (think of the number of minutes each day spent actually typing versus those spent looking at the monitor) and that being able to clearly comprehend what has been written is extremely important. . It is clear that well written, well documented code is easier to read than poorly written, poorly…

"building code that satisfies requirements and works perfectly is a noble goal"

At Microsoft, it may be a noble goal.

With my customers, it is a requirement.

Re: Ask YC: Code Digesting

#13
post #12

Earlier quoted context omitted.

I disagree, for the most part. I think that in most large development shops, more time is spent reading code than writing code (think of the number of minutes each day spent actually typing versus those spent looking at the monitor) and that being able to clearly comprehend what has been written is extremely important. . It is clear that well written, well documented code is easier to read than poorly written, poorly…

"building code that satisfies requirements and works perfectly is a noble goal" At Microsoft, it may be a noble goal. With my customers, it is a requirement.

Your customers require perfection? You've got tough customers, then. I assume they refuse to pay maintenance/support fees on principle...

Re: Ask YC: Code Digesting

#14
post #12

Earlier quoted context omitted.

"building code that satisfies requirements and works perfectly is a noble goal" At Microsoft, it may be a noble goal. With my customers, it is a requirement.

Your customers require perfection? You've got tough customers, then. I assume they refuse to pay maintenance/support fees on principle...

I don't think they're tough. They just treat IT like anything else they spend their money on.

To them, maintenance/support is for changes they want, not for fixing bugs that should have never been there in the first place. Less than 5% is for that.

Re: Ask YC: Code Digesting

#15
post #14

Earlier quoted context omitted.

Your customers require perfection? You've got tough customers, then. I assume they refuse to pay maintenance/support fees on principle...

I don't think they're tough. They just treat IT like anything else they spend their money on. To them, maintenance/support is for changes they want, not for fixing bugs that should have never been there in the first place. Less than 5% is for that.

Wow. I can't think of anything I've spent my money on recently that has been perfect, software or otherwise.
Post reply on HN