Live data from Hacker News

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

web.mit.edu

411–420 of 446 posts

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

#411
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.

Life and its rewards aren't perfect. Work with honest, intelligent people; genuinely do your best; your days will be much better and the odds will be with you.

Another perspective: if you are not in a position to change the rules of the game, understand the rules of the game and play that game, not another one that you would like to play or that you think is more fair to play. Alternatively, if it is not the game you want to play, find a place where that game, or a similar one, is played.

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

#413

This explains anti-vaxxers beautifully. If everyone is vaccinated and the disease disappears (and kills few people) anti-vaxxers think: “why do we vaccinate everyone? The disease didn't kill anyone... and it disappeared."

So if you have a headache and you take an aspirin and the headache disappears you're going to conclude it's from the aspirin, right?

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

#414

Earlier quoted context omitted.

> My goal is to write code that is so clear it doesn't need documentation. I hear this so often but I think it is an excuse. Those 3 points are also true about your code. > There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors

> 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 logic is. The logic is much more abstract in terms of correctness.

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

#415
post #413

This explains anti-vaxxers beautifully. If everyone is vaccinated and the disease disappears (and kills few people) anti-vaxxers think: “why do we vaccinate everyone? The disease didn't kill anyone... and it disappeared."

So if you have a headache and you take an aspirin and the headache disappears you're going to conclude it's from the aspirin, right?

In headache case, the link between illness and cure is instantaneous.

But when it comes to vaccination, due to the time needed for everything to take effect (many people need to be vaccinated, it takes time) anti-vaccines are unable to link the vaccine to a cure for the disease.

For humans, time changes everything, even the ability to make a connection between illness and cure.

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

#416

This is wonderful description of the kind of hellhole corporate Scrum is turning into. Agile was literally about doing things quickly and quick cycles of capability improvement. But Scrum is a worse version of the planning processes it meant to replace! If anything, the way scrum lays out the work into immediate problems exacerbates the cycle. In the long run it just turns into a ticketing system where fires get push…

> Scrum is a worse version of the planning processes it meant to replace! You say this as if it was a coincidence. I'm allowed to say such things. Some of my best friends are scrum masters.

I still can't believe a scrum master is an actual FT job - last company I worked for had one FT scrum master for each project - so they ran the meetings and as far as I can tell, did nothing else - what the heck do they pretend to do for the rest of the week?

I went to all the same meetings, and was still supposed to actually develop software in between them all.

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

#417

Earlier quoted context omitted.

Why should the documentation repeat that a pointer to const cannot modify what it is pointing to?

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

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

#418
Nobody is a strong word. There are many competent engineering teams that understand the value of strong foundations.

However the problem is quite real in large companies where promo driven development takes over and the incentives are shifted from building what is valuable to customers to building what is valuable to get a promo.

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

#419

Earlier quoted context omitted.

> Most people can be trained well to do any job required of them. I really wish this were true, but especially in programming I don’t think this is the case. I’ve spent years as a programming teacher. Some of my students have been among the most wonderful, enthusiastic, hard working students you can find. And yet, despite both of us working hard for a year or more, some never develop any talent whatsoever for program…

> I really wish this were true, but especially in programming I don’t think this is the case. I should have made my prior assumptions clear. The "most people" I'm referring to are CS graduates or people with IT diplomas and the percentage among those who are trainable to a capacity of competence in most companies are roughly 70%. > Perpetuating the lie that all our brains have an equal capacity to program is a terrib…

> The world is not a fair place.

Yep. Those two stories are in some amount of conflict. I agree that anyone who has passed a decent hiring bar can be trained to some baseline level of competence. But the difference in capacity between that baseline level and someone brilliant can be huge. And it matters. This is the difference between something being an ongoing issue for the team for months, and it just quietly never seeming like it was ever a problem in the first place. As you say, it’s totally unfair.

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

#420
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.

Life and its rewards aren't perfect. Work with honest, intelligent people; genuinely do your best; your days will be much better and the odds will be with you.

>Work with honest, intelligent people

Not too many of them around, are there? You can have either honesty or intelligence but not both.

Post reply on HN