> I know, I've made that mistake terribly before where I avoided performance until a year after a project was in flight [emphasis added] It's not about avoidin

> I know, I've made that mistake terribly before where I avoided performance until a year after a project was in flight [emphasis added] It's not about avoiding making it fast, it's about prioritizing. There's a probably apocryphal story from, I believe, The Psychology of Computer Programming (Weinberg) where a mainframe programmer opposed a new program because it wouldn't be as fast as theirs. Except their program produced garbage results, and the new one produced correct results. The priority was in the wrong place (speed) rather than the business need (correctness). There's absolutely nothing wrong with making your program fast, so long as it's not to the detriment of correctness or while avoiding making it correct. Fighting for performance boosts in your data access patterns or data layouts while still manipulating the data incorrectly is a fruitless endeavor.