The first time I was told, "Make it work, make it right, make it fast," was in my first programming course. However, it was in passing by another professor substituting. After the first programming course, we had OOP Design. It's how to better structure OOP software, abstractions and design patterns. This was our, "This is how good programmers do it."

That same professor who had subbed then beat it into our heads - in our senior level programming languages course - that making the damn thing work takes priority over all. I guess better late than never.

My classmates and I were taught to use the most naive code possible, and then improve it immediately using patterns that abstract and generalize the problem being solved. We were taught to look for improvements that solve problems of safety and scale, we were taught to look for ways to use existing design patterns.

Those are important basic software skills to learn, but in my schooling they were never offset by a philosophy that dealt with how and when to use them, and more importantly, when not to use them.

I've personally seen in my ~20 year professional software career so far a lot of software engineering that is overly expensive by a long way because people decide to add unwarranted complexity.