Hacker News Reader

Lots of weird opinion in this statement, maybe insecurity from never getting your degree? Software has proven to automate things just as important as “real engineering” in many fields. Hospitals, power grids, entire financial systems.

As hard as CS is, I think any type of "engineering" is harder and that actual engineers are a way different breed than software engineers. Software, as a practice, is also the wild west compared to actual engineering disciplines which require licensing and have a much closer relationship to the phrase "regulations are written in blood".

"Actual" engineering might have greater stakes in terms of "blood", but I have a hard time believing they are harder.

There are equations well known for hundreds of years on how to design a bridge that doesn't collapse. And the fact that most bridges don't actually collapse is not mainly due to the ingenuity of the engineer that built it, but rather, allowing liberal margins of errors for safety. If you use materials twice as strong as the minimum requirement, things don't break if you made a 50% error in your calculations.

In fact, I'd be very concerned if "actual engineering" is hard. Given that most people are mediocre in ability ("licensing" is just about formal requirements, whether one can jump through the hoops, as opposed to actually being super smart), it's really scary if building a bridge or a building is "hard".

On the other hand, building robust yet complex software is actually hard. There's no software equivalent of "just spend more money on materials to allow for a 10000% margin of error to ensure it doesn't break". Spending more money stops working at a certain point, for example, hiring more people doesn't work, per Mythical Man Month; spending more effort on handling edge cases don't always work, because writing more code with minimal utility means an even less maintainable project in the long run. Correct code almost has to be "mathematically perfect" in order to be small, simple-as-need-be, and robust. And then even if your own code is 100% error free, you have potential bugs all the way down from frameworks, compilers, to even the CPU (eg. Spectre).

Software development definitely has one of the highest skill ceiling among the trades that I know of. Sure this doesn't apply to whoever wrote your CRUD app, but think about it -- let's say you're thinking of building a skyscraper that requires extremely difficult engineering (whatever that means) to properly build, nothing short of the most brilliant engineer would be capable of planning and executing the project, any mistakes would lead to a complete collapse of the building... would you want to proceed with this project?

Yet people start software projects like these for fun. Precisely because it doesn't necessarily have to involve "blood".

I was a "real engineer" for several years before learning to code and switching to software and found that software was harder and required a greater attention to detail, skill, depth of knowledge, and so on.

I've found that your sentiment that software engineering is less rigorous is common among those that haven't done "real engineering" though.

There is some truth that in software you have the option to push out risky code and have it fail and then course correct quickly, while in "real engineering" you can't take risks like that because there is a higher potential negative severity/outcome but that depends on the cost of software downtime and bugs.

In "real engineering" you can also develop models and test things in a safer environment before the equivalent of "pushing out to prod" but often the feedback loop is longer, and so you have more time to consider your test, but that doesn't mean that reasoning about that system is any harder, or easier necessarily.

> There is some truth that in software you have the option to push out risky code and have it fail and then course correct quickly, while in "real engineering" you can't take risks like that because there is a higher potential negative severity/outcome but that depends on the cost of software downtime and bugs.

I'm sure you could be like Albert Hofmann for Chemical Engineering, or Electroboom for EE

I, too, was a "real" engineer before transitioning into software. I think you are right with your analysis. "Real" engineering, as practised by people in the industry, is neither harder nor more rigorous than real world software engineering. I wonder where this idea comes from. I read that very often here on HN.

For me, the reason I give so much respect to Engineers is that they have a profession, a set of rules they are willing to stand up for, and not violate. The law supports them in this manner. Perhaps my respect is misplaced, I'll never know for sure.

The application of the rules and procedures reliably, every time, every day, for every little change, just seems so damned boring and yet terrifying. Knowing that if you're wrong, one or perhaps many people will die, is a strong incentive to do things right.

Take the walkway collapse caused by a seemingly small change to make construction easier[1]. Or, the institutional failure when Engineers are over-ridden by management with spread-sheets who don't actually understand the problem at hand.[2]

