6 ms·

The most misunderstood statement in all of programming by a wide margin. I really encourage people to read the Donald Knuth essay that features this sentiment.

The most misunderstood statement in all of programming by a wide margin. I really encourage people to read the Donald Knuth essay that features this sentiment. Pro tip: You can skip to the very end of the article to get to this sentiment without losing context. Here ya go: https://dl.acm.org/doi/10.1145/356635.356640 https://dl.acm.org/doi/10.1145/356635.356640 Basically, don't spend unnecessary effort increasing performance in an unmeasured way before its necessary, except for those 10% of situations where you know in advance that crucial performance is absolutely necessary. That is the sentiment. 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.

iamflimflam1 6mo ago
> 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.
Sammi 6mo ago
In particular I've seen way too many people use this term as an excuse to write obviously poor performing code. That's not what Knuth said. He never said it's ok to write obviously bad code. I'm still salty about that time a colleague suggested adding a 500 kb general purpose js library to a webapp that was already taking 12 seconds on initial load, in order to fix a tiny corner case, when we could have written our own micro utility in 20 lines. I had to spend so much time advocating to management for my choice to spend time writing that utility myself, because of that kind of garbage opinion that is way too acceptable in our industry today. The insufferable bastard kept saying I had to do measurements in order to make sure I wasn't prematurely optimizing. Guy adding 500 kb of js when you need 1 kb of it is obviously a horrible idea, especially when you're already way over the performance budget. Asshat. I'm still salty he got so much airtime for that shitty opinion of his and that I had to spend so much energy defending myself.
- jcgrillo 6mo ago
  Reminds me of a codebase that was littered with SQL injection opportunities because doing it right would have been "premature optimization" since it was "just" a research spike and not customer facing. Guess what happened when it got promoted to a customer facing product?
  - Shorel 6mo ago
    Now that's an stupid argument. I'm with you. Removing SQL injection has little if anything to do with performance, so it is not an optimization. I guess we will get more of this with the vibe coding craze.
    - fragmede 6mo ago
      We'll see. It's easy enough to ask Claude to red team and attack the system given the codebase and see what holes it finds to patch up. It's good enough now to find blatantly obvious shit like an SQL injection.
  - Quarrelsome 6mo ago
rkaregaran 6mo ago
(this is the correct answer, parent needs to understand this better)
sandeepkd 6mo ago
This is crucial detail that almost everyone misses when they are skimming the topic on surface. The implication is that this statement/law is referenced more often to shut down the architecture designs/discussions
dimitrios1 6mo ago
Even moreso . I like the Rob Pike restatement of this principle, it really makes it crystal clear: "You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is." Moreso, in my personal experience, I've seen a few speed hacks cause incorrect behavior on more than one occasion.
- YZF 6mo ago
  This is true but doesn't help. Parent is talking about building software that is inherently non-performant due to abstractions or architecture with the wrong assumption that it can be optimized later if needed. The analogy is trying to convert a garbage truck into a race car. A race car is built as a race car. You don't start building a garbage truck and then optimize it on the race course. There are obvious principles and understanding that first go into the building of a race car, assuming one is needed, and the optimization happens from that basis in testing on and off the track.
  - dimitrios1 6mo ago
    Ha! -- Allow me to introduce you to the US Diesel Truckin Nationals! Here are some dump trucks drag racing https://www.youtube.com/watch?v=aqxpOPeImkw https://www.youtube.com/watch?v=aqxpOPeImkw
    - YZF 6mo ago
      lol. TIL. But they're not racing Formula 1.
giancarlostoro 6mo ago
> except for those 10% of situations where you know in advance that crucial performance is absolutely necessary Yeah like, NOT indexing any fields in a database, that'll become a problem very quickly. ;)
- austin-cheney 6mo ago
  Those 10% situations will be identified by the business requirements. Everything else is an unmeasured assumption of priorities in conflict with the stated priorities. For the remaining 90% of situations high performance is always important but not as important as working software.
- ElectricalUnion 6mo ago
  Those days, what I see as "premature database optimization" is non-DBAs, without query plans, EXPLAINS and profiling, sprinkling lots of useless single column indexes that don't cover the actual columns used for joins and wheres, confusing the query planner and making the database MUCH slower and therefore more deadlock-prone instead.
tshaddox 6mo ago
> Basically, don't spend unnecessary effort increasing performance in an unmeasured way before its necessary, except for those 10% of situations where you know in advance that crucial performance is absolutely necessary. That is the sentiment. Which is pretty close to just saying "don't do anything unless you have a good reason for doing it."
hinkley 6mo ago
Because it reads like permission not to think and for a group of supposed intellectuals we spend a lot of fucking time trying not to think. Even 'grug brained' isn't about not thinking, it's about keeping capacity in reserve for when the shit hits the fan. Proper Grug Brain is fully compatible with Kernighan's Law.
red_admiral 6mo ago
Knuth certainly writes better than Dijkstra, even if he lost the "goto" argument in the end.
pelasaco 6mo ago
Computer scientist here. I love Donald Knuth, but he never maintained production systems :) I’m being a bit provocative here, just to make two points: a) Software development back in the day, especially when it comes to service, reach, security, etc., was completely different from today. Black Friday, millions of users, SLAs, 24-hour service... these didn’t exist back then. b) Because of so many conditions — some mentioned in point (a) - prematurity ends when the code is live in production. End.
port11 6mo ago
DRY might be even more misunderstood. We all parrot it to mean don’t duplicate code, forgoing the part where domain and function need to be taken into account.

