Re:The Fallacy of Premature Optimization
by hinkley on Monday October 31, 2022 @12:51PM
(#33408594)
Optimization gets treated a lot like AI: When we find a concrete use for some facility of it, we give it is own name and disassociate it with the source.
What once was Optimization gets called Information Architecture, Capacity Planning, and so on, and all of these things should be done as soon in the project as possible.
> IMHO, a big thing for junior programmers to unlearn is that one should begin by putting a sloppy version of the program in production
This is the closest we've gotten to a Just Do It mantra but we have a lot of space for improvement. An instructor can't help you get better at public speaking if you won't speak at all until you can speak well. However once you can speak well you shouldn't rush important speeches because you can't walk some things back once they're out there.
We will always have a steady stream of brand new developers who need simple rules of thumb, but some senior developers never grow out of it. What I see is a lot of these aphorisms being used as a way to censor others who might be suggesting work in the "hard but valuable" quadrant of cost vs value.
At some point in my career I got so fed up with coworkers trying to go against business needs (customers are complaining about responsiveness) by shaming coworkers into not touching performance and essentially running a work slowdown, that I began identifying types of code refactoring that improve clarity and speed. Sometimes what confuses the developer confuses the compiler. Particularly in the realm of strength reduction.
What once was Optimization gets called Information Architecture, Capacity Planning, and so on, and all of these things should be done as soon in the project as possible.
> IMHO, a big thing for junior programmers to unlearn is that one should begin by putting a sloppy version of the program in production
This is the closest we've gotten to a Just Do It mantra but we have a lot of space for improvement. An instructor can't help you get better at public speaking if you won't speak at all until you can speak well. However once you can speak well you shouldn't rush important speeches because you can't walk some things back once they're out there.
We will always have a steady stream of brand new developers who need simple rules of thumb, but some senior developers never grow out of it. What I see is a lot of these aphorisms being used as a way to censor others who might be suggesting work in the "hard but valuable" quadrant of cost vs value.
At some point in my career I got so fed up with coworkers trying to go against business needs (customers are complaining about responsiveness) by shaming coworkers into not touching performance and essentially running a work slowdown, that I began identifying types of code refactoring that improve clarity and speed. Sometimes what confuses the developer confuses the compiler. Particularly in the realm of strength reduction.