4 ms·

There are 2 types of engineers. Generic Engineer, "Engineerius Domesticus" - Like an architect or civil engineer. If they make a fatal mistake, especially one

There are 2 types of engineers. Generic Engineer, "Engineerius Domesticus" - Like an architect or civil engineer. If they make a fatal mistake, especially one that can be avoided with best practices, they will never be allowed to work in their profession again. Possibly they go to jail. Software Engineer, "Engineerius Softwarus Sapiens Sapiens Sapiens Sapiens" - If they make a fatal mistake, especially one that can be avoided with best practices, there will be a blameless post mortem/retrospective where everyone gets a pat on the back, exclaiming "what a great job everyone did, this was really unavoidable, if we disregard the fact that it was completely avoidable". The smartest guy in the room has already an offer from another employer where he will make the very same mistake. As long as this doesn't change, and software developers have exactly 0 incentive to write code that's at least "not garbage", please enjoy your bugs.

move-on-by 3y ago
From a legal sense- at least in the USA- we are not engineers. Actual engineers must pass a FE (Fundamentals of Engineering) exam. After 4 years working under a Professional Engineer, you can apply to take the PE exam and become a Professional Engineer as well- with the ability to ‘stamp’ (approve) designs. That is when you are liable. There are continuing education requirements to maintain the status. Rules vary by state, and some states have reciprocity agreements. Until we have that for software ‘engineering’, we are not engineers and do not have the same requirements and liabilities.
tracker1 3y ago
If you can convince someone to go back to 1960's models and pay for software development where planning is literally measured in years for what gets done in a few months today, more power to you. I don't mean to be completely snarky, but that's the reality of it.. most software isn't a skyscraper, or even a medical device of vehicle.. most software is CRUD with some business rules thrown in. A given system goes down it's an inconvenience but nobody actually dies. You aren't going to hire a team of architects to design and review a dog house. And if you think the latter can't apply to physical things, look at some of the case reviews from Gamer's Nexus... many are literally unfit for their own duty. A recent NAS case review on a different channel showed it had to be Dremel modified in order to even work. Similar for the NAS case recently used by DeBauer. It actually happens plenty with physical goods. The comparison really bugs me. It does indeed bug me when there's a direct connection from the entertainment system in a car and the drive train, for example... that isn't abstracted away via physical device + api. Similar can be said for some decisions with Aerospace equipment. In the end, can you name the engineer that is never working again because the accelerator in some car models tended to get stuck? I can't.
- not_your_vase 3y ago
  "It crap, but at least it is generated fast" - cool. Cars are a bit special in this regard. When a house is built, it's architect will be registered, and punished, if needed. When a car is created, it is created by a brand, like Ford. When there is a recall, you only hear that it's Ford's or Tesla's fault. But at the moment when they see that there is a problem, they will frantically search in change history to see who caused the problem. If you think that this person gets a raise instead of a permanent burger flipping job at a McDonald's, then I got a nice bridge to sell that you might be interested in.
  - tracker1 3y ago
    Feel free to start your own development company, doing things how you suggest and get or provide the funding as you like. I wish you all the best in such and endeavor.