But... The day in, day out grind, it's so tempting to be clever and creative, and do the thing that programmers do all to often when they write code so cleaver they can't debug it. Give in to the temptation once, and someone else could die.

What a grind... It's like being an accountant with a sword dangling over your head.

Engineering is about being methodical and prudent, not about being the sharpest tool in the shed.

[1] https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse

[2] https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disas...

Why is it we always see these gatekeeping comments on every thread about software engineering? It’s as if we can’t accept that words can have different meanings and if millions of people are using a word a certain way then perhaps that meaning is also valid.

In some states, you can go to jail for calling yourself an engineer without the state licensure. Words have multiple meanings, but "Engineer" is a title, not just a word.

---

Why the gatekeeping? Because Software "Engineering" isn't really what most of those with the title are capable of doing.

Let's talk about Electrical Engineering for a moment... a typical house in the US has many circuits supplying 120 volts at 15 amps, 60 Hz. You can plug any combination of loads into any of the outlets, and, if they are installed and maintained properly, you won't damage the wiring in the walls, nor are you likely to start a fire.

This is accomplished with engineering (the design of breaker panels, outlets, etc) a strict set of rules, (the electrical code) licenses for the electricians, and state inspection of the circuits before they are put into use.

---

Programming is the wild west compared to this. You have no way to run a piece of code on a machine without risking all the data on the machine, and/or all the machines networked to it. Our hardware is sub-standard (RowHammer shouldn't ever have worked), our operating systems give everything ambient authority. It's actually less secure now than it was in 1982, when you at least had write protectable media that the OS couldn't over-ride.

There's no way to take a random executable piece of code and run it safely. There is NO ENGINEERING in software engineering. It's all band aids and bailing wire.

> There's no way to take a random executable piece of code and run it safely.

Right, because there is actual computer science theory that explains why this is difficult.

What CS theory is that?

The temptation is to cite the halting problem, but that's not it.

The Bell-LaPadula model[0] has been proven to be able to provide security, but due to historical accident, you generally can't implement it in Linux, MacOS, Linux, etc al.

The necessary CS theory was developed to make things safe in the 1970s, as I've stated, over and over in various threads here[1-4] and elsewhere on the internet[5], ad nauseum. But we, the programmers, "software engineers", hackers, whatever you want to call us, don't apply those systems, and continue to pile layer upon layer of band-aid to systems that are insecure by design.

It's like building all of your bunkers out of crates of TNT, and wonder why they keep blowing up at the first rifle shot, then concluding you need thicker walls.

[0] https://en.wikipedia.org/wiki/Bell%E2%80%93LaPadula_model

[1] https://news.ycombinator.com/item?id=36717861

[2] https://news.ycombinator.com/item?id=36652789

[3] https://news.ycombinator.com/item?id=36623992

[4] https://news.ycombinator.com/item?id=36442874

[5] https://twitter.com/mikewarot/status/1607769510542544899

Rice’s theorem. btw capabilities are cool but it’s very difficult to actually deploy them to real-world software without accidentally giving things more access than intended.

Rice's theorem can quickly prove that antivirus software is always a waste of time, so that's a plus. It can not, however, do anything to help jailbreak out of a process that has no access to the outside, no matter how evil or clever it (the code in that process) is.

Think of capabilities as cash in your wallet... fairly easy to manage, as long as you can secure the wallet.

In engineering, lives are often on the line, but there are also plenty of areas of engineering where most of the work is also band aids and balling wire. For example, lots of product design isn't safety critical and doesn't need to meet any formal standards. Maybe you don't consider that engineering because it's not rigorous enough - I certainly do though.

> It seems to me that a formal CS education is wasted on those who don't have the urge to code in their spare time, and only get into the field for the money.

It's a hell of an expensive (and difficult!) credential when, these days, it seems you can do the most plentiful && easiest && high paying dev work (web) without it.