As I like to say, if the construction world could tweak a $CEILING_HEIGHT parameter and hit the big "REBUILD HOTEL" button, and the entire hotel would systematically tear itself down and rebuild itself from scratch in about 5 minutes for a net cost of $5, and then run a large set of automated checks for code compliance, making sure the doors don't conflict with each other, etc. in the next five minutes, and spit out a report of all the results, you'd expect them to operate differently. VERY differently.

Coding is 100% an engineering endeavor. And just like any other one, a particular project may not be following engineering best practices and that project may be producing some dangerous garbage as a result, but I'm actually fairly satisfied with my engineering practices, as engineering practices, what with my automated testing, automated acceptance criteria, automated security checking, automated style checking, integrated peer-review practices, performance testing practices, engineering for redundancy and resiliance. If $YOU're thinking the coding world is awfully cowboy maybe that's a sign that $YOU need to up your game with the already-existing and well-documented best practices in our industry. To be honest most other "real engineers" would be green with envy at what we have available to us!

I know a few civil engineers and have been surprised at how many similarities that work has to software engineering. Some of the poor practices that people gripe about in tech are similar in that world, and the same goes for many good practices.

There are meaningful ways in which software interacts with the physical world.

Latency is the first to come to mind. The realities of how systems are designed and how permanent the storage in question is translate to latency and thus frequently performance bottlenecks.

Data durability is another thing to consider. Though frequently that's mostly abstracted away in the lower layers of hardware, system composition, and operating system / file system / libraries generally.

Limitations also exist in raw hardware performance (state machine speed, how parallel the computation can be, how parallel the desired process can be made) and capacity, for processing, temporary memory (RAM), and long term storage. Thermal considerations might also be a factor, but those are usually managed by lower layers and present as capacity limitations to typical software.

Software as a domain for achieving goals does offer an unusually wide degree of flexibility in approach. Today we also stand on the shoulders of many giants, with relatively easy access to extremely powerful systems that can obscure many sins for 'reasonable' workloads.

Fascinating, thanks for posting that, I know what I'm reading this weekend!

I mean that seems like a methodology that would run a heavy risk of sampling bias. This is literally people who have chosen to switch to software engineering, and who are currently software engineers.

The only way to make the sample better would be to also sample people who moved the other direction, but there haven't been nearly as many of those because software engineering jobs have been in much higher demand than other engineering positions.

What you certainly cannot do is sample people who have only experienced one field.

But yes, it's not meant to be a quantitative study, but there are a lot of very valuable insights in the blog posts.

You have to consider, most engineering disciplines learn how to program, but almost no one in a software engineering program learns how to design stuff.

And the jump from building academic programs in C/Matlab to building commercial software products is much smaller than the jump from having never used Fusion 360 to designing a commercial product.

Plus, there are many more resources out there for switching careers into software engineering. With CAD, you're kind of stuck with YouTube videos and the odd online course for foundational material.