|
I think your definition of engineering is a curious mix of "No true Scotsman" fallacy and a bit of circular reasoning. My parents were very respected traffic engineers. One was concerned with traffic inside cities, another with road design. One couldn't give less care about "nature of materials and physical force" while figuring out where to put traffic lights and close roads, while another had a set of standards (say a lorry's turning radius, sign sizes etc) which they've applied without thinking about costs or even producing a pysical thing. That was done by some other contractor in a sense anyway. A friend of mine is an electrical engineer. He maintains electric motors and I guess he would fit your definition better. At the same time, how much an electrical engineer has in common with traffic engineer? Or say an air traffic engineer? Or a construction engineer? I would say what they mostly have in common is the "engineer" part as they are doing completely different jobs in completely different industries. I might even go further and say when someone calls "Alice is an engineer", it is just a shorthand for "Alice is a mechanical [or some other] engineer". So those were the differences, but lets see the similarities. When a traffic engineer gets a project to see if they can increase the traffic flow from point A to B it usually follows the common pattern of finding out the current situation, figuring out a solution, testing/simulating it out and then making the project/solution on what should be done. Then when the solution gets implemented, some details can be re-adjusted etc. I did simplify it a bit, and I'm unsure in the exact english phrases, but I think you get my point. Software engineers that I know follow the exact same process. Oh, a database is overloaded, lets see what we can do about it. Can we give it more hardware? No, as thats too expensive? What about if we scale up/down the services/workers/instances/nodes/pods calling that database? Can we simulate that? What do the metrics say? Etc etc. You see where am going with this? In essence, there is no difference. My point is, if you cannot call Software Engineering only by the word "Engineering", then you cannot call anything else (just) Engineering. You can dance around this whatever you like, and define Engineering either narrowly or widely enough not to include Software Engineering (just like you did), but at the end of the day this isn't a natural science like say Maths or Physics. You cannot say 2+2=5, but you can say Engineering is X. But then, lets be honest here, and I suspect this is the root cause of this: it's about exclusivity and status. Engineers, doctors, lawyers, electricians, plumbers and a myriad of different professions like having guilds (or similar organizations, speaking in general here), and like having artificial scaricity. This brings status, it brings money, it brings power and influence. It cannot work if everyone is allowed in. It's what's simply called gatekeeping. It's what hiding behind a dismissive, elitist sentence I've heard too many times: "Oh, but he's no engineer". So if we're honest here we can call a spade a spade. |
Let's resort to definitions, with apologies.
Engineering
> Engineering is the use of scientific principles to design and build machines, structures, and other items, including bridges, tunnels, roads, vehicles, and buildings.[1]
That certainly doesn't make Software Engineers what are traditionally thought of as "engineers." So... on to Software Engineering:
Software Engineering
> Software engineering [is] the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software and the study of these approaches; that is, the application of engineering and computer science to software. [2]
That description does not fit what most of us do when we write or create software. Perhaps it should. We'd be better off in many cases. But programmers are often closer to gardeners than engineers in that we approach solving problems through empirical processes, testing and verifying as we go. TDD is an admission of the need to do just that. So is Scrum (empirical process control). There absolutely are cases where algorithm optimization using the latest research must be applied just so. There absolutely are cases where applying gradient descent and convolutional neural nets in specific fashions applies. Most of us are gardeners growing our systems, or carpenters building out a feature, though. Programmers. Software engineer makes it sound loftier, just like sanitation engineer makes trash collection sound loftier.
I will absolutely concede that I still use the "engineer" terminology on a day to day basis, my opinion on the internet notwithstanding. But it is a label that is weakly applied for fashion and connotation, rather than for its distinct meaning, and I suppose that is what I tilt at here on HN. Apologies for the pedantry.
[1] https://en.wikipedia.org/wiki/Engineering
[2] https://en.wikipedia.org/wiki/List_of_engineering_branches