Thinking through design criteria, trying to perfect them, asking all these small questions can be a joyful, creative act in itself. I think it's great when good developers can engage in heated debate as to which is the most solid design, backing away from the desire to be buzzword compliant and come up with a solid design.
In the end, I'd rather write code people looked at and said "That's elegant" than code that people looked at and said "that's clever."
This being said, if you don't realize that all of this is a creative endeavor then things will be formalized to the point of killing that creative spark.
I do think coding standards exist for a reason, but also that they should be no longer than necessary. Indeed, one issue with writing long coding standards is that usually they are a form of premature optimization ;-)
A friend of mine described it as something like (paraphrasing, I think it was more eloquent originally): my job is using mathematics to serve [corporation], but my religion is using [corporation] to serve mathematics.
Maintainable code is elegant code. Too much emphasis on the straightest line to results results in inelegant code, full of boilerplate, which becomes progressively harder to maintain. The line between elegant reusable libraries and impenetrable abstractions, however, is a fine one, and figuring out where that line is doesn't come without engineers who are willing to experiment a bit and refactor when they were wrong. Understanding of the tools and language features that allow the creation of elegant reusable libraries doesn't come without experimenting with them. Those who don't strive to continually learn new things and grow their skills become jaded with what they are doing, and eventually end up unengaged and consequently less productive, or they go do something else instead. There's a reason that the half-life of being a software engineer is 15 years. (Assuming the 15 year half-life story is true. It sounds about right to me.)
Hence my point about design being a creative act in itself, and where a lot of the joy really is to be had. Anything can be formalized to the point of killing the creative spark, but generally a mature approach to software development, but one which recognizes the fact that not only should we not get away from programming as a creative act of design but that in fact no matter how we try we cannot do so anyway is the best approach IMO
I am not explicitly saying that you would for sure agree with him 10 years from now, but I want to at least suggest it's a possibility.
For what it's worth, I run a software company, in which I sign paychecks, and I think what is said in this posting is pretty smart.
The joy of being a professional, well paid developer is in creating the product, not the code. The joy of programming for programming's sake is something you do in your own time. Sure, any smart company will reserve work time for that, but not in the middle of building a product.
Same goes for the "healthy" opposition of a producer. If you need to be managed like that, please fuck off back to the playground, and don't dare call yourself "mature".
Most of this article reflects a "we are such special an unique snowflakes, we don't need to take responsibility for the consequences of our actions" that has become all too common in our business.
I'm all for spending truckloads of money on getting programmers the best tools and work-environment with all the nice toys, and giving them all the freedom in the world to do their job in any way they are most comfortable with. But the one thing I expect from them in return is to take responsibility for delivering results. Not to fuck around and be creative and "artistic" at the expense of those who are signing their paychecks.