Nice, haven't seen "engineering" elitism since university. Software is the nervous system of a business. Everything from accounting, to payroll, to inventory tracking, to sales, to marketing, to communications, is achieved in today's world by interfacing with dozens if not hundreds of software programs and systems. Impossible to achieve with hardware alone obviously, you need operating systems, you need data centers, need custom dashboards and BI, you need ACH/SWIFT routing interfaces to make payments go through, you need file management, you need chat software to communicate with employees and customers, you need software nearly every step of the way. It's complex as hell. And the complexity of making all those systems work together just compounds that complexity.

As a software engineer, software "engineering" is a joke, at least in the sense we apply that term to other disciplines of engineering. It's not like all that complexity you mentioned is understood. It's worked around, and then the workaround is taken for granted and exists in perpetuity because nobody can discern why it was done in the first place. Watching a mechanical or electrical engineer be able to predict the performance of a design in a hypothetical scenario and then have that prediction largely reflect reality in later testing is pretty enlightening. These types of things generally don't happen in non-trivial software systems largely because software "engineers" don't really care. Formal methods for verifying correctness is something we've decided isn't worth it. Formally verified operating systems like seL4, and languages that lend themselves to formal verification like Ada/SPARK, are nothing more than oddities for most software engineers; the only places that bother with this are hard engineering firms that are trying to live up to do-or-die performance guarantees.

Additionally, the minimum knowledge required to be a "good" software engineer is significantly lower than the amount required to be a "good" electrical engineer. You are not pushing any limits without an expansive understanding of mathematics, multiple opportunities to work on some very expensive shit, and an employer that's actually pushing something forward. Getting a VLSI/radio electronics/DSP/etc. engineer online is a process that takes years before that engineer doesn't need constant input to keep them from shitting the bed. Unless you're so passionate about it that you can't possibly bring yourself to do anything else, you would have to be insane to go through the amount of learning required so you can pull a salary that will only slightly top an entry-level software development job.

None of this is to say that software development isn't valuable, or that the people that are doing aren't skilled, but as an industry, we don't hold ourselves to anywhere near the standard that other disciplines do, and there's not much to gain other than saving face by not admitting it.

You comment a lot about calculating performance, but this is not engineering.

Engineering is about suiting the needs to the means. In the realm of widely-used webapps, the need is 1. speed to market, 2. features and 3. maybe stability against errors 4. if successful, scalability.

And our engineering is perfectly successful for that. We are able to output features after features, we’ve factorized the boilerplate, and we publish our apps before they’re even ready.

Scalability predictions from a software developer need to be taken with a grain of salt. There is no universal law determining it. The prediction is sound up until it runs into somebody else's fuckup, at which point it becomes worthless.

The idea that most software engineers can make any real guarantees about the correctness of their programs is laughable. At least once a month we hear about a massive new vulnerability that proves that that just isn't true. To not accept it is hubris.

It's not about calculating performance. It's about proving that something fundamentally fits in with everything we know about the world. Software developers that approach their work with this mindset are exceedingly rare, and their work is largely academic.

They are discussing the difference between engineers that have to toil with the rules of the universe, and engineers who have to toil with rules that they make themselves.

Software does exactly what you tell it. Hardware does what you tell it, but it always listens to mother nature first.

Disagree. The impression I've got when talking to friends in traditional engineering is that the scope of a software role is larger (More vertically integrated, more expectations) and we have better processes (E.g. code review, deployment pipeline, monitoring, etc).

Cannot speak for EE, but I'm friends with people who do ChemE, MechE, Civil and mechatronics.

Most of that is software glue, and not particularly challenging. It's necessary to run a modern company to have this kind of glue to connect systems together, but at the same time EE and ChemE are much more challenging.

Consider that the space shuttle was considered one of the most complex projects in history with around 1 million parts. 1 million loc projects are common, a large tech company like google likely has billions of loc.

Putting all of this together sensibly is hard.

A line of code isn't really equivalent to a physical part of a space shuttle.

Why not? A simple one line change recently brought down CloudFlare. And least you think that's not important, a one line change to code brought down most of AT&T's phone network in 1990 (think 911).

Compare the amount of effort that goes into both design and production of a physical part and a line of code.

A single physical part generally has many, many inputs and outputs (expressed as its physical contact surfaces, tolerances, forces and stresses of all possible kinds from all directions they are supposed to withstand, etc., all with the added dimension of time) compared to a line of code or even a function. You cannot design a 'functionally pure' part, or design a part that creates itself for every discrete 'use'. And unlike a line of code, it can't be quickly replaced so you must get it right. And if you get it wrong, people may die in this particular example. Etc.

And that's before we become concerned with actual production of that part, whereas all you need for to write a line of code is a text editor or pen and paper.

Software has analogous constraints, with regards to scale, performance, latency, design, etc. Everyone thinks that a line of code can be quickly replaced. On a small program, this is true. But at scale, this is not true at all and anyone that's worked on a multi-million line application knows this. You cannot have every line of a complex system in your head at once. You cannot instantly solve for all of the interconnecting pieces in your mind at once. It takes a team of software engineers of various disciplines to consider the tradeoffs of any change to these complex systems. In particular when they are live and supporting millions to billions of users. And because software has more of an organic quality than traditional hardware, managing hundreds or thousands of changes that need to go into the system over the course of a month or quarter is non-trivial. People that think software is trivial are the same ones that fall for the idea that anything can be quickly refactored and redesigned and nothing will break and everything will go smoothly. It's just not true.

Most human beings can handle, at most, 5 to 9 variables in their head at once. Software systems grow to immense complexity of thousands to millions of variables, with various runtimes, databases, caching layers, frameworks, libraries, coding styles accrued over multiple decades in some cases, data aggregation pipelines, dozens to hundreds of APIs with their own unique interfaces, etc. It is a constant battle against entropy, which happens inevitably in such systems.

Meanwhile, there isn't a single modern "real engineer" who doesn't get their daily work done thanks to multiple software programs supporting their own productivity so much that they can replace what used to be teams of dozens to hundreds of assistants, techs, engineers, and other various human support systems. They draw lines on AutoCAD that automatically compute moments of inertia, shaft calcs, bill of materials, etc. Then they take that file output and zap it over Slack instantly to their colleague who works from home hundreds of miles away to get their feedback on it. Behind all of that is a team of software engineers and product devs that not only has to understand the constraints of their own technical systems, but the technical needs of their engineering clientele.

I'm not arguing EE is better than SE or otherwise. My point is specifically that EE has both more complexity and stricter constraints, and both unavoidable due to the nature of it being mechanical as opposed to ideal. Yes, in SE you also have complexity, but you can abstract it away with many tricks like isolating side effects and writing pure functions that are easy to reason, re-running from clean slate at will at little cost or even running your code anew at every request, letting things fail completely and be sure it's cleaned up reliably, etc. In EE, you have enormous implicit state that you can't ignore, the global of time and everything else all at once you must juggle.

Single line of code is single line of code. Physical part might have multiple lines of code defining it. Let's take something relatively simple like bracket. Now gather together all the dimensions, angles, hole dimensions, material specifications of it and treat all of those as their individual lines of code.