There is a 4 and 5. 4) Realizing that there is a Big O around the larger architecture and thinking it is always important 5) Realizing that archecture is dete

There is a 4 and 5. 4) Realizing that there is a Big O around the larger architecture and thinking it is always important 5) Realizing that archecture is determined by the problem space, so addressing the problem itself as directly as possible will converge on optimal Big O Once you've done it over and over for years it becomes more clear how Big O just reflects the assumptions, and fighting it at the terminating point of the specific algorithms and data is a thing to defer until an easy win is needed. The only effort greenfield code deserves for optimization, OTOH, is to quickly review the language's built-in structures, and pick the one that is approximately best. Push the features, then as time permits build profiling mechanisms to find the hotspots as the system gets production data.