This article is terrible, just full of straw man arguments and holier-than-thou attitude. Meanwhile, the article completely fails to present any data, completely fails to identify why organizations fail to optimize, and completely fails to provide any solutions. The article basically just pretends there's some large anti-optimization movement so he can knock it down. And even while proving the obvious (that optimization is important), the article uses appeals to authority rather than actual data. Ugh.
> Today, it is not at all uncommon for software engineers to extend this maxim to "you should never optimize your code!" Funny, you don't hear too many computer application users making such statements.
Funny, you don't hear too many computer application users asking for optimization, either. The rare, high-profile cases where people complain that something is slow get a lot of attention, but the majority of the time, the feedback you get from users is a resounding silence. I wish users would give me unsolicited actionable feedback on my software, but the reality is, it takes effort to get feedback, and usually people don't complain about performance, they just have a general feeling of malaise about the software that doesn't rise to the level of an explicit complaint. In 11 years of software development, I've had only a handful of users ever complain about performance. The times I've optimized are almost always a result of performance logging. Performance logging lets me say to stakeholders, "This DB query is taking a full second, and 30% of users are exiting the application on that screen--can I spend time to optimize this?"
Funny, you don't actually hear too many software engineers actually saying "you should never optimize your code", either.
I stopped reading at the "observations" section, which were just too full of cringe.
I skimmed the rest, though, and noticed that the author's suggests a few books on assembly language. Good call, guy, I'll be sure to tie my application to a specific processor architecture so I can make it extra difficult to understand why memory is getting thrashed or thread switches are happening at such inopportune times.
> Today, it is not at all uncommon for software engineers to extend this maxim to "you should never optimize your code!" Funny, you don't hear too many computer application users making such statements.
Funny, you don't hear too many computer application users asking for optimization, either. The rare, high-profile cases where people complain that something is slow get a lot of attention, but the majority of the time, the feedback you get from users is a resounding silence. I wish users would give me unsolicited actionable feedback on my software, but the reality is, it takes effort to get feedback, and usually people don't complain about performance, they just have a general feeling of malaise about the software that doesn't rise to the level of an explicit complaint. In 11 years of software development, I've had only a handful of users ever complain about performance. The times I've optimized are almost always a result of performance logging. Performance logging lets me say to stakeholders, "This DB query is taking a full second, and 30% of users are exiting the application on that screen--can I spend time to optimize this?"
Funny, you don't actually hear too many software engineers actually saying "you should never optimize your code", either.
I stopped reading at the "observations" section, which were just too full of cringe.
I skimmed the rest, though, and noticed that the author's suggests a few books on assembly language. Good call, guy, I'll be sure to tie my application to a specific processor architecture so I can make it extra difficult to understand why memory is getting thrashed or thread switches are happening at such inopportune times.