3 ms·

Should "sound engineers" in recording studios drop the title? "special effects engineers" in film production? Should the academy awards do away with the "scient

by geebee 5y ago

Should "sound engineers" in recording studios drop the title? "special effects engineers" in film production? Should the academy awards do away with the "scientific and engineering achievement award"? If there were legitimate confusion about software engineers, I'd see the problem. If people who aren't licensed professional engineers are claiming they are, of if people are reading a book on SQL and PHP and hanging out a shingle as a structural engineer, then ok. But "engineer" is a very widespread term to describe the ingenious (Ingenieur, Ingenium, Engineer) application of design, technology, science, and mathematics to real world problems. That is probably the primary use of the term.

hilbert42 5y ago
"Should "sound engineers" in recording studios drop the title? "special effects engineers" in film production? Should the academy awards do away with the "scientific and engineering achievement award"?" The usual definition of an engineer is someone with a degree in the subject and it's been that way for about a century or more. Most 'sound engineers' do not have one (but there are exceptions). In fact, most of those who I've known have no qualifications in the field at all. That's not to say they're not good at their work (as many are very competent). SMPTE (Society of Motion Picture and Television Engineers) and the AES (Audio Engineering Society) used to require a degree for membership but I'm unaware of whether they still do or not (as it's a long while since I had anything to do with these institutions). If I recall one could automatically become a member of them if one was already a member of the IEEE (but it required a degree as well for membership). This reciprocal arrangement between professional bodies works when the core training is the same (I recall becoming a member of one institution after it took my name from another, all I did was tick the box and pay the fee). The question of whether it matters if someone is called an engineer or not is probably only relevant when regulation and safety are involved. For example, my profession is electrical engineering and computing so I shouldn't (and wouldn't) misrepresent myself as a civil engineer and apply for a bridge-building job when that's not my profession (that's to say, I may be in engineering but I'm unskilled in the bridge-building branch of the profession). Even if I secretly studied bridge building for, say, over a decade and was quite excellent in the subject I shouldn't be allowed to practice that skill without going through the formal accreditation process because when something goes wrong (and sooner or later it inevitably will), the lines of accountability will be dredged out (no pun intended). When this happens it's much easier for all involved to assume [know from one's qualifications] what the skills and expertise of those involved are so blame can be apportioned. It's hard to imagine a situation where a sound engineer sitting behind a sound desk—or a film grader/editor at a Moviola film editor or its digital equivalent—can do anything that would endanger life so it likely doesn't matter what they call themselves. The matter of using the term 'engineering' in connection with computer programming is a much more difficult and vexed matter for two reasons. The first is how practical software development actually measures up to other engineering professions, and second, the applications to which software is put. In the first case there's a solid argument (as per the SciAm article reference I've posted elsewhere to this story), which is that the maturity of software development per se is well behind other branches of engineering (electrical and chemical engineering for instance). The second covers the fields where software is applied, which, as we all know, is everywhere. Unlike my bridge-building analogy, we've not yet separated out a methodology (a separate engineering philosophy) for critical systems software development from other less critical systems. (It's obvious we need them separated but we still use common tools (compilers etc.) and common programming methodologies and this is a significant problem—I could provide reasons but they are too lengthy to cover here although for those interested the SciAm article is a good place to start.) Put simply, the level of hardness and granularity of traditional engineering (set by a several-hundred-year long lineage of experience and backed by both domestic and international standards) that goes into hardware design and then building hardware—bridges, rockets, microchips, etc.—is not necessarily backed by the same hardness and granularity from the supporting software. And as we've seen in practice, in many, many instances this has been a major problem. In my opinion, there will have to be rationalization and standards eventually. When that will happen is anyone's guess.
- deleted 5y ago
  [deleted]

by geebee 5y ago

hilbert42 5y ago

"Should "sound engineers" in recording studios drop the title? "special effects engineers" in film production? Should the academy awards do away with the "scientific and engineering achievement award"?" The usual definition of an engineer is someone with a degree in the subject and it's been that way for about a century or more. Most 'sound engineers' do not have one (but there are exceptions). In fact, most of those who I've known have no qualifications in the field at all. That's not to say they're not good at their work (as many are very competent). SMPTE (Society of Motion Picture and Television Engineers) and the AES (Audio Engineering Society) used to require a degree for membership but I'm unaware of whether they still do or not (as it's a long while since I had anything to do with these institutions). If I recall one could automatically become a member of them if one was already a member of the IEEE (but it required a degree as well for membership). This reciprocal arrangement between professional bodies works when the core training is the same (I recall becoming a member of one institution after it took my name from another, all I did was tick the box and pay the fee). The question of whether it matters if someone is called an engineer or not is probably only relevant when regulation and safety are involved. For example, my profession is electrical engineering and computing so I shouldn't (and wouldn't) misrepresent myself as a civil engineer and apply for a bridge-building job when that's not my profession (that's to say, I may be in engineering but I'm unskilled in the bridge-building branch of the profession). Even if I secretly studied bridge building for, say, over a decade and was quite excellent in the subject I shouldn't be allowed to practice that skill without going through the formal accreditation process because when something goes wrong (and sooner or later it inevitably will), the lines of accountability will be dredged out (no pun intended). When this happens it's much easier for all involved to assume [know from one's qualifications] what the skills and expertise of those involved are so blame can be apportioned. It's hard to imagine a situation where a sound engineer sitting behind a sound desk—or a film grader/editor at a Moviola film editor or its digital equivalent—can do anything that would endanger life so it likely doesn't matter what they call themselves. The matter of using the term 'engineering' in connection with computer programming is a much more difficult and vexed matter for two reasons. The first is how practical software development actually measures up to other engineering professions, and second, the applications to which software is put. In the first case there's a solid argument (as per the SciAm article reference I've posted elsewhere to this story), which is that the maturity of software development per se is well behind other branches of engineering (electrical and chemical engineering for instance). The second covers the fields where software is applied, which, as we all know, is everywhere. Unlike my bridge-building analogy, we've not yet separated out a methodology (a separate engineering philosophy) for critical systems software development from other less critical systems. (It's obvious we need them separated but we still use common tools (compilers etc.) and common programming methodologies and this is a significant problem—I could provide reasons but they are too lengthy to cover here although for those interested the SciAm article is a good place to start.) Put simply, the level of hardness and granularity of traditional engineering (set by a several-hundred-year long lineage of experience and backed by both domestic and international standards) that goes into hardware design and then building hardware—bridges, rockets, microchips, etc.—is not necessarily backed by the same hardness and granularity from the supporting software. And as we've seen in practice, in many, many instances this has been a major problem. In my opinion, there will have to be rationalization and standards eventually. When that will happen is anyone's guess.

deleted 5y ago
[deleted]