Hacker News Reader

Comment by dekhn | Hacker News Reader

I'm a hacker, always have been. Took a detour to be a PhD scientist, and another one to be a "software engineer", but I'm a hacker. And this hacker can tell you: most (95%) of software "engineering" is not engineering, but more or less the equivalent of telling anecdotes about your grandparents experiences while arguing you have a solution to covid.

That said, there's 5% of software engineering out there that is engineering; read the RISKS mailing list archives if you want to see some examples (and counterexamples).

If software engineers were engineers, testing would be a higher priority, and visible regressions would happen rarely, if at all.

View on HN

> If software engineers were engineers, testing would be a higher priority, and visible regressions would happen rarely, if at all.

That would mean they were doing their jobs badly. All engineering requires balancing priorities such as physical strength (or in software, correctness), and cost. An engineer who overbuilds everything 10x will quickly be out of work.

When correctness matters less than business results, then your role has passed from engineering into business. Software is somewhere in the middle. Software engineers are often informally expected to own the results without owning the profits.

Cost is an important constraint in engineering. Nearly every engineering project has cost as a component of the engineering process as omitting it yields projects that cannot be completed.

If you could create and patch buildings incrementally like software, you don't think people would do that?

Correctness in itself is not a meaningful goal. If something works well enough to meet the needs of the user, being more 'correct' doesn't necessarily provide more benefit.

Buildings have been created and patched incrementally for millennia.

It's one of the things that Engineers got pretty good at, because people died over and over.

> If software engineers were engineers, testing would be a higher priority, and visible regressions would happen rarely, if at all.

You say that as if software engineers determine the priorities ...

The difference between a "software engineer" and a real engineer like a civil engineer is that when a manager type tells a civil engineer to ignore safety or standards for profit reasons, a civil engineer gets to tell them to fuck off

You, as a software engineer, should also tell your manager to fuck off if they are making bad decisions. No one is inherently above you. If they're the kind of management to never listen to you then that doesn't make you less of an engineer, that makes them shitty managers to ignore these important principals behind their systems

You get fired the real engineer doesn't. You are paid to do what management tells you.

Language and phrasing is of course important. I have disagreed with my management on many occasions and I have never been fired.

Many companies have a culture of continuous deployment that often means "bugs happen, its part of life around here". You would go against the whole mantra of the company and industry. Not easy to tell the boss to fuck off.

It’s even more strict than that. A non-engineer is not allowed to be a supervisor of a civil engineer. This is why civil engineers work in a firm structure: the entire chain of command is made up of civil engineers. Any company who wants engineering work done must contract with a firm. This makes any potential conflicts of interest external rather than internal.

This is also why most defense companies are run almost entirely by engineers. Even though they're not required to be, they organize themselves that way to ensure a culture of design excellence. It's better to fail to deliver a product than to deliver a product that will kill people.

> defense companies ... than to deliver a product that will kill people

Isn't that the point?

Most products defense companies produce are to prevent people from dying or to do completely tangential tasks.

Boeing and their famous 737 max screwup where run by engineers with solid work and engineering ethic ?

The decision to sell a safety feature as an optional extra was pushed by bean counters.

Is this what went wrong at Boeing? Also, how is Tesla structured? Are software engineers working on autopilot functionality managed by true engineers?

Boeing ended up getting run by bean counters with the eventual expected results where the bean counters wanted to charge for a safety feature. Magically, the planes with the safety feature (every single plane sold to USA, Canada, and EU based airlines) had no issues. The ones sold to nations where they were trying to save money, had the issues that we all know of today.

As for how Tesla is structured, well it's Musk at the top who delegates everything and spends his time on Twitter trying to boost the stock price to hit his quarterly stock price goals. As for if they're managed by engineers, I have no clue.

> If software engineers were engineers, testing would be a higher priority

Many classes of engineers don't have the chance to test their designs. They have to know it will work ahead of time. The closest analogy in CE/CS might be formal methods, which (as I suspect you would agree) are sorely under-utilized.

Those engineers use tests, their tests just don't operate on "full real systems".

In fact we would be using a lot more simulators.

> If software engineers were engineers, testing would be a higher priority

testing is not that important for a hacker but important for an engineer (although hackers do penetration testing).

Reply on news.ycombinator.com