1. We don't need to know how engineering works in real world. You need to be in a domain and work in that domain to acquire that knowledge. Knowing how to calculate stress in civil/structural engineering doesn't mean you are an engineer. You need a job. You need an internship if you were a student.

2. It is quite dumb to assume we build software in the same way that bridge is built. That's essentially what Water Fall method would do. You build the blueprint precisely, build a prototype and then build the actual bridge. I don't see why the author would assume we think we were classical engineer. I never assumed we would be using the same technique all the time.

That pretty much sums it up and is in fact quite accurate. Well put!

Well, the classical engineering domains are all pretty different anyway (electrical, structural, civil, etc). I remember my grandfather saying he thought it was ludicrous that they were all covered by a single qualification.

Building software with an engineering approach is a real thing. Not everyone subscribes to it, but doesn't mean it isn't a real thing.

For the record, I do a lot of gardening too, and building software has fuck all to do with that.

I also don't get how everyone who argues against software-as-engineering talk like buildings and bridges never fall over. They do.