4 ms·

Hence why throwing around the term "engineer" in software is silly. There's little consequence to misrepresenting yourself in software, other than your immediat

Hence why throwing around the term "engineer" in software is silly. There's little consequence to misrepresenting yourself in software, other than your immediate employment and maybe a financial lawsuit. In other professions, enforcement has real teeth due to the stakes of failure.

itronitron 2y ago
But so many bugs in software can be fixed by just turning the computer off and back on again. Is that great engineering or bad?
- zo1 2y ago
  To be honest, "engineers" in the physical sciences generally have a much easier and predictable time than programmers. Is that perhaps a fault of programmers, very possibly (nevermind, definitely our own doing). The reason I say they have an easier time is that a lot of their "problems" are solved, have general solutions and lookups, best practices that you can not deviate from, etc. E.g. look at the amount of times we all have to re-invent distributed work queues and notifying other systems of something. If we were in the context of physical engineering, there would be maybe 4 options, all with well-understood pros/cons and you just pick the one that fits your performance profile and requirements. Done. And then sure, we could get some "certified engineer" software title where a person can confidently say "yes I sign off that if you use this option, and your estimated load of messages per second never exceeds Y, and you have provisioned X-units of compute on your server, then you will lose less than 0.01% of messages." What an easy job that would be - Except we have countless hipster-devs all wanting to "do it their own way" and write their own library for it.
  - jpc0 2y ago
    You used message queues which is a hard problem and compared it to what is probably a simple problem in engineering, picking a material or screw size or such. You have disciplines in software that can easily be equated to the engineering you described, many people get paid a lot of money to create CRUD apps. Which database do you select, how do you implement the webserver, do you seperate out the API and frontend? these are all pretty easy problems to solve and have solutions with obvious pros and cons, sure you can have someone try some novel technique every now and then but the industry as a whole know how to do that. When you start discussing distributed systems it's kind of in autonomous Mars rover territory, the best practices are kind of there but there isn't a ton of consensus that what is known is even the best solution.
