You are acting as if there is no component of artistry in other engineering fields, but this is simply not true (though I admit it may not be readily apparent to the casual observer).

Agreed. For instance, I designed my first circuit board recently. Routing connections on several layers between electrical components is more of an art than anything else (though some logicial constraints apply and have to be watched out for all the time). Coincidentally I felt it's something I will not want to do again, because a less technical person could just as well do it in their less expensive time. It's like how I'm not comfortable spending time coding (simple) websites or user interfaces.

In programming, you may never use that stuff at all. Sure, I've used some dot/cross product, plane equation, etc. in my game development, but in my professional experience (business apps) I've never used more than basic arithmetic.

Actually you can model quite easily and very efficiently with math in programming regardless of what you are doing, you can easily make your entire application a collection of mathematical equations. Then again you can model anything, math can be applied to everything and be useful too. Computers are really powerful calculators and everything you see or do has some math behind it, making it easier to apply regardless of the project and it can actually be a fun way to move away from the traditional 'physics / engineering / finance' approach to calculus.

Play around with an OO functional language focusing on equations for a while and you will probably quickly find many ways you can apply calculus to your business apps and almost all the areas wont be obvious either.

In programming, you may never use that stuff at all. Sure, I've used some dot/cross product, plane equation, etc. in my game development, but in my professional experience (business apps) I've never used more than basic arithmetic.

Actually you can model quite easily and very efficiently with math in programming regardless of what you are doing, you can easily make your entire application a collection of mathematical equations. Then again you can model anything, math can be applied to everything and be useful too. Computers are really powerful calculators and everything you see or do has some math behind it, making it easier to apply regardless of the project and it can actually be a fun way to move away from the traditional 'physics / engineering / finance' approach to calculus.

Play around with an OO functional language focusing on equations for a while and you will probably quickly find many ways you can apply calculus to your business apps and almost all the areas wont be obvious either.

reminds me of something that came up a while ago, and became a point of contention:

as I see it, computers don't run on math;

this doesn't mean math isn't involved somewhere, only it is not what actually "runs" the computer, but rather, it is much closer to running on mechanisms implementing basic arithmetic with an algebra-like abstraction layer thrown on top, but even then it is weak as many core assumptions made in algebra and calculus don't really map over to computers, and with most of the actual "math" part being done by the human programmer (and not by the computer).

but, then again, I am left to realize that this basically comes down to worldview.

actually, I guess this brings up another point:

actually knowing what one is doing, and thus designing something more based on the relative design tradeoffs of the various options;

not really knowing what they are doing, and just sort of hacking on it in an attempt to get a desirable result (basically, lots of fiddling and trial-and-error trying to better approach the desired results).

I guess, arguably the "engineering" in software-engineering, is probably more in reference to when someone knows what they are doing (and weighs various options and similar), rather than just hacking on it in an attempt to make it work.

interestingly, both seem to have pros and cons, rather than one strategy or another always producing a better result.

it seems to depend a lot on what someone is doing at the time.

other times, a person may need to "just do it" regardless of whether or not they really have all the prerequisite knowledge.

like, "there is only me, and I don't really know how to make this, but there is no other way it is going to get done" (leading to it being time to break out the trial-and-error and prepare for extended periods of fiddling...).

or such...

I think of "engineering" as being the process of taking a set of requirements and creating a system of some kind to achieve those requirements. "Software engineers" therefore take a set of requirements for the behaviour of a piece of software and create a software system to achieve those requirements.

I think of "engineering" as being the process of taking a set of requirements and creating a system of some kind to achieve those requirements. "Software engineers" therefore take a set of requirements for the behaviour of a piece of software and create a software system to achieve those requirements.

A set of requirements encodes an infinite spectrum of possible implementations. And all possible fields can be reduced to that act of producing implementations which satisfy a particular set of requirements (even a master chef is merely producing a recipe that satisfies a set of subjective requirements).

It is that act of creation that is relevant to this discussion.

Play around with an OO functional language focusing on equations for a while and you will probably quickly find many ways you can apply calculus to your business apps and almost all the areas wont be obvious either.

That sounds awesome! I have been meaning to make some time to learn F#. Do you have any examples of how you've applied calculus to a business app? Did it have practical benefits? (e.g., implemented code faster, more maintainable code, etc.)

I think of "engineering" as being the process of taking a set of requirements and creating a system of some kind to achieve those requirements. "Software engineers" therefore take a set of requirements for the behaviour of a piece of software and create a software system to achieve those requirements.

A set of requirements encodes an infinite spectrum of possible implementations. And all possible fields can be reduced to that act of producing implementations which satisfy a particular set of requirements (even a master chef is merely producing a recipe that satisfies a set of subjective requirements).

It is that act of creation that is relevant to this discussion.

yeah, I think it is mostly a question of methodology and thought processes, and what exact types of methodologies and processes can be regarded as engineering, ...

for example, some people assert that it isn't really engineering unless a person uses the BDUF or Waterfall methodology, or may go as far as to claim that Waterfall is the only valid way to develop software, ...

whereas, lots of other people use various other strategies, and tend to also be fairly successful at getting software made.

I have personally found it is preferable to avoid dealing with anyone which obsesses too much over methodology though.

for an individual developer, elements of lifestyle, psychology, time and effort investment, available resources, ... may also become significant factors.

so, whether or not it is really engineering or not, or necessarily even whether or not it is ideal to consider whether it should or should not be such, I don't really know...

Engineering: the art or science of making practical application of the knowledge of pure sciences.

Programming is one part of the process of Software Engineering - which in itself represents an art / science of making practical application of the knowledge of computer sciences. It's indisputably engineering.

Dictionary definitions aside, a software engineer is not doing work that is all that different to the person who is designing and architecting bridges (indeed, the architect is almost certainly reliant upon at least one software engineer in order to do their part of the work, if they are not doing so themselves already). People hire programmers who are good at math, because algorithms are a strictly mathematical process used for reasoning or data processing. Writing code may require the act of applying oneself to a keyboard and organising a series of words into recogniseable language, but that's about as far as it goes in terms of similarity to writing.