There might be some confusion of terminology at work here. I tend to agree with the article that you have to think about performance while designing your progra

There might be some confusion of terminology at work here. I tend to agree with the article that you have to think about performance while designing your program, but that is not a contradiction to what Knuth is saying. Knuth talks about optimization, which is a trade-off to make your existing code faster by sacrificing readability. This guy talks about proper design, which is a trade-off between time to market and quality. You can (and should!) have both. Think about what you do before you do it, and then optimize the parts that need more work. BTW: I think there might also be a misunderstanding about why optimization can be bad. djb used to say "profile, don't speculate". I think this is the core of the Knuth recommendation as well. If you optimize before you have written all the code, chances are you don't even fully understand the problem the code is trying to solve yet, so you might have to rewrite parts of it, and then it would suck if you had sunk a few months into optimizing those parts. Also, only after you have all the code and you have test cases do you have an opportunity to profile and find out which parts of your code are contributing the most to its lack of performance. The fundamental insight here is called Amdahl's Law. Or maybe you find out that your code is already fast enough. I usually spend a ton of time beforehand thinking about how to write code that will not need much optimization later, but sometimes you find out your initial assumptions were wrong.