PoignardAzur 3y ago
> Software Engineer, "Engineerius Softwarus Sapiens Sapiens Sapiens Sapiens" - If they make a fatal mistake, especially one that can be avoided with best practices, there will be a blameless post mortem/retrospective where everyone gets a pat on the back, exclaiming "what a great job everyone did, this was really unavoidable, if we disregard the fact that it was completely avoidable". The smartest guy in the room has already an offer from another employer where he will make the very same mistake. Oh come on. The point of a blameless post-mortem is to avoid ass-covering and other concealment of critical information from the responsible parties. It's not about patting yourself on the back, it's about creating an environment where mistakes can be quickly identified and fixed. If you're of the mindset that the only way to create a safe system is to put a gun to the engineer's head, then yeah, that's a bad deal. If you're of the mindset that human errors will happen no matter how much you intimidate and punish your engineers, your priority becomes figuring out processes that are resilient to human error, and blameless post-mortems are a part of that.
jiggawatts 3y ago
I have an email in my inbox just this morning from a developer with the magic phrase “I just want to…” in it. I mentally auto complete the suffix as: “disregard security requirements, ignore best practices, cut corners, do the needful at someone else’s expense, etc…” There is no scenario where the rest of the sentence is “…do the right thing.” I get an email like this weekly at a minimum. This one is asking to punch an unauthorised, unauthenticated, unaudited path from the Internet to legacy servers on the network that will go end-of-life in a month. Exposing the gooey vulnerable insides of a huge network to direct attack. I’ll politely refuse. He’ll just go to someone else, who won’t refuse. You can assume the same scenario plays out every few seconds world-wide. It might be code review, or using a hard-coded credential “just for now”, or whatever. This is the typical reality of software development. From what I’ve heard, embedded and industrial control software is worse still.
- midoridensha 3y ago
  >From what I’ve heard, embedded and industrial control software is worse still. Avionics software is not like this at all. There's a reason you never hear about software failures in airplanes. (Before some wise-ass says something about the Boeing MCAS in the 737MAX, that wasn't a software failure. The software worked perfectly, flying the planes into the ground exactly was it was designed to do by the systems engineers and corporate executives who conceived of MCAS and thought it'd be a great idea to take input from a single sensor.) Industrial control software is pretty bad though.
- rbreaves 3y ago
  You sound like a bundle of joy. To me it all depends on the situation - but I’ve dealt w/ network engineers that really had no business being over it or any real understanding of Linux, ssh, tunnels, etc. He was constantly ignoring my work related requests that absolutely needed resolution in 4-48hrs so I just stopped communicating w/ him. The moment I gained access to a staging server that wasn’t locked down to hell & back I forwarded whatever ports & level of access that I needed. It’d have served the company better to give me the permissions to open up ports & access as I needed in the first place, devs need access to what they’re dev’ing or running against but given the level of quality people I was dealing w/ I just gave up & granted myself access in other ways vs opening up support tickets all the time. I did recently gain access to an employee that was on it though & used common sense - sadly they’ve resigned & I don’t know why but I do know it’s a HUGE loss. They had some amazing side projects going on too - the guy was valuable imo & an effort to keep him should have been made if it hadn’t.

move-on-by 3y ago

From a legal sense- at least in the USA- we are not engineers. Actual engineers must pass a FE (Fundamentals of Engineering) exam. After 4 years working under a Professional Engineer, you can apply to take the PE exam and become a Professional Engineer as well- with the ability to ‘stamp’ (approve) designs. That is when you are liable. There are continuing education requirements to maintain the status. Rules vary by state, and some states have reciprocity agreements. Until we have that for software ‘engineering’, we are not engineers and do not have the same requirements and liabilities.

tracker1 3y ago

If you can convince someone to go back to 1960's models and pay for software development where planning is literally measured in years for what gets done in a few months today, more power to you. I don't mean to be completely snarky, but that's the reality of it.. most software isn't a skyscraper, or even a medical device of vehicle.. most software is CRUD with some business rules thrown in. A given system goes down it's an inconvenience but nobody actually dies. You aren't going to hire a team of architects to design and review a dog house. And if you think the latter can't apply to physical things, look at some of the case reviews from Gamer's Nexus... many are literally unfit for their own duty. A recent NAS case review on a different channel showed it had to be Dremel modified in order to even work. Similar for the NAS case recently used by DeBauer. It actually happens plenty with physical goods. The comparison really bugs me. It does indeed bug me when there's a direct connection from the entertainment system in a car and the drive train, for example... that isn't abstracted away via physical device + api. Similar can be said for some decisions with Aerospace equipment. In the end, can you name the engineer that is never working again because the accelerator in some car models tended to get stuck? I can't.

