[mewpmewp2]

Best example I've seen is wanting to optimize a frontend JS for loop that gets triggered maximally only once per page load, runs max 100 times in a loop with complicated data structures that will confuse any reader of that code why it was done like this and not just with a for loop.

[JohnBooty]

It's such a Dunning-Kruger effect. You get legitimately talented engineers who are talented enough to do a legitimately hard thing: optimizing a complex piece of code.

So, they don't realize that there's kind of another level of understanding beyond that (when to optimize vs. how to optimize)

There's also the fact that some people just like optimizing shit for selfish or even slightly nefarious reasons. Some just like doing it because it's fun. Others like it because it gives them visible and easily quantified "wins." On the rarer and more nefarious side of things, they may enjoy now having "ownership" over a piece of complex code that only they can understand....

[mewpmewp2]

I don't know how to exactly classify this, but based on my experience it feels like a certain type of engs who have only been exposed to this type of way of doing things from when they started, like at uni. It's to do with going through certain type of education, after that certain type of enterprisey environment following very strict rules of design patterns and applying these patterns to absolutely everything they do. They haven't done many quicker projects or side projects to realize that simpler things can work absolutely well enough to realize there can be flexiblity. I think they are good people and outside of work I get along well with them, but during work I do feel frustrated and when I try to explain it to them, I get kind of a West World like response "Doesn't look like anything to me". Like they can't get it, because they only have the uni and enterprise experience, and not experience to build things on their own volition.

[JohnBooty]

Yeah. I think formal CS education often does a good job of teaching students to optimize in a myopic way - calculating big-O notation, understanding basic algorithms and data structures etc.

It's also rigid by design and (probably) necessity: students don't typically encounter unknown, unchanging, and evolving constraints and requirements throughout the project. Lastly they are not typically maintaining a medium/large codebase in conjunction with other engineers.

So you tend to get these smart kids don't know when to optimize. They can make a 15-line function "faster" but they don't have a sense of the impact this has on a larger project and they don't know how to weigh the impact of an optimization vs. the effort involved and future complexity it might incur.

The lack of knowledge would be fine on its own, but back to the Dunning-Kruger effect: they typically don't know that they don't know this stuff.

Not sure how you change that at the CS education level, honestly. At the very least you could stress to the kids that in the real world you have conditions and goals much different than in CS classrooms...