Some good ideas here but some very important ones are missing. Before I start I feel compelled to note that the twenty second load delay is not really part of this idea, that is an anecdote and you should have spotted it much sooner. Know the code. Read it all, read every checkin/commit.
Your best point was a single word: DON’T. Don’t optimize; optimized code is less stable that simple, boring, defensive and easily maintained code. I write servers and even there I do almost no code-level optimization.
The compulsion, and that is the nicest word I can bring myself to use, to optimize even the most uncritical code, probably comes from what may be the most abhorrent and despicable practice in software: the whiteboard interview. We need to band together and refuse to do these, they are degrading and humiliating and not good metrics of our skill. They measure obliviousness. They measure our ability to concentrate under ridiculous conditions, on a medium unsuited for the work, and while being watched, which is a pressure nobody should put up with at work. The interviewer sniffs and fidgets and makes misleading suggestions. I refuse to do them.
And they are always the same: someone with no training in interviewing, annoyed at having to take time from work he is already behind, tells the candidate to write some super-dooper whiz-bang hyper-optimized screaming fast bad code. This is a junior developer’s first exposure to the industry, it’s small wonder that he thinks that’s what he should focus on. It isn’t. Stability counts much more, and stability is not achieved by breaking all the rules to make it run a tiny bit faster.
A user won’t notice if a table populates a quarter second faster; he will never forget frequent crashes that result from “clever” coding practices.
Here is my main point:
Optimization is better done at the design level than at the code level.
Shaving off a microsecond by breaking the rules with something like an early return buys nothing compared to a better architecture. Most developers simply don’t think at that level, they don’t read the entire code path, but focus on low-level speed ups while a change at the architecture level is vastly more effective.
This is what we should be learning to do, but we have learned that software architecture is a different role, while a developer’s role is to write lines.