>Funny we don't have a category for best practices and architecture.

And we probably should.

I'm not gonna step into that mdot discussion, I've no dog in that race, but I would disagree with your post title. Good programming IS an art in that one is trying to take an idea and convert it into a tangible thing.

Beyond that, we want our screens/pages to look good, be pleasing to the eye and easy to work with. That's why it's called 'style'.
We want our code to be readable and easy for someone else to understand, hence all the arguments over the years of camelCase, type prefixing , etc. We talk of 'ugly' code, using the same descriptors as many people use when looking at art. I'm not a fan of abstract art, but many people are, and I firmly believe most 4 year olds can produce better 'art' but that doesn't make them crappy artists. They ARE artists regardless of my opinion.


>
>"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=1513451
>
>I 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.