I thought you were making the point that programming is math and engineering is not?

That isn't what I meant. More like programming is math (somewhat closer to its own field of mathematics) but it isn't usually engineering, though sometimes it is in a more abstract sense.

I'm also fine with 'software developer' especially as we've largely moved away from programming computers, and at best most of us are programming abstract machines that bear decreasing resemblance to computers.

> it isn't engineering

Consider a fuel injection system from the 1960's. It was a mechanical computer. Was that not engineering? It was certainly designed by a team of engineers.

These days, it's software that does the same thing. Why is that not engineering?

The material aspect is engineering. Is the logic engineering? Do you engineer logic? Would a mathematician think of contriving logic as engineering?

In order to discuss categories at all, you have to place some limit on how far to stretch the equivalence of different things. Sure, a physical thing is transformable to a logical thing, but doesn't that affect our categories? We're pretty bad at finding or agreeing on the lines between the categories we create, so I don't worry about that much.

I didn't say that programming is never anything like engineering. I apply engineering-inspired approaches to my work all the time. But here's another perhaps eccentric opinion: when I'm thinking like an engineer, it's usually to compensate for the code being too complicated to read. I consider that a pragmatic response to a worrying failure, not something to aspire to more of.

> Do you engineer logic?

You betcha. Think of how Woz designed a floppy disk controller that used fewer parts than other designs. That's engineering the logic.

A big part of software engineering is to engineer the logic to get the correct result as fast as possible.

> A big part of software engineering is to engineer the logic to get the correct result as fast as possible.*

Engineering is all about working within a set of constraints. Things that are easier and/or cheaper to manufacture, have clearly been engineered that way.

It can't be a coincidence that we consider CPU time and memory footprint "costs".

We consider them costs because they are. If you can execute code on your server farm 1% faster, you can save millions of dollars in server costs. Hence software engineers who work on server farm code tend to get paid very well.

Replying here because I'm becoming enraged by HN rate-limiting our perfectly civil discussion.

I definitely see where you are coming from re: 'engineering' logic. As I said before, I don't have a huge argument against this. However, for me this is where the metaphor blurs into near-meaninglessness for me. Optimization happens to be a specialization of mine, and I can't find a reason to think of it as engineering, except for the fact that I take measurements. The optimization itself is more like applied information theory. I can agree that the measurement + iteration is perhaps engineering.

For the record, I don't consider a programmer who connects up various packages designed by others as much of an engineer. A programmer who designs and codes the load managing software for an electric utility is certainly doing engineering. There's a line between the two, but it's definitely a fuzzy line.