Software engineer here, with an engineering background, and a wife who works in construction. We've had long discussions (and arguments) on the differences of our jobs.
Software engineering is about designing new things. Almost everything basic has been done in an open source library somewhere. In almost any job where a software engineer is hired, she has to design something that doesn't exist.
In something like construction and most forms of engineering, things that would otherwise be in a 'library' in software are already fully designed. Want to build a tower? Just copy and paste the plans from an existing structure, with a few modifications.
In fact, one of the main reasons I decided not to become an engineer is that you spend most of your time designing a 10% improvement to an existing invention, when that same time could be used to program something more visible, like a social network.
There are not many new designs in engineering; an extremely skilled engineer is someone who can manipulate an existing design into something new or improve on it. But almost every programmer is expected to modify designs, hack them, or create something new.
Look back at how far the standards have changed completely, from assembly to C to C++ to Java, JavaScript, C#, PHP, and so on. There's not a lot of code that can be recycled from 10 or 20 years ago. This is very different to say... the automotive or aeronautics industry when you can keep improving on designs from decades back.
Project management is notoriously difficult in software. Time estimates are best done by people doing the work, but when they're busy making estimates, they're not writing code. This tempts people to avoid any project management at all.
Often, a lot of code depends on specific people, and if these people are late or unable to perform, the code does not move ahead. In contrast, if you wanted to build a car, you can simply hire different people to assemble the tires, the chassis, the battery, the engine, and so on. Object oriented and existing frameworks makes this possible, but it may not be practical when you're designing everything from scratch.
Failures may be allowed in software. Testing can be costly. In software, it's very tempting to skip all that testing, when you can just fix a crash. In most forms of engineering, a 'crash' can be fatal.
You do have programming methods that use extensive testing, like extreme programming (which was actually used on software megaprojects). But with tight deadlines (that can be made tighter on purpose), it's tempting to skip all that programming and launch with bugs. The Joel Spolsky style of "always fixing all bugs" will save more time in the long run, but the undisciplined will skip this and fail.
Small projects are better. My wife once asked me to get a job in a big company. It ended up in an argument that big companies are bad companies... to her, a big company had a lot of resources, experience, functional project management, and the right procedures. To me, a big company is a dinosaur, where most of your time is spent on fixing code, testing it, and documentation.
I've seen million-dollar IT projects worked on by less than 10 people. More people would have slowed down the project and added unnecessary bureaucracy. WhatsApp is an example of a 'small' project that's worth billions of dollars. It's not that big projects aren't possible, but you simply don't need thousands of people to produce billions of dollars worth in software.