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.
Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
411–420 of 446 posts
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#412If 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."
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#413This 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."
Re: Nobody ever gets credit for fixing problems that never happened (2001) [pdf]
#414Earlier 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.
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]
#415This 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?
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]
#416This 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 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]
#417Earlier 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 += 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]
#418However 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]
#419Earlier 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…
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]
#420I'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.
Not too many of them around, are there? You can have either honesty or intelligence but not both.