7 ms·

> I have seen people take this to some bizarre alternate insanity of their own creation as a law to never measure anything, typically because the given develope

> I have seen people take this to some bizarre alternate insanity of their own creation as a law to never measure anything, typically because the given developer cannot measure things. Similar to the "code should be self documenting - ergo: We don't write any comments, ever"

msla 6mo ago
> Similar to the "code should be self documenting - ergo: We don't write any comments, ever" My counterpoint: Code can be self-documenting, reality isn't. You can have a perfectly clear method that does something nobody will ever understand unless you have plenty of documentation about why that specific thing needs to be done, and why it can't be simpler. Like having special-casing for DST in Arizona, which no other state seems to need: https://en.wikipedia.org/wiki/Time_in_the_United_States https://en.wikipedia.org/wiki/Time_in_the_United_States
- pc86 6mo ago
  This isn't a counterpoint, it's just additional (and barely relevant) information.
  - msla 6mo ago
    It's a counterpoint to the maxim, not the post I'm replying to.
- switchbak 6mo ago
  Documenting it in a way that ensures it satisfies the example case would be preferred. You know, like with a test.
  - msla 6mo ago
    "Why is this person testing that Arizona does such bizarre things with time? Surely no actual state is like that! Such complexity! Take it out!"
p0nce 6mo ago
Laziness in moral clothing.
f1shy 6mo ago
It is to me incredible, how many „developers“, even “10 years senior developers” have no idea how to use a dubugger and or profiler. I’ve even met some that asked “what is a profiler?” I hope I’m not insulting anybody, but to me is like going to an “experienced mechanic” and they don’t know what a screwdriver is.
- afpx 6mo ago
  The last time I interviewed (around 10 years ago) I was surprised when 9 of the 10 senior developers didn't know how many bits were in basic elemetary types. (Then, shortly afterward I also tried to find a new job, realized the entire industry had changed, and was fortunate enough to decide it wasn't worth the trouble.)
  - WalterBright 6mo ago
    > 9 of the 10 senior developers didn't know how many bits were in basic elemetary types That's likely thanks to C which goes to great pains to not specify the size of the basic types. For example, for 64 bit architectures, "long" is 32 bits on the Mac and 64 bits everywhere else. The net result of that is I never use C "long", instead using "int" and "long long". This mess is why D has 32 bit ints and 64 bit longs, whether it's a 32 bit machine or a 64 bit machine. The result was we haven't had porting problems with integer sizes.
    - afpx 6mo ago
      That's a reasonable answer. But, I meant they seemed to have little understanding or interest. I don't interview much, and I'm probably a poor interviewer. But, I guess I was expecting some discussion.
      - WalterBright 6mo ago
        I ran into some comp sci graduates in the early 80's who did not know what a "register" was. To be fair, though, I come up short on a lot of things comp sci graduates know. It's why Andrei Alexandrescu and I made a good team. I was the engineer, and he the scientist. The yin and the yang, so to speak.
alexjplant 6mo ago
> "code should be self documenting It should be to the greatest extent possible. Strive to write literate code before writing a comment. Comments should be how and why, not what. > - ergo: We don't write any comments, ever" Indeed this does not logically follow. Writing fluent, idiomatic code with real names for symbols and obvious control flow beats writing brain teasers riddled with comments that are necessary because of the difficulty in parsing a 15-line statement with triply-nested closures and single-letter variable names. There's a wide middle ground where comments are leveraged, not made out of necessity.
- Sharlin 6mo ago
  You misunderstood the GP - they were criticizing the way some programmers use "code should be self-documenting" as an excuse when they actually mean "I’m too lazy to write comments even when I really should". Just like "premature optimization is bad" may in fact mean something like "I never bothered to learn how to measure and reason about performance"
  - wombatpm 6mo ago
    At a minimum they should comment their GOTO’s
  - alexjplant 6mo ago
    Updated my comment to refine my rhetorical intent. Thank you for the call-out.
rustystump 6mo ago
Language conventions aside, i have rarely found a comments to be and more often they have lied to me. AI makes this both worse and better. I know it may be hard for me to understand the need for writing in english what is obvious (to me) in code. I also know i have read a stupid amount of code. My rule is simple, if the comment repeats verbatim the name of a variable declaration or function name, it has to go. Anything else we can talk about.

