Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

web.mit.edu

Post reply on HN
Print view View original

421–430 of 446 posts

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#421

Post by WalterBright »

godelski wrote: post #414
WalterBright wrote: post #392

Earlier quoted context omitted.

> Those 3 points are also true about your code. The difference is there are things the compiler can verify to be correct.

This conversation is a bit difficult when you're ignoring a fair amount of what I and others have said. I think you're wanting to be right so interpreting the words to support that. The compiler does not tell you that code is correct. It has no such capability and even LLMs are far away from doing that. The compiler can only tell you that the code is compilable. That means the syntax is correct, but it does not mean…

The compiler can verify for you that a pointer to const does not modify the pointed to data. It is not necessary to document it.

There are a number of constructs in C that require documentation because they are not expressible in code. More expressivity in the language reduces the documentation required. An ownership/borrowing capability means one doesn't have to document who the "owner" is. And so on.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#422

Post by atleastoptimal »

euroderf wrote: post #329
atleastoptimal wrote: post #297

Earlier quoted context omitted.

Even spending 5% of your time self marketing has massive dividends on your career vs spending 0% of your time. The virtues of your skills aren't self evident.

True. But when you're a smart kid and you get auto-noticed in school with no effort on your own part (aside from the academic effort!), maybe it's time to add a course like "Creating Your Own P.R... And Believing It Too" into the curriculum.

That's true, but everyone has to learn at some point. There's only a limited amount of attention in the world. Even the smartest are subject to the laws of human whims. The purpose of school and most vocational systems is to best advertise and direct the skills of those with the most potential to where their skills are suited best. However individual firms have their own needs and agendas, and often suffer from failures of pure meritocracy that their success allows them to go on without.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#423

Post by godelski »

WalterBright wrote: post #417
godelski wrote: post #402

Earlier quoted context omitted.

> Why should the documentation >> someone else is going to be reading your code. Someone else is going to {read,edit,write,maintain} your code. Which means __anything__ the code does should be explained. Before you were suggesting documentation is only for the user. Documentation is also important for the developer. Whoever takes over your code later or works on it with you.

I was objecting to comments like these: i += 2; // add 2 to i const(int)* p; // p will not change what it points to No value is added by such comments. Hence, the more expressive a language is, the fewer comments are needed. Of course, a precondition is that the person reading the code knows the language reasonably well, and I'm not writing a language tutorial.

I think we're talking about different things then. I don't think you need to document every single line of code. That would be insane and is absurdly pedantic. No one is suggesting you (more than) double the amount of text in a codebase.

But you should write summarize your abstractions. So that's your classes and functions. I agree with the other commenter that what is of most concern is the method's signature. Also, a naming might be obvious, but I assure you it is not. What is obvious to some is not obvious to others. In addition to this, the code changes over time. What once might have been obvious no longer is later down the line. Expect this to happen because you want to handle failure in your "system" (in this case, the style in which you write code). The more complexity in a method, the more important it is to document.

If you need an example I think both the main article AND the comments here are quite enlightening[0]. In fact, I'd say the comments perfectly prove the author's point. The author writes very clearly how when playing the game you should operate under purely the letter of the law but top comment claims crystal clarity yet mentions "intent." A point explicitly mentioned that one should ignore by the author.

Just think of documentation as information entropy. By adding a few words you increase the information gain for someone who has never before looked at the code. I've also given you reasons as to why you are likely to also benefit, so if you need a purely selfish reason to document, this too exists. But we must differentiate long term utility vs short term to see the reasoning.

[0] https://news.ycombinator.com/item?id=36453856

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#424

Post by godelski »

WalterBright wrote: post #421
godelski wrote: post #414

Earlier quoted context omitted.

This conversation is a bit difficult when you're ignoring a fair amount of what I and others have said. I think you're wanting to be right so interpreting the words to support that. The compiler does not tell you that code is correct. It has no such capability and even LLMs are far away from doing that. The compiler can only tell you that the code is compilable. That means the syntax is correct, but it does not mean…

The compiler can verify for you that a pointer to const does not modify the pointed to data. It is not necessary to document it. There are a number of constructs in C that require documentation because they are not expressible in code. More expressivity in the language reduces the documentation required. An ownership/borrowing capability means one doesn't have to document who the "owner" is. And so on.

As said in the other conversation, you're missing what's being communicated. And as __explicitly__ stated in the comment you replied to (this comment's gp), the compiler tells you __nothing__ about the logic. It can't! The compiler doesn't know human intention. It can tell you that you've accessed an out of bounds index, but it can't tell you that you selected the wrong index. These are very different things!

A compiler only tells you about semantic errors. It has no understanding though. This is true for any language. We can say/write things that are linguistically correct but have no actual meaning and tells us nothing about the "correctness" or efficiency of our usage.

Comments are for the logic, not grammar. The logic is abstract.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#425

Post by hinkley »

staunton wrote: post #284
hinkley wrote: post #121

Earlier quoted context omitted.

Having people thank me for being 'on top of' a problem that I already know about because I'm the one who pushed the button that broke it... It's gross. It feels gross. Much happier when I can fix something quickly because I have some tools or logic in the codebase already that lets me do something quickly by being covered with sanity checks so I can zip along without driving us off a cliff.

There's some people who break something, realize it, just leave it as is, and cannot comprehend why you would think they should maybe help fix it... So I'd guess the praise is for not being like that.

I see what you're saying, but that still feels like a participation trophy to me.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#426

Post by fifilura »

begueradj wrote: post #399
fifilura wrote: post #356

Earlier quoted context omitted.

Then you just have to refer to the Karma bucket. "In my/their next life..."

haha :) you are funny :)

Maybe. But still it is in the spirit of the parent post "Life and its rewards aren't perfect".

If you start micro-optimizing - especially on other people, whose behaviour you can rarely change. It may leave you with lots of frustration and completely missing the grand picture.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#427

Post by watwut »

ziddoap wrote: post #384
watwut wrote: post #373

Earlier quoted context omitted.

You cant use it as an argument, just like you cant use a fiction book as an argument.

Parent post didn't cite it in an argument. They shared a story.

Very likely fictional story which they tried to pass as a thing that happened.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#429

Post by scooke »

hakunin wrote: post #27

I've been contemplating the issue in the headline, as pertains to my value. When I help somebody in 40 mins with something they've been stuck on for 3 months, my value is clear to everyone. When I work there the whole time, and nobody ever gets stuck for 3 months, my value is unclear. Don't know how to deal with this paradox.

I'm currently in an unrelated field, but with a similar tension of unclear value while things work. The way to deal with this has been to keep a tally of checks on important systems, whether it's daily, weekly, monthly, with links to undesired outcomes should the process that has been checked fail. This list of you checking the processes is one way to "prove" your value, at least for ppl who wouldn't necessarily understand naturally.

Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]

#430

Post by knightofmars »

Xcelerate wrote: post #331
mixmastamyk wrote: post #151

Earlier quoted context omitted.

Well, you could dust off the old email and 'mistakenly' send it again. Though it will seem petty, a small fraction might rethink the past few months.

I’ve started doing something like this more frequently, but it is in the interest of job security / cover-my-butt rather than pettiness. I build something that depends on many systems that others have created and that uses data from probably about every dataset we have. What I build also has very high customer visibility. So whenever something breaks upstream, the first place customers notice the problem is in the sy…

This is absolutely not petty, you are doing your job (to provide value to the organization) and doing it extremely well. The work you are doing provides more value to your organization than you seem to realize. If I were your manager I would be pushing to get you a raise/promotion with this as the reason.
Post reply on HN