You and I know this because we did not learn big-O notation to express algorithm efficiency. Instead we learned to think about loops, nesting of loops, what dri

You and I know this because we did not learn big-O notation to express algorithm efficiency. Instead we learned to think about loops, nesting of loops, what drives the number of loop iterations (per customer, per stock item, per character, per pixel) and we also learned to think about minimizing the work done in loops. Unfortunately many modern developers do not go beyond big O notation, which in many cases is totally irrelevant because they are talking about memory accesses which are light years faster than disk. Actually, it is also useful these days to thing of whether work is done all in registers, all in L1 cache, all in L2 cache, all in RAM, all in disk cache(a form of RAM), all in disk interface cache(RAM on the hard drive controller), disk, or somewhere across a network connection which could be in the data center, across town, across the country or across the world. It would be useful if training courses moved that big-O stuff off the the sidelines as a little historical note because it really is a theoretical analysis of algorithms, all things being equal. But in the real world, all things are NOT equal. Similarly the issues around threading an locks on mutable state which can consume 50% or more of CPU time on a modern processer when an developer tries to roll their own multithreading. Immutable state and interthread queues are the only way to go, and the best way to do it is to explicitly design around the actor model.