5 ms·

That doesn't make sense to me because car companies hire huge numbers of automotive engineers (I think?) I always thought this was an engineering culture war t

by nmrm2 11y ago

That doesn't make sense to me because car companies hire huge numbers of automotive engineers (I think?) I always thought this was an engineering culture war thing -- software engineers aren't really engineers and software is sort of this silly thing that you use to glue together "real" engineering products. Hopefully the author of your parent post will elaborate some :-) (edit: I assumed you meant business-engineering culture war, not engineering-software. Might've been mistaken upon rereading)

structural 11y ago
The culture war is alive and well, many companies (mine included, unfortunately) treat software engineers as barely qualified typists of the "algorithms" designed by "real engineers". They'd get rid all of them in a second if they could, every so often a new manager tries.
- at-fates-hands 11y ago
  The culture war has been going on forever. When I was growing up in the 80's, my father was a software engineer at Honeywell and said they discriminated against the software guys, even when they knew software was the future of computing. He said it had been going on since the 60's and 70's as related to him by previous employees. He was told if he was a software engineer to just keep his head down and not talk to the "real engineers" working on "real problems". Likewise when I was in college for computer science, he reminded me of the same struggles he had when I used to get fed shit from the other engineering students about how "If all else failed, they could become a CS major." and just be nice because one day they'll be coming to me for help. And here we are today. Same thing, same arguments, same outdated viewpoints.
rwmj 11y ago
Well, unfortunately many software engineers don't behave like real engineers, so is it any surprise? I mean to say, most people here will be highly familiar with version control, but back in the days when I used to audit companies, version control was barely[1] used, and editing files on the live server was the norm. And even here we're still having discussions about how "hard" it is to manage dependencies, use strong typing, use safe languages, garbage collection, bounds checking, formal proofs, etc. [1] I think I may be correct in saying never used. I can't recall a case where we saw a company using any kind of VCS, but perhaps I just forgot.
- ScottBurson 11y ago
  Your criticism is valid from our perspective, but the non-software engineers on the other side of the culture divide are even less aware of proper software practice, so I don't see how the failure of software people to follow those practices could be the source of the prejudice. I think it's a different problem. Software engineering is fundamentally about the management of complexity. People who have only worked on small programs -- like most non-software engineers and scientists -- don't understand the need to manage complexity because they've never worked on any program large enough to require it. Programming in the small is easy, particularly when you're mostly doing numerics. Other engineers see that and think that all programming must be easy.
  - ethbro 11y ago
    Whenever I describe software engineering I typically use some form of "a true software engineer doesn't just make something work, he avoids &#%$ing over the next person to pick up his or her code."
- AnimalMuppet 11y ago
  Funny that you include garbage collection as part of what we should be doing, in an article about software in cars. Garbage collection is almost never the right answer for software in embedded systems.
  - jtc331 11y ago
    Unless the poster was including ARC-style systems in what they meant by "garbage collection". Ideally you want something that is both deterministic (i.e., it's not running randomly in the background like a traditional GC) and that guarantees there are no leaks. In theory ARC gives you both of these.
    - emn13 11y ago
      ARC depends on malloc/free which isn't quite as deterministic as you make it out to be - precisely because malloc/free does not (typically) run in the background, it needs to update internal datastructures when it gets the chance, which can lead to considerable latency spikes. In fact, I'd go so far as to say latency isn't the issue - the issue is that typically GC'd languages rely heavily on heap allocation because it's cheaper(!) not more expensive. Put another way: java creates lots of garbage, C/C++ does not. If you wrote a C/C++ program that allocated as heavily as a typical java program... well, I'd expect performance issues that would probably be worse than java's.

by nmrm2 11y ago

structural 11y ago

The culture war is alive and well, many companies (mine included, unfortunately) treat software engineers as barely qualified typists of the "algorithms" designed by "real engineers". They'd get rid all of them in a second if they could, every so often a new manager tries.

at-fates-hands 11y ago
The culture war has been going on forever. When I was growing up in the 80's, my father was a software engineer at Honeywell and said they discriminated against the software guys, even when they knew software was the future of computing. He said it had been going on since the 60's and 70's as related to him by previous employees. He was told if he was a software engineer to just keep his head down and not talk to the "real engineers" working on "real problems". Likewise when I was in college for computer science, he reminded me of the same struggles he had when I used to get fed shit from the other engineering students about how "If all else failed, they could become a CS major." and just be nice because one day they'll be coming to me for help. And here we are today. Same thing, same arguments, same outdated viewpoints.

rwmj 11y ago

Well, unfortunately many software engineers don't behave like real engineers, so is it any surprise? I mean to say, most people here will be highly familiar with version control, but back in the days when I used to audit companies, version control was barely[1] used, and editing files on the live server was the norm. And even here we're still having discussions about how "hard" it is to manage dependencies, use strong typing, use safe languages, garbage collection, bounds checking, formal proofs, etc. [1] I think I may be correct in saying never used. I can't recall a case where we saw a company using any kind of VCS, but perhaps I just forgot.

ScottBurson 11y ago
Your criticism is valid from our perspective, but the non-software engineers on the other side of the culture divide are even less aware of proper software practice, so I don't see how the failure of software people to follow those practices could be the source of the prejudice. I think it's a different problem. Software engineering is fundamentally about the management of complexity. People who have only worked on small programs -- like most non-software engineers and scientists -- don't understand the need to manage complexity because they've never worked on any program large enough to require it. Programming in the small is easy, particularly when you're mostly doing numerics. Other engineers see that and think that all programming must be easy.
- ethbro 11y ago
  Whenever I describe software engineering I typically use some form of "a true software engineer doesn't just make something work, he avoids &#%$ing over the next person to pick up his or her code."
AnimalMuppet 11y ago
Funny that you include garbage collection as part of what we should be doing, in an article about software in cars. Garbage collection is almost never the right answer for software in embedded systems.
- jtc331 11y ago
  Unless the poster was including ARC-style systems in what they meant by "garbage collection". Ideally you want something that is both deterministic (i.e., it's not running randomly in the background like a traditional GC) and that guarantees there are no leaks. In theory ARC gives you both of these.
  - emn13 11y ago
    ARC depends on malloc/free which isn't quite as deterministic as you make it out to be - precisely because malloc/free does not (typically) run in the background, it needs to update internal datastructures when it gets the chance, which can lead to considerable latency spikes. In fact, I'd go so far as to say latency isn't the issue - the issue is that typically GC'd languages rely heavily on heap allocation because it's cheaper(!) not more expensive. Put another way: java creates lots of garbage, C/C++ does not. If you wrote a C/C++ program that allocated as heavily as a typical java program... well, I'd expect performance issues that would probably be worse than java's.