The typical CS "curriculum" has a pretty large focus on performance. Most of the assignments given in my university had constraints around time, memory and cpu

The typical CS "curriculum" has a pretty large focus on performance. Most of the assignments given in my university had constraints around time, memory and cpu consumption. Therefore performance was heavily focused on. This has carried over quite well into my work life. Things like "big O", understanding the mechanics of different kinds of data structures, and their tradeoffs enter all my code. They don't really take up a large part of my active thinking, but I will routinely make decisions that are more performant and try to weigh in readability, "grok"-ability, and if they are common or not. I find that university forced me to learn the unattractive bits of computing, that if I was self taught I likely would've glossed over and not spent several months on. Yes, if stuff is legitimately slow, make it faster. But things typically _become slow_, it's a creep. As time progresses, it slows down, now it's slow and you may not have a product manager who thinks _now_ is the time to dedicated resources towards speeding it up.