Coming from Real Engineering and making 2x more programming, I lol at people who say there is any Engineering in software.

We are programmers dealing with layers upon layers of abstraction. Knowing to optimize for time by using vectors is more of an art, than a science.

I did do safety critical C code and Assembly which are probably my hole in the whole 'its not engineering'. But javascript/python/backend work: programming.

It's just a job title, arguably one without the protections or standards afforded to chartered engineers, and with an incredibly low barrier to entry. Pretty much the reason we have to do this ridiculous dance with tech tests, LeetCode, and 12 stage interview processes.

Exactly my point.

The strong consensus was that software is an engineering discipline, and the nitpicking you can have on any particular topic that is/isn't engineering-y can be applied across the board.

But this conversation is totally moot IMO because if you have a bachelors in computer science or software engineering, and a masters in the same discipline, and several years experience, you can apply and become the same chartered engineer from the same association that does "real" engineering.

I see it as a difference in time and stakes.

We’ve built bridges and boats for thousands of years, where the outcome of failure is people die.

This has a lot to do with why it’s easy to estimate the time and cost to build a house, but it’s a rare shaman who can consistently estimate software projects well.

Once we’ve built software for even a few hundred years, we’ll probably have it pretty dialed in, too.

We write software that has killed people due to bugs too, such as Therac-25 releasing too much beta radiation killing patients.

> This has a lot to do with why it’s easy to estimate the time and cost to build a house

My parents and in-laws are property developers and I've also been involved in a build; not one was on time or budget. Some are really off budget, beyond the scale software projects that mess up are. In China they've had projects run into the billions and be decades late.

I do understand your points, but this is what I mean when I say you can nitpick any issue with software not being Real Engineering and apply it to other engineering categories too.

But yeah we may have a very different process in 50 or 100 years. I'm only 10 years into my career and it's already pretty different to when I started!

One related problem I see is that Computer Science tends to be under-estimated by other engineering fields. A ton of software engineers did not study software. They learned to program as part of their engineering studies, and they believe that they learned both Computer Science and their engineering topic at the same time.

I may be biased, but I see fewer computer scientists pretend to be mechanical engineers because they once tuned a PID.

If Bachelor of Science computer science grads were that much more extraordinary, they wouldnt be working side by side with non-degreed programmers.

Chem Engineer here, I wrote random forest once. My coworker with a CS degree, all front end work.

There definitely is. Safety/mission critical code is definately a more rigorous, formal process where you don't just download a library for padding a string (you probably wouldn't use built-in strings anyway on this kind of code).

But I agree that the way most coding works (i.e. move fast and fail often) is completely antithetical to how engineers should work. But there's infinite moneys and almost zero accountability, so who's gonna stop them?

>Knowing to optimize for time by using vectors is more of an art, than a science.

that's definitely why I fully agree with calling programmers creatives over engineers. once you get past dead simple problems, no two programmers are going to approach a prompt the exact same way. performance, scalabiliy, documenting, version control friendliness, even ephemeral stuff like code style. coders very much are artists who happen to know a lot of math.

It is a downgrade in my opinion.

Most programming work needs common sense a lot more than it needs theoretical algorithmic knowledge.

And almost nobody values good documentation, especially as a competetive advantage.

FWIW I think LeetCode problems can make sense for some businesses, but most not.