msla 6mo ago

> Similar to the "code should be self documenting - ergo: We don't write any comments, ever" My counterpoint: Code can be self-documenting, reality isn't. You can have a perfectly clear method that does something nobody will ever understand unless you have plenty of documentation about why that specific thing needs to be done, and why it can't be simpler. Like having special-casing for DST in Arizona, which no other state seems to need: https://en.wikipedia.org/wiki/Time_in_the_United_States https://en.wikipedia.org/wiki/Time_in_the_United_States

pc86 6mo ago
This isn't a counterpoint, it's just additional (and barely relevant) information.
- msla 6mo ago
  It's a counterpoint to the maxim, not the post I'm replying to.
switchbak 6mo ago
Documenting it in a way that ensures it satisfies the example case would be preferred. You know, like with a test.
- msla 6mo ago
  "Why is this person testing that Arizona does such bizarre things with time? Surely no actual state is like that! Such complexity! Take it out!"

p0nce 6mo ago

Laziness in moral clothing.

f1shy 6mo ago

It is to me incredible, how many „developers“, even “10 years senior developers” have no idea how to use a dubugger and or profiler. I’ve even met some that asked “what is a profiler?” I hope I’m not insulting anybody, but to me is like going to an “experienced mechanic” and they don’t know what a screwdriver is.

afpx 6mo ago
The last time I interviewed (around 10 years ago) I was surprised when 9 of the 10 senior developers didn't know how many bits were in basic elemetary types. (Then, shortly afterward I also tried to find a new job, realized the entire industry had changed, and was fortunate enough to decide it wasn't worth the trouble.)
- WalterBright 6mo ago
  > 9 of the 10 senior developers didn't know how many bits were in basic elemetary types That's likely thanks to C which goes to great pains to not specify the size of the basic types. For example, for 64 bit architectures, "long" is 32 bits on the Mac and 64 bits everywhere else. The net result of that is I never use C "long", instead using "int" and "long long". This mess is why D has 32 bit ints and 64 bit longs, whether it's a 32 bit machine or a 64 bit machine. The result was we haven't had porting problems with integer sizes.
  - afpx 6mo ago
    That's a reasonable answer. But, I meant they seemed to have little understanding or interest. I don't interview much, and I'm probably a poor interviewer. But, I guess I was expecting some discussion.
    - WalterBright 6mo ago
      I ran into some comp sci graduates in the early 80's who did not know what a "register" was. To be fair, though, I come up short on a lot of things comp sci graduates know. It's why Andrei Alexandrescu and I made a good team. I was the engineer, and he the scientist. The yin and the yang, so to speak.

alexjplant 6mo ago

> "code should be self documenting It should be to the greatest extent possible. Strive to write literate code before writing a comment. Comments should be how and why, not what. > - ergo: We don't write any comments, ever" Indeed this does not logically follow. Writing fluent, idiomatic code with real names for symbols and obvious control flow beats writing brain teasers riddled with comments that are necessary because of the difficulty in parsing a 15-line statement with triply-nested closures and single-letter variable names. There's a wide middle ground where comments are leveraged, not made out of necessity.

Sharlin 6mo ago
You misunderstood the GP - they were criticizing the way some programmers use "code should be self-documenting" as an excuse when they actually mean "I’m too lazy to write comments even when I really should". Just like "premature optimization is bad" may in fact mean something like "I never bothered to learn how to measure and reason about performance"
- wombatpm 6mo ago
  At a minimum they should comment their GOTO’s
- alexjplant 6mo ago
  Updated my comment to refine my rhetorical intent. Thank you for the call-out.

rustystump 6mo ago

Language conventions aside, i have rarely found a comments to be and more often they have lied to me. AI makes this both worse and better. I know it may be hard for me to understand the need for writing in english what is obvious (to me) in code. I also know i have read a stupid amount of code. My rule is simple, if the comment repeats verbatim the name of a variable declaration or function name, it has to go. Anything else we can talk about.