3 ms·

Early in my career I heard just such advice from a guy I respected as a big success in his field. A couple of years later, when his code started taking down ot

Early in my career I heard just such advice from a guy I respected as a big success in his field. A couple of years later, when his code started taking down other actors in the ecosystem, it became my job for a while to replace his modules with my own implementations that were more efficient. Sometimes by a factor of 1000. Literally. Doing it right the first time would have only taken a fraction of the effort it took in the end (assuming you have the proficiency to do so). I find dismissive comments about efficiency troubling.

qwertyuiop924 10y ago
There is a difference between doing the right thing for efficiency, and going out of your way to make things as fast as possible. Storing 1k entries in an O(n) datastructure is an example of not doing the former, and using your language's built-in hashmap type, instead of implementing your own, using domain-specific knowledge to optimize it within an inch of life, is an example of the ladder. Don't write code you know will be too slow, but don't optimize the code just because you can. By the same token, if you find out that your code is too slow, it's your job to optimize it. Take performance seriously, but don't optimize before you know why you're optimizing.