Counterpoint: If an architect was thrown at building a nuclear plant (when his day job was normal commercial real estate) or asked to build biomedical systems or develop a system to generate reasonable yet playable universes for RPGs, he'd kinda struggle. Yet, because a 'software developer/engineer' is allegedly discipline of sub-specialization, we get asked to do all manner of things on the assumption 'well, it's all just software, right....?'.
The reality is you go to see the cardiologist for your heart, the neurosurgeon for nerve related surgeries, an endocrinologist when dealing with hormones or for things like thyroid (not hormones.. forget the other term...), etc. Yet we ask software developers to move from (my career as an example): Mobile communications/public safety applications -> Military simulations and training systems including simulating weather and tactical air navigation aids -> building 3D worlds and the systems that allow massive multi-user setups -> working on telephony and PBXes -> online multi-user gaming (gambling) portal -> 300K user HR web applications -> working on postal point of sale and money order handling -> working on 'nodes' (the systems used in large networks for traffic management) and network management systems -> working on 3G/4G cross-network authentication, authorization, accounting, network monitoring and support tools and porting these frameworks between operating systems...
One of the reasons we often build things less than well is that we are being thrown at way too much new stuff in a short time.
It'd be like an architect or a civil engineer being asked to build a skyscraper one day, a green eco underground complex the next day, a space X mars base the next day, and then a cruise ship and later an anti-matter reactor. It's more than a little bit of a stretch and they could never take an engineering approach (known safe practices and materials for instance... our tools and techniques change by the product, sometimes multiple times in a project).
This is a big part of why we are an immature career. We are highly adaptive but not without a reduction in important knowledge in-detail and there is rarely time to build up best-practices (most of the time, the day's best practice is next year's 'we don't do that any more').
Also:
I build a bridge that I design - I include a lot of components of known attributes and use them in standard or carefully modelled new ways.
Software: I am working on a project needing tools X, Y, Z. Updates are shipped (and can significantly change or break or subtly behave differently every time) daily or weekly. The OS platform is often updating itself. So is the software for the database. Oh, and we've just changed CM tools. And project reporting tools change quite often. And 3rd party libraries... could be totally re-written, entirely deprecated, or just left as abandonware two months down the road.
Try the equivalent of a bridge and it'll be likely to have a 'Tacoma Narrows' moment...
In fiction and RPGs, you are the nerd, so you can crack a computer that is secured, make allegedly secure wifi gear do whatever the plot needs, and know how to disable something a nutter has been planning for years in a matter of minutes. Real world is ROFLing away....