iamflimflam1 6mo ago

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

Sammi 6mo ago

In particular I've seen way too many people use this term as an excuse to write obviously poor performing code. That's not what Knuth said. He never said it's ok to write obviously bad code. I'm still salty about that time a colleague suggested adding a 500 kb general purpose js library to a webapp that was already taking 12 seconds on initial load, in order to fix a tiny corner case, when we could have written our own micro utility in 20 lines. I had to spend so much time advocating to management for my choice to spend time writing that utility myself, because of that kind of garbage opinion that is way too acceptable in our industry today. The insufferable bastard kept saying I had to do measurements in order to make sure I wasn't prematurely optimizing. Guy adding 500 kb of js when you need 1 kb of it is obviously a horrible idea, especially when you're already way over the performance budget. Asshat. I'm still salty he got so much airtime for that shitty opinion of his and that I had to spend so much energy defending myself.

jcgrillo 6mo ago
Reminds me of a codebase that was littered with SQL injection opportunities because doing it right would have been "premature optimization" since it was "just" a research spike and not customer facing. Guess what happened when it got promoted to a customer facing product?
- Shorel 6mo ago
  Now that's an stupid argument. I'm with you. Removing SQL injection has little if anything to do with performance, so it is not an optimization. I guess we will get more of this with the vibe coding craze.
  - fragmede 6mo ago
    We'll see. It's easy enough to ask Claude to red team and attack the system given the codebase and see what holes it finds to patch up. It's good enough now to find blatantly obvious shit like an SQL injection.
- Quarrelsome 6mo ago

rkaregaran 6mo ago

(this is the correct answer, parent needs to understand this better)

sandeepkd 6mo ago

This is crucial detail that almost everyone misses when they are skimming the topic on surface. The implication is that this statement/law is referenced more often to shut down the architecture designs/discussions

dimitrios1 6mo ago

Even moreso . I like the Rob Pike restatement of this principle, it really makes it crystal clear: "You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is." Moreso, in my personal experience, I've seen a few speed hacks cause incorrect behavior on more than one occasion.

YZF 6mo ago
This is true but doesn't help. Parent is talking about building software that is inherently non-performant due to abstractions or architecture with the wrong assumption that it can be optimized later if needed. The analogy is trying to convert a garbage truck into a race car. A race car is built as a race car. You don't start building a garbage truck and then optimize it on the race course. There are obvious principles and understanding that first go into the building of a race car, assuming one is needed, and the optimization happens from that basis in testing on and off the track.
- dimitrios1 6mo ago
  Ha! -- Allow me to introduce you to the US Diesel Truckin Nationals! Here are some dump trucks drag racing https://www.youtube.com/watch?v=aqxpOPeImkw https://www.youtube.com/watch?v=aqxpOPeImkw
  - YZF 6mo ago
    lol. TIL. But they're not racing Formula 1.

giancarlostoro 6mo ago

> except for those 10% of situations where you know in advance that crucial performance is absolutely necessary Yeah like, NOT indexing any fields in a database, that'll become a problem very quickly. ;)

austin-cheney 6mo ago
Those 10% situations will be identified by the business requirements. Everything else is an unmeasured assumption of priorities in conflict with the stated priorities. For the remaining 90% of situations high performance is always important but not as important as working software.
ElectricalUnion 6mo ago
Those days, what I see as "premature database optimization" is non-DBAs, without query plans, EXPLAINS and profiling, sprinkling lots of useless single column indexes that don't cover the actual columns used for joins and wheres, confusing the query planner and making the database MUCH slower and therefore more deadlock-prone instead.

tshaddox 6mo ago

> Basically, don't spend unnecessary effort increasing performance in an unmeasured way before its necessary, except for those 10% of situations where you know in advance that crucial performance is absolutely necessary. That is the sentiment. Which is pretty close to just saying "don't do anything unless you have a good reason for doing it."

hinkley 6mo ago

Because it reads like permission not to think and for a group of supposed intellectuals we spend a lot of fucking time trying not to think. Even 'grug brained' isn't about not thinking, it's about keeping capacity in reserve for when the shit hits the fan. Proper Grug Brain is fully compatible with Kernighan's Law.

red_admiral 6mo ago

Knuth certainly writes better than Dijkstra, even if he lost the "goto" argument in the end.

pelasaco 6mo ago

Computer scientist here. I love Donald Knuth, but he never maintained production systems :) I’m being a bit provocative here, just to make two points: a) Software development back in the day, especially when it comes to service, reach, security, etc., was completely different from today. Black Friday, millions of users, SLAs, 24-hour service... these didn’t exist back then. b) Because of so many conditions — some mentioned in point (a) - prematurity ends when the code is live in production. End.

port11 6mo ago

DRY might be even more misunderstood. We all parrot it to mean don’t duplicate code, forgoing the part where domain and function need to be taken into account.