mitthrowaway2 2y ago
Software failure might have increasing stakes these days. The CrowdStrike outage probably had more casualties than THERAC-25. Hospital systems shut down, people couldn't access secure areas with their ID badges, and 911 systems stopped working.
- starttoaster 2y ago
  The thing is, you can hold an engineer that designed a bridge accountable for designing a poor bridge that failed under load. The strength of materials, the load bearing ratings of a particular design for a bridge, can all be calculated and are well known. How do you come up with the same types of calculations for software? You really can't, because writing software is more about designing a solution to problems people aren't already solving. You can write tests for the problems that you are skilled enough to anticipate, or even tests to cover problems you discovered in hindsight of a regression, and sure you can hold software engineers accountable for choosing to bypass the tests they write. But how do you hold a software engineer accountable for a failure mode that nobody considered already? It's like holding the very first person to design a bridge accountable for making a bad bridge, let's see you make a better one. For that reason, I don't think we'll see software engineers accepting the same level of responsibility for their errors as structural engineers.
  - Workaccount2 2y ago
    Software is simply too complex. The complexity is mitigated with abstraction, but the abstracted code quickly becomes complex again, and it once again gets abstracted. Layer this a bunch of times and you get to where the regular SWE is working. However, that doesn't mean we cannot have bug-free code. It just means that code would have to be written close to hardware, likely by a team fluent in both hardware execution and software architecture.
  - ahepp 2y ago
    I can certainly see that there are some fundamental issues with assigning software engineers the level of responsibility that structural engineers have. That said, from what I've heard, crowdstrike seems like a great example of something a hypothetical licensed software engineer should lose their license for. I admit I don't know all the details, but it seems that an update was pushed to prod that immediately broke all windows machines. Doesn't that mean they pushed an update to customers without testing it even a single time, on a single windows machine? I heard they even bypassed customer staging environments? I also find it interesting to consider what the future holds. A few possible paths seem like: 1) The state of the profession progresses to the point where we have enough widely recognized best practices to make licensure meaningful 2) We consider the benefits of rapid, cheap(er than the alternative), software production as being greater than the costs of crowdstrike level events, and change nothing 3) We adapt software system architectures on the customer side so that there's meaningful oversight and accountability inside an organization (in many ways enabling #1)
kmac_ 2y ago
Well, the CS program differs slightly between polytechnics and universities. The former emphasizes practical engineering, such as networking details, while the latter focuses more on theory, such as algorithm correctness proofs. I think our job requires a lot of engineering due to reliability, performance, compatibility, communicating design, etc.
thebruce87m 2y ago
There are lots of safety critical systems out there with software in them. You probably travelled in one today.
itishappy 2y ago
Code runs our electrical grid, medical devices, internet, shipping, financial systems, early warning radar, etc. Meanwhile, some accredited mechanical engineer is getting paid to ensure your toilet paper gets perforated correctly.
- Workaccount2 2y ago
  And probably getting paid 1/2 to 1/3 what they would have been making if they skipped college and just crashed coursed javascript.
  - itishappy 2y ago
    I resemble that remark.
- commandlinefan 2y ago
  I _think_ I'd like to see software development get some sort of accreditation because... man, there are a lot of people doing it who shouldn't be doing it. But I wonder if that would really do much beyond requiring everybody who worked as a programmer to pay some annual fee and fill out some extra documentation every time they made a change.
  - techwizrd 2y ago
    NCEES attempted to create an accreditation scheme in the US for Software Engineering, but canceled it because few people took the exam [0]. It's not surprising that almost no one took the exam. It wasn't well publicized and employers do not require an FE or PE for software engineers. You also have to pass the FE. The closest relevant prerequisite was the FE in Electrical and Computer Engineering, which most CS coursework would not cover. And you need to spend 4 years working under a licensed PE. Ill-conceived and executed. 0: https://ncees.org/ncees-discontinuing-pe-software-engineering-exam/ https://ncees.org/ncees-discontinuing-pe-software-engineerin...
  - johnnyjeans 2y ago
    I certainly wouldn't, especially if it's going to be modeled on other accredited fields like Medicine and Engineering where you can't even see the review board until you've made it through formal education. Software development is one of the few places where someone like me, who is allergic to pedagogy, was able to find professional success not mired in stifling bureaucracy. The overwhelming majority of software has absolutely zero criticality. The retail staff at your local supermarket can do more damage through negligence than virtually any given programmer. Fucking us over because of an incalculably tiny minority of jobs is a ludicrous proposition. No thanks. Yeah, there are a lot of people who have no business making this field their profession. It's also a profession that's rather difficult to test for competency without filtering out 95%+ of the workforce. That's why it's important for leadership in charge of those roles to have deep domain knowledge to filter out people who aren't up for it. That's the entire point of an in-depth interview process.
petre 2y ago
Not really because much of the older hardware was replaced by software. See PTOs. Current hardware increasingly relies on embedded software. We are using it for payments, driving our vehicles, coordinating railway traffic, flying planes, calculating bridges.
pkaye 2y ago
Just give a new title "Software CEO" and then there is no liability to worry about and you get paid a lot more.

itronitron 2y ago

But so many bugs in software can be fixed by just turning the computer off and back on again. Is that great engineering or bad?

zo1 2y ago
To be honest, "engineers" in the physical sciences generally have a much easier and predictable time than programmers. Is that perhaps a fault of programmers, very possibly (nevermind, definitely our own doing). The reason I say they have an easier time is that a lot of their "problems" are solved, have general solutions and lookups, best practices that you can not deviate from, etc. E.g. look at the amount of times we all have to re-invent distributed work queues and notifying other systems of something. If we were in the context of physical engineering, there would be maybe 4 options, all with well-understood pros/cons and you just pick the one that fits your performance profile and requirements. Done. And then sure, we could get some "certified engineer" software title where a person can confidently say "yes I sign off that if you use this option, and your estimated load of messages per second never exceeds Y, and you have provisioned X-units of compute on your server, then you will lose less than 0.01% of messages." What an easy job that would be - Except we have countless hipster-devs all wanting to "do it their own way" and write their own library for it.
- jpc0 2y ago
  You used message queues which is a hard problem and compared it to what is probably a simple problem in engineering, picking a material or screw size or such. You have disciplines in software that can easily be equated to the engineering you described, many people get paid a lot of money to create CRUD apps. Which database do you select, how do you implement the webserver, do you seperate out the API and frontend? these are all pretty easy problems to solve and have solutions with obvious pros and cons, sure you can have someone try some novel technique every now and then but the industry as a whole know how to do that. When you start discussing distributed systems it's kind of in autonomous Mars rover territory, the best practices are kind of there but there isn't a ton of consensus that what is known is even the best solution.

mitthrowaway2 2y ago

Software failure might have increasing stakes these days. The CrowdStrike outage probably had more casualties than THERAC-25. Hospital systems shut down, people couldn't access secure areas with their ID badges, and 911 systems stopped working.

starttoaster 2y ago
The thing is, you can hold an engineer that designed a bridge accountable for designing a poor bridge that failed under load. The strength of materials, the load bearing ratings of a particular design for a bridge, can all be calculated and are well known. How do you come up with the same types of calculations for software? You really can't, because writing software is more about designing a solution to problems people aren't already solving. You can write tests for the problems that you are skilled enough to anticipate, or even tests to cover problems you discovered in hindsight of a regression, and sure you can hold software engineers accountable for choosing to bypass the tests they write. But how do you hold a software engineer accountable for a failure mode that nobody considered already? It's like holding the very first person to design a bridge accountable for making a bad bridge, let's see you make a better one. For that reason, I don't think we'll see software engineers accepting the same level of responsibility for their errors as structural engineers.
- Workaccount2 2y ago
  Software is simply too complex. The complexity is mitigated with abstraction, but the abstracted code quickly becomes complex again, and it once again gets abstracted. Layer this a bunch of times and you get to where the regular SWE is working. However, that doesn't mean we cannot have bug-free code. It just means that code would have to be written close to hardware, likely by a team fluent in both hardware execution and software architecture.
- ahepp 2y ago
  I can certainly see that there are some fundamental issues with assigning software engineers the level of responsibility that structural engineers have. That said, from what I've heard, crowdstrike seems like a great example of something a hypothetical licensed software engineer should lose their license for. I admit I don't know all the details, but it seems that an update was pushed to prod that immediately broke all windows machines. Doesn't that mean they pushed an update to customers without testing it even a single time, on a single windows machine? I heard they even bypassed customer staging environments? I also find it interesting to consider what the future holds. A few possible paths seem like: 1) The state of the profession progresses to the point where we have enough widely recognized best practices to make licensure meaningful 2) We consider the benefits of rapid, cheap(er than the alternative), software production as being greater than the costs of crowdstrike level events, and change nothing 3) We adapt software system architectures on the customer side so that there's meaningful oversight and accountability inside an organization (in many ways enabling #1)

kmac_ 2y ago

Well, the CS program differs slightly between polytechnics and universities. The former emphasizes practical engineering, such as networking details, while the latter focuses more on theory, such as algorithm correctness proofs. I think our job requires a lot of engineering due to reliability, performance, compatibility, communicating design, etc.

thebruce87m 2y ago

There are lots of safety critical systems out there with software in them. You probably travelled in one today.

itishappy 2y ago

Code runs our electrical grid, medical devices, internet, shipping, financial systems, early warning radar, etc. Meanwhile, some accredited mechanical engineer is getting paid to ensure your toilet paper gets perforated correctly.

Workaccount2 2y ago
And probably getting paid 1/2 to 1/3 what they would have been making if they skipped college and just crashed coursed javascript.
- itishappy 2y ago
  I resemble that remark.
commandlinefan 2y ago
I _think_ I'd like to see software development get some sort of accreditation because... man, there are a lot of people doing it who shouldn't be doing it. But I wonder if that would really do much beyond requiring everybody who worked as a programmer to pay some annual fee and fill out some extra documentation every time they made a change.
- techwizrd 2y ago
  NCEES attempted to create an accreditation scheme in the US for Software Engineering, but canceled it because few people took the exam [0]. It's not surprising that almost no one took the exam. It wasn't well publicized and employers do not require an FE or PE for software engineers. You also have to pass the FE. The closest relevant prerequisite was the FE in Electrical and Computer Engineering, which most CS coursework would not cover. And you need to spend 4 years working under a licensed PE. Ill-conceived and executed. 0: https://ncees.org/ncees-discontinuing-pe-software-engineering-exam/ https://ncees.org/ncees-discontinuing-pe-software-engineerin...
- johnnyjeans 2y ago
  I certainly wouldn't, especially if it's going to be modeled on other accredited fields like Medicine and Engineering where you can't even see the review board until you've made it through formal education. Software development is one of the few places where someone like me, who is allergic to pedagogy, was able to find professional success not mired in stifling bureaucracy. The overwhelming majority of software has absolutely zero criticality. The retail staff at your local supermarket can do more damage through negligence than virtually any given programmer. Fucking us over because of an incalculably tiny minority of jobs is a ludicrous proposition. No thanks. Yeah, there are a lot of people who have no business making this field their profession. It's also a profession that's rather difficult to test for competency without filtering out 95%+ of the workforce. That's why it's important for leadership in charge of those roles to have deep domain knowledge to filter out people who aren't up for it. That's the entire point of an in-depth interview process.

petre 2y ago

Not really because much of the older hardware was replaced by software. See PTOs. Current hardware increasingly relies on embedded software. We are using it for payments, driving our vehicles, coordinating railway traffic, flying planes, calculating bridges.

pkaye 2y ago

Just give a new title "Software CEO" and then there is no liability to worry about and you get paid a lot more.