software art not software engineering?

David Heinemeier Hansson (creator of Ruby on Rails and CTO of Basecamp) in an article Computers Are Hard 

This whole self-loathing a lot of software engineers engage in is entirely unproductive and is never going to be resolved. The idea that software development is a young industry and if we just give it another 30 years of ISO compliance or whatever rigor, we’re going to arrive at a romanticized notion of engineering they have in aerospace, or elevators, or bridges… no, we’re not. This is a fundamentally different domain that requires a fundamentally different approach.

We already have many of the answers. We’re simply afraid of embracing them. For example, in traditional engineering estimates are a huge part. Things run on estimates and on critical path diagrams because that’s simply the way you build a skyscraper. You don’t get to reconfigure how the pylons go after you pour the concrete. Software development is nothing like that. Software in many ways is far closer to the creative process of writing, game making, movies. Experiences where you design the unknown and you don’t know whether it’s good or not until you see it.

Look at movie making. We’ve been making movies for a hundred years. Haven’t we figured out the creative process yet? No! We haven’t. You can take a great director, a great cast, and still make a totally shitty movie. Versus in building, largely speaking, if you take a great architect, a great engineering firm, and a great general contractor, you’re gonna arrive at a building that works. You may make minor mistakes but the basic structure is going to be sound, unless someone makes a completely negligent error. In movie making, in music, in software things fail all the time. Even when good people who know the techniques of how to build things get together and work on something, they still end up failing.

Also I loved his take on programming languages:

Yes, for a person. A programming language can be better or worse for an individual. I think they can also be better or worse on an objective level, but that discussion is almost uninteresting. The interesting discussion for me is one of personal truth.

I wonder if that can be extended to other parts of software development, or if I'm just making excuses for my seeming lack of thoroughness - like my relative skepticism about unit-level testing vs other devs looking to it as such a holy thing, or even my lean into make whenever it comes into make vs buy. I think there is a chance that some of my preferences don't scale so well; that I'm pretty good at lone wolf projects (and have ones that have survived for decades!) but some of my mojo is less good when things need to massively scale, like team-wise or across distributed systems.

It's funny that Hansoson makes so much sense to me when I really didn't enjoy briefly playing with Ruby on Rails, the "assuming everything you do is this basic CRUD operation and so can just be more of a configuration than regular coding... but I'm not sure if I really think that stance is wrong (and hard to customize when it's not a perfect fit) or just less fun.