3 ms·

The term “software engineer” was invented to describe the work being done by Margaret Hamilton and her team, when developing the guidance software for the Apoll

The term “software engineer” was invented to describe the work being done by Margaret Hamilton and her team, when developing the guidance software for the Apollo moon landings. It definitely is a form of engineering. From Wikipedia: > When I first came up with the term, no one had heard of it before, at least in our world. It was an ongoing joke for a long time. They liked to kid me about my radical ideas. It was a memorable day when one of the most respected hardware gurus explained to everyone in a meeting that he agreed with me that the process of building software should also be considered an engineering discipline, just like with hardware. Not because of his acceptance of the new 'term' per se, but because we had earned his and the acceptance of the others in the room as being in an engineering field in its own right. https://en.wikipedia.org/wiki/Margaret_Hamilton_(software_engineer) https://en.wikipedia.org/wiki/Margaret_Hamilton_(software_en...

jhgb 6y ago
> The term “software engineer” was invented to describe the work being done by Margaret Hamilton and her team, when developing the guidance software for the Apollo moon landings. There's a considerable debate about when and where this term was "invented", apparently with some oral histories placing it even into (late?) 1950s. As for grandparent's comment, I think it was referring to the fact that the nature of the job is completely different. For example a large portion of a traditional engineer's job deals with fighting the natural world. A bolt may rust away and stop doing what it was doing until then. A source code line in the form of a=a+7; won't do any such thing. As long as it exists it will keep doing the same thing. Hence software engineers have to deal with a completely different set of issues, to the extent that calling it "engineering" is to a certain extent metaphorical.
- heelix 6y ago
  Code rots/rusts faster than most physical objects. Requirements change, libraries update at a breakneck speed. I've had to deal with some (functional) languages that don't allow you to change the the variable where some would allow that sort of modification just fine for your simple example. Change is everywhere.
  - jhgb 6y ago
    > Code rots/rusts faster than most physical objects. Requirements change, libraries update at a breakneck speed. That's a forced metaphor as well, not actually an identical process. If "requirements change", that's not the same thing as a bolt rusting away. Surely the requirements for the rusting bolt didn't change, or the requirements for its "dependencies", i.e., the things it's attaching together. > I've had to deal with some (functional) languages that don't allow you to change the the variable where some would allow that sort of modification just fine for your simple example. I completely fail the relevance of that. Or maybe it is somewhat relevant, but in the completely opposite way, i.e., that this phenomenon does not even have an analogy in the physical world, thus underlining the vast differences between software engineering and classical engineering disciplines. (Likewise the dichotomy between a computational procedure and the process generated by said procedure, the latter being constrained in the way you describe, doesn't exist in traditional engineering either.)

jhgb 6y ago

> The term “software engineer” was invented to describe the work being done by Margaret Hamilton and her team, when developing the guidance software for the Apollo moon landings. There's a considerable debate about when and where this term was "invented", apparently with some oral histories placing it even into (late?) 1950s. As for grandparent's comment, I think it was referring to the fact that the nature of the job is completely different. For example a large portion of a traditional engineer's job deals with fighting the natural world. A bolt may rust away and stop doing what it was doing until then. A source code line in the form of a=a+7; won't do any such thing. As long as it exists it will keep doing the same thing. Hence software engineers have to deal with a completely different set of issues, to the extent that calling it "engineering" is to a certain extent metaphorical.

heelix 6y ago
Code rots/rusts faster than most physical objects. Requirements change, libraries update at a breakneck speed. I've had to deal with some (functional) languages that don't allow you to change the the variable where some would allow that sort of modification just fine for your simple example. Change is everywhere.
- jhgb 6y ago
  > Code rots/rusts faster than most physical objects. Requirements change, libraries update at a breakneck speed. That's a forced metaphor as well, not actually an identical process. If "requirements change", that's not the same thing as a bolt rusting away. Surely the requirements for the rusting bolt didn't change, or the requirements for its "dependencies", i.e., the things it's attaching together. > I've had to deal with some (functional) languages that don't allow you to change the the variable where some would allow that sort of modification just fine for your simple example. I completely fail the relevance of that. Or maybe it is somewhat relevant, but in the completely opposite way, i.e., that this phenomenon does not even have an analogy in the physical world, thus underlining the vast differences between software engineering and classical engineering disciplines. (Likewise the dichotomy between a computational procedure and the process generated by said procedure, the latter being constrained in the way you describe, doesn't exist in traditional engineering either.)