Deciding What To Optimize
When do we put the time into optimizing code versus going with it as is?
Over optimizing can be worse than under optimizing. The main problem with over optimizing is that your development time quickly escalates to where you are never delivering, but you can also suffer from making code harder to read and even reduce performance in some environments if optimizations are too specific. For front-end code, where it will run on different browsers it is of particular concern, different operating systems, and even different CPU architectures.
Optimizing your code can take a significant time commitment. Spending hours debating the advantage of using a linked list or a binary tree over an array can be well worth it in some situations, but when you are only storing a handful of values, it just isn't worth it. Besides, when you are first building an application, there are many features that you can't be entirely sure to what extent they will be used.
When writing code, you should pay attention to creating performant code but you shouldn't obsess over it unless you are writing something that you already know has to be extremely performant, such as a library that will be used extensively in your application. Obsessing over performance comes after you have the code running.
No matter how well you think, you understand the problem space you should always plan on iterating. To decide what you need to optimize you need data. You don't have data until you have an application. Before then what have is ideas and assumption and what you need is data. The data will come from multiple sources, but without it, all of your optimization assumptions are just assumptions.
If we worked on the assumption that what is accepted as true really is true, then there would be little hope for advance. - Orville Wright
Some code optimizations can make code easier to read and maintain, but more often it is far more complex. Complex code is harder to read, harder to isolate, and harder to test all of which makes it more expensive to maintain and more difficult for you to get new hires up to speed.
A question I have seen over and over in one form or another is:
Which loop is faster?
On the surface, this seems like a valid question, after all, if we know the fastest loop why can't we use that everywhere?
Where the question breaks down is when you have different ways for a loop to be handled. So while Spidermonkey, the engine powering the JavaScript Mozilla Firefox, may process a forEach differently then V8, Google Chrome's JavaScript engine. Not only that but the implementation between versions of each JavaScript engine may and in some cases do handle the forEach differently. So now you have to compare the performance of each loop type in each of the many different JavaScript engines out there, and on top of that, you have to account for performance in different operating systems and the different CPU architecture of devices.
Not only that but what happens next week when you have a new version of one or other of the browsers? These kinds of optimizations are often problematic unless you can lock-down the environment where the code is running.