In my experience they seem to love this but will call it “thinking from first principles” or something else to make sure they don’t sound like (gag) marketing people.
I have noticed that, at least in the Java world, people lie a lot about stuff going "faster", and I think it's just justification to not fix their terrible code.
I have written a lot of JMH benchmarks in the last year to test out claims from developers (some are on my blog, a lot I haven't written about yet), and so much shit that's supposedly "faster" simply isn't.
For example, I had a coworker who would write all this logic into tons of nested and sequential `for` loops, and the logic was disgusting but lent itself well enough to the Java streams API. I brought this up to this coworker, and he said he wouldn't do that because the streams are "slower" and that he "benchmarked to check". I wrote my own JMH benchmark to check and it turns out that the streams (at least for an application like this) are not actually slower than the loops; the two versions ran within about 3% of each other's. I don't think he actually wrote benchmarks, I think he was just lying and wanted me to stop interrogating.
All technical fields sure have their bullshit, wrapped in a layer of something else.
Another one pretty common backing decisions with bullshit or misleading numbers. Like A/B tests that don't cover the whole behavior spectrum or metrics that don't match the point we're making but sound close enough.
I have written a lot of JMH benchmarks in the last year to test out claims from developers (some are on my blog, a lot I haven't written about yet), and so much shit that's supposedly "faster" simply isn't.
For example, I had a coworker who would write all this logic into tons of nested and sequential `for` loops, and the logic was disgusting but lent itself well enough to the Java streams API. I brought this up to this coworker, and he said he wouldn't do that because the streams are "slower" and that he "benchmarked to check". I wrote my own JMH benchmark to check and it turns out that the streams (at least for an application like this) are not actually slower than the loops; the two versions ran within about 3% of each other's. I don't think he actually wrote benchmarks, I think he was just lying and wanted me to stop interrogating.