not_your_vase 3y ago
"It crap, but at least it is generated fast" - cool. Cars are a bit special in this regard. When a house is built, it's architect will be registered, and punished, if needed. When a car is created, it is created by a brand, like Ford. When there is a recall, you only hear that it's Ford's or Tesla's fault. But at the moment when they see that there is a problem, they will frantically search in change history to see who caused the problem. If you think that this person gets a raise instead of a permanent burger flipping job at a McDonald's, then I got a nice bridge to sell that you might be interested in.
- tracker1 3y ago
  Feel free to start your own development company, doing things how you suggest and get or provide the funding as you like. I wish you all the best in such and endeavor.

PoignardAzur 3y ago

> Software Engineer, "Engineerius Softwarus Sapiens Sapiens Sapiens Sapiens" - If they make a fatal mistake, especially one that can be avoided with best practices, there will be a blameless post mortem/retrospective where everyone gets a pat on the back, exclaiming "what a great job everyone did, this was really unavoidable, if we disregard the fact that it was completely avoidable". The smartest guy in the room has already an offer from another employer where he will make the very same mistake. Oh come on. The point of a blameless post-mortem is to avoid ass-covering and other concealment of critical information from the responsible parties. It's not about patting yourself on the back, it's about creating an environment where mistakes can be quickly identified and fixed. If you're of the mindset that the only way to create a safe system is to put a gun to the engineer's head, then yeah, that's a bad deal. If you're of the mindset that human errors will happen no matter how much you intimidate and punish your engineers, your priority becomes figuring out processes that are resilient to human error, and blameless post-mortems are a part of that.

jiggawatts 3y ago

I have an email in my inbox just this morning from a developer with the magic phrase “I just want to…” in it. I mentally auto complete the suffix as: “disregard security requirements, ignore best practices, cut corners, do the needful at someone else’s expense, etc…” There is no scenario where the rest of the sentence is “…do the right thing.” I get an email like this weekly at a minimum. This one is asking to punch an unauthorised, unauthenticated, unaudited path from the Internet to legacy servers on the network that will go end-of-life in a month. Exposing the gooey vulnerable insides of a huge network to direct attack. I’ll politely refuse. He’ll just go to someone else, who won’t refuse. You can assume the same scenario plays out every few seconds world-wide. It might be code review, or using a hard-coded credential “just for now”, or whatever. This is the typical reality of software development. From what I’ve heard, embedded and industrial control software is worse still.

midoridensha 3y ago
>From what I’ve heard, embedded and industrial control software is worse still. Avionics software is not like this at all. There's a reason you never hear about software failures in airplanes. (Before some wise-ass says something about the Boeing MCAS in the 737MAX, that wasn't a software failure. The software worked perfectly, flying the planes into the ground exactly was it was designed to do by the systems engineers and corporate executives who conceived of MCAS and thought it'd be a great idea to take input from a single sensor.) Industrial control software is pretty bad though.
rbreaves 3y ago
You sound like a bundle of joy. To me it all depends on the situation - but I’ve dealt w/ network engineers that really had no business being over it or any real understanding of Linux, ssh, tunnels, etc. He was constantly ignoring my work related requests that absolutely needed resolution in 4-48hrs so I just stopped communicating w/ him. The moment I gained access to a staging server that wasn’t locked down to hell & back I forwarded whatever ports & level of access that I needed. It’d have served the company better to give me the permissions to open up ports & access as I needed in the first place, devs need access to what they’re dev’ing or running against but given the level of quality people I was dealing w/ I just gave up & granted myself access in other ways vs opening up support tickets all the time. I did recently gain access to an employee that was on it though & used common sense - sadly they’ve resigned & I don’t know why but I do know it’s a HUGE loss. They had some amazing side projects going on too - the guy was valuable imo & an effort to keep him should have been made if it hadn’t.