The way we approach problems is the same. We are not doing research or science. We are using our judgment to pick a particular solution from a large solution space to a problem(s) that must meet different user specifications/requirements.
Don't get me wrong there are massive differences but IMO they are largely cultural and macro economic related. I'll get to this in a bit but first I want to rant about what the author misses.
The author is conflating levels of design abstraction. He sees that traditional engineering has coordinated on common engineered components for example the Bethlehem Steel plant was so prolific it became the de facto standard for steel wide flange shapes for the whole country. So the author is correct in that now since engineers aren't busy designing every single minutia of every beam like they did back in the day when there were no standards they can start from a higher complexity point and focus on more complex designs. However, software developers can do the exact same thing. Software definitely has "engineered components" we call them frameworks, libraries, modules etc. They allow us to "spin" up new tools and working concept level designs very quickly since we're not busy coding all of our data structures from scratch every single time.
I'm not going to get into his risk argument since I'm already ranting too much, am lazy and it's a complex topic but I'll just say that the ability to revert a software project back a couple months means you only really lose labor/productivity and not capital. Reverting a building or part of one back a couple of months is a nightmare scenario and on average "rework" is ~25% of a typical construction project's final cost (this includes both capital and labor costs but the point still stands).
The midcourse design change argument is flat out wrong. I've been on several large projects that never got built or were unrecognizable from beginning to the final product. There are many reasons for this but traditional engineering design software is mostly to blame since there's more flexibility now (compared to the 1960s) in how people can render buildings so as a fraction of a projects lifespan projects stay in the "development" phase much longer as opposed to the "building" phase which means designers can change A LOT of the project before they need to get buy in from all construction parties and agree on what they're all building. This is one reason among many why construction productivity has gone down and costs have gone up.
Alright so what are the biggest differences between traditional engineering and software development? IMO the macro economic moment means that software is higher reward financially which means that software developers have TONS of room to grow in their field either technically, managerially, operationally, professionally etc. There's A LOT of choice and room on where you can take your software development career. This is not so on the traditional engineering side of things. There is limited growth so many many firms are top heavy and put in de facto brakes, check boxes and licensure requirements on the career ladder since there simply isn't enough room for the new incoming grad class every year. It's essentially a pyramid scheme. This makes the work culture very traditional, stagnant, and risk averse. Nobody wants to fall out of line because they can be replaced. There aren't interesting niches to explore or exploit since everything is very full and competitive.
The growth in software allows developers the breathing room to sharpen their skills and generally the culture in software really encourages this self improvement. Not so in traditional engineering. Gaining productivity in some new skill means rocking the boat and challenging orthodoxy. The margins are already slim and the boss really needs the reliable bonus he's been depending on so why take a chance on something new? Just wait your turn in line like he did.
Allowing developers the time to build technical skill means there's incentive for employers with larger margins to leverage those skills. So developers get more responsibility this is a virtuous cycle which leads to faster career growth. IMO junior devs get much more responsibility earlier in their career than their traditional engineering counterparts.
My take is on the pessimistic side but I can't in good faith encourage a smart, ambitious, technical/analytical person to go into the traditional engineering disciplines. EE/CS as far as I can tell is still the best route.