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.
1. Well, you don't need to, but it's certainly interesting.
2. People assume all the time that software development is engineering. That's what leads to clashes between management and developers; clients not understanding why you can't estimate precisely; neverending projects; etc.
It's a very important thing to understand and explain that software development is _not_ an engineering discipline -- at least not yet. We strive to make it another branch of engineering, that's why we have design patters, methodologies, etc. Engineering is usually boring, but predictable, and that's a very important property software lacks at the moment.
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.