I'm actually surprised that anyone could disagree with the OP, other than to nitpick. I found most of what he said to be so obviously true as to go without even saying.
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.)
"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."
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
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.)