I think they underestimate the value of specific knowledge. A builder that can build X meters of wall every day van do that reasonably independent of the building site. X will of course vary when you give a new kind of stones. The problem with programming is every job has its own kind of stones.
>I think they underestimate the value of specific knowledge
This is the crux of the issue. When it comes to "Knowledge Work" almost every step sooner or later becomes a specialization. For example, I used to sneer at the role of a "Build Engineer" until i was forced to take up that role in one project. The combination of HW Platforms, OS versions, config switches, build flags, magic incantations etc. quickly gave me a new found respect for a job which i had considered "trivial".
It is that one tends to underestimate the complexity involved in a particular job which has evolved well beyond its initial "trivial" requirements. Hence the need to guard consciously against such tendencies particularly in domains where you may not be competent.
I find that doesn't really capture the difference. In programming, the building part is fully automated. You press play or type a compile command and wait. If someone wants a build estimate, you should give them the time it takes to compile an deploy. Code is blueprint. Writing the code is all engineering, R&D, design and architecture and it usually entails figuring out how the system will interface with countless protocols, legacy systems, details of user's lives etc. It's nothing like building something that is already fully planned. It's a lot more like researching and planning all the details.
