Funny we don't have a category for best practices and architecture.
"In this sense, we should continually be striving to transform every art into a science: in the process, we advance the art."
Donald Knuth said the above.
He also said this:
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
By using mdot it is not just a speed saving, but a way to prevent simple stupid errors often caused by those who think themselves experts. Knuth also said it's good to take speed that is easily had.
What Hoare and Knuth are really saying is that software engineers should worry about other issues (such as good algorithm design and good implementations of those algorithms) before they worry about micro-optimizations such as how many CPU cycles a particular statement consumes.
That's truem but I have a substantial library of reusable code so I can think about the good design and then deliver it very quickly. The routines are fast and I don't think about insignificant optimization as some accuse.
https://ubiquity.acm.org/article.cfm?id=1513451I also have techniques which make for very fast construction and very fast execution. I prefer my tables be event logs. As of such and such date, the price of a product is x. Then always determine the current price as of now. A new price change is a simple new record, no edits, no contention, just simple and clean.
I also use a serialized GUID. Oooooh. It's guessable! That's not right. But an integer key - which is not just guessable, but knowable, is ok? Stupid arguments like that are everywhere.
Let's advance from using crude sticks and paint to make "art" and progress to science and architecture.
