Rules of optimization
&gt; <i>But if performance work has been neglected for most of the product development cycle, chances are that when you finally fire up the profiler it’ll be a uniformly slow mess with deep systemic issues.</i><p>Totally true, and I have observed it IRL on large, old projects whose architecture was hostile to performance. And these products were doing computationally intense stuff.<p>&gt; <i>Performance is everyone’s responsibility and it needs to be part of the process along the way.</i><p>Yes.<p>Everyone repeats &quot;only optimize after profiling&quot;. It&#x27;s true: if your program is running too slowly, you should always profile. But that rule only applies when your code is already slow. It doesn&#x27;t actually say anything about the rest of the development process.<p>Developers should have a solid grasp of computer hardware, compilers, interpreters, operating systems, and architecture of high performance software. Obliviousness to these is the source of performance-hostile program designs. If you know these things, you will write better performing code without consciously thinking about it.<p>If this knowledge is weighed more heavily in the software dev community, people will put in the effort to learn it. It&#x27;s not that complicated. If the average dev replaced half of their effort learning languages, libraries, and design patterns with effort learning these fundamentals, the field would be in a much better place.