Exactly. It's hilarious to imagine management coming to a dev with a problem and a set of objectives and the dev replying mockingly "What are we some kind of special snowflake that we have to satisfy a different set of requirements than an off-the-shelf solution can satisfy?".

Every structure and bridge and road and tunnel project is obviously unique also. Unique terrain, unique architecture, unique engineering. If the idea is to look to other engineering to improve this, again, it's not like software is some kind of special.

They're only unique in trivial ways. Roads are made of the same material everywhere - they're different only in some strict geometric sense.

Meanwhile even very ambitious tunnelling projects like the Gotthard Base Tunnel, if you watch documentaries about them, they only hit a very small number of really unexpected issues even over long periods of time. Tunnelling is an incredibly predictable business. You buy some TBMs, set them going and worst case, you hit unexpected rock types or have an unexpected malfunction. The technology is advanced but rock is the same as rock has always been. Once the project planning is over requirements don't change. The course you're on doesn't change. Workers are largely trainable and replaceable - you never find you're unexpectedly relying on some random worker somewhere deep in the org chart who is 50x more skilled than their coworkers and who just got poached by a company that pays 3x as much as you can. The users/customers have no input: they get what you deliver and a tunnel is such a simple thing talking about whether they like it or not is a nonsensical question - it's a tunnel.

> They're only unique in trivial ways. Roads are made of the same material everywhere - they're different only in some strict geometric sense.

That's about as accurate as saying that software projects are only unique in trivial ways because there's probably already a free library or plugin that can do whatever else you need. It's easy to assume your occupation is much harder than everyone else's but we rarely have deep knowledge of the challenges other people face day to day outside of our own line of work.

As a simplified example, the design of a road, its pavement layers and its foundation is determined by factors like traffic loading characteristics, service requirements (peak capacity), speed limits and visibility, ground conditions, climate and more (see Caltrans' Highway Design Manual at http://www.dot.ca.gov/design/manuals/hdm.html), many of which rely on professionals in entirely other fields.

As kaspy points out in his, this is just more software engineering hubris playing out. I took architectural drafting classes in high school, and there are tons of technical differences and considerations that go into building design. And I was only dealing with drawing them, forget about having to have all that in my head and actually being able to make decisions on it.

To make what I hope is an apt analogy back to software, you are basically saying, "Oh, their job is easy. All they have to do is follow established design patterns!" But, of course, we also have design patterns... Why don't we say the same thing about ourselves? Because we know that that's complete bullshit; there's a lot of thought and wisdom that goes into actually building stuff around those patterns.

Yes, but architecture isn't the same thing as road building where the same small set of variables play out repeatedly over centuries. The work an architect does is much closer to the work software engineers do.