4 ms·

>However, in software, we are all (or should be, at least) constantly working on things outside our current skillset. I kind of disagree with you here. Profess

by TheCapn 12y ago

>However, in software, we are all (or should be, at least) constantly working on things outside our current skillset. I kind of disagree with you here. Professionally I code the software that runs Control Systems for various industries. The software design must match a electrical spec that is written by one of our Electrical Engineers. So although my work might be dipping to the agricultural or civil or mechanical engineering domains I must collaborate with a qualified engineer to meet spec. The way that statement is written is not to say that myself as a controls developer cannot branch into web or mobile development though I'd argue there are certain software fields not everyone should be practicing without some rudimentary training and proof of competence (anything security related, or any branch of software that interfaces to real world components). I don't want a self-taught web front-end coder writing code that handles the security of my financial information. I wouldn't necessarily trust a corporate programmer writing billing software to write embedded drivers. That's not to say people can't be hobbyists though. People dabble in electrical hobbies all the time but they don't market themselves professionally as "Engineers" either like many do in Software.

angersock 12y ago
I don't want a self-taught web front-end coder writing code that handles the security of my financial information You know how many developers that is today, though? Especially given the vast gap between how software engineering is taught and how it is practiced? I wouldn't necessarily trust a corporate programmer writing billing software to write embedded drivers. Have you seen the great lengths assembly hackers at, say, BMC, go to to make sure their legacy code modifications keep running on turducken VMs? I would trust those folks to write embedded drivers if the project was spec'ed properly. That's the whole point, though: in our general discipline it comes down to collecting data, transforming data, and persisting data--the actual type of data matter relatively little, and introducing these arbitrary "Oh, you're a frontend JS guy, you shouldn't work on my backend transaction processing system" restrictions only hurts us.
- TheCapn 12y ago
  I understand what you're saying I think. My point is that with our massive amount of inner-connectivity today I want regulated assurances that my financial security or hardware wellbeing is handled by someone who is vetted professionally for being competent. If the JS guy wants to go through the rigor to learn the tools to be a great security expert he should be able to. Heck, I wouldn't refer to him as a "JS guy" at that point anymore either. I want an industry where there is a vetting process to prevent frauds or incompetence from creating issues prior to the issues existing. Some amount of assurance, or accountability. We currently sort of work on "best-intentions" in that regard. Engineering in it's traditional fields has gone through this growth pain. In some cases many lives were lost in the process of learning that there should be a regulatory body overseeing who is allowed to sell themselves as competent practitioners. Consider the state of OpenSSL when Heartbleed came about. There was most definitely a series of fundamental issues at play that weren't brought to light until after its hayday, but as an industry we sort of have the mindset of "these types of things are inevitable". I can't say concretely where I stand on the matter but I do believe a higher level of accountability would be a net positive for public perception. This is a very loose example, its a complex topic that would take far longer to debate in full I think. On the flip side too is the idea that "Software Engineering" becomes a protected field where its important. I mentioned my domain is control systems, but so many of the tools I work with are years behind more modern frameworks and technologies that are used outside my industry. I have embarrassingly low amounts of tools to test the programs I develop, its mostly a rigorous manual testing procedure that gets done to say I'm satisfied and I'm responsible for this application. I blame, in part, the fact that this work is more often done by Engineers in other domains. They don't know what modern software development has overcome and created. Some of the routines and applications I inherited moving to this position were embarrassingly poor and thankfully never caused real-world harm mostly due to the numerous tiers of safeguards that exist in designs. Its like coding with exceptions but being fine with it because there's a Catch somewhere higher in the operating environment. I suppose I might be in the wrong place here as this is HN a more Startup-centric tech forum. I've long disagreed with the mindset that software engineers need to "upset the established norm" in a lot of fields. Medical is a big one lately that's getting a lot of traction. There's a balance that should exist between regulated gatekeeping of fields for the public good and legislated protection over fields to prevent outside interaction. I feel I've ranted a bit. This truly is a complex topic which I think I'm still establishing a position on as I grow and get experience in the industry. I know where we are _currently_ isn't right in the long run, but taking the term "Engineer" to be as by-the-book as possible to the traditional fields of engineering isn't right either.

by TheCapn 12y ago

angersock 12y ago

I don't want a self-taught web front-end coder writing code that handles the security of my financial information You know how many developers that is today, though? Especially given the vast gap between how software engineering is taught and how it is practiced? I wouldn't necessarily trust a corporate programmer writing billing software to write embedded drivers. Have you seen the great lengths assembly hackers at, say, BMC, go to to make sure their legacy code modifications keep running on turducken VMs? I would trust those folks to write embedded drivers if the project was spec'ed properly. That's the whole point, though: in our general discipline it comes down to collecting data, transforming data, and persisting data--the actual type of data matter relatively little, and introducing these arbitrary "Oh, you're a frontend JS guy, you shouldn't work on my backend transaction processing system" restrictions only hurts us.

TheCapn 12y ago
I understand what you're saying I think. My point is that with our massive amount of inner-connectivity today I want regulated assurances that my financial security or hardware wellbeing is handled by someone who is vetted professionally for being competent. If the JS guy wants to go through the rigor to learn the tools to be a great security expert he should be able to. Heck, I wouldn't refer to him as a "JS guy" at that point anymore either. I want an industry where there is a vetting process to prevent frauds or incompetence from creating issues prior to the issues existing. Some amount of assurance, or accountability. We currently sort of work on "best-intentions" in that regard. Engineering in it's traditional fields has gone through this growth pain. In some cases many lives were lost in the process of learning that there should be a regulatory body overseeing who is allowed to sell themselves as competent practitioners. Consider the state of OpenSSL when Heartbleed came about. There was most definitely a series of fundamental issues at play that weren't brought to light until after its hayday, but as an industry we sort of have the mindset of "these types of things are inevitable". I can't say concretely where I stand on the matter but I do believe a higher level of accountability would be a net positive for public perception. This is a very loose example, its a complex topic that would take far longer to debate in full I think. On the flip side too is the idea that "Software Engineering" becomes a protected field where its important. I mentioned my domain is control systems, but so many of the tools I work with are years behind more modern frameworks and technologies that are used outside my industry. I have embarrassingly low amounts of tools to test the programs I develop, its mostly a rigorous manual testing procedure that gets done to say I'm satisfied and I'm responsible for this application. I blame, in part, the fact that this work is more often done by Engineers in other domains. They don't know what modern software development has overcome and created. Some of the routines and applications I inherited moving to this position were embarrassingly poor and thankfully never caused real-world harm mostly due to the numerous tiers of safeguards that exist in designs. Its like coding with exceptions but being fine with it because there's a Catch somewhere higher in the operating environment. I suppose I might be in the wrong place here as this is HN a more Startup-centric tech forum. I've long disagreed with the mindset that software engineers need to "upset the established norm" in a lot of fields. Medical is a big one lately that's getting a lot of traction. There's a balance that should exist between regulated gatekeeping of fields for the public good and legislated protection over fields to prevent outside interaction. I feel I've ranted a bit. This truly is a complex topic which I think I'm still establishing a position on as I grow and get experience in the industry. I know where we are _currently_ isn't right in the long run, but taking the term "Engineer" to be as by-the-book as possible to the traditional fields of engineering isn't right either.