Do you think there is something specifically about HW eng thinking SW eng is easy, or just the classic underestimating a domain you have no understanding of?
I think a massive part of it is that Software Engineering is better than hardware engineering. The software engineers are great! They have all these tools and documentation and they're free and open source! So there's no barrier to entry for a hardware engineer to pick up C++. But if a software engineer wants to pick up like Verilog for example... Well firstly, you're going to need expensive hardware, secondly the tooling is all closed source propriety and costs thousands to license. Oh, and there's no CI, the debuggers are tcl based tools from the 90s. etc. etc.
A hardware engineer can pick up software tools and solve the tiny part of the orchestration that needs to be done in software easily, but there's no equivalent where a software engineer would pick up hardware.
Edit: changed "incompetent" to "inexperienced" as it better reflect my opinion.
The principle of scope, and scope-bound (and scope-bound objects) really took of recently, and i'm pretty sure a better name than RAII exists now (especially since RAII doesn't mention deletion, and resource deletion is litterally the point of RAII).
He might know about SFINAE, i didnt (but i never got into C++ metaprogramming, and he did).
"recently"? - you are joking. i suspect that neither you nor your brother know much at all about c++. RAII and scope are both core ideas in c++ and always have been.
I would say that's debatable. RAII definitely dates back to the earliest days of C++, but you don't have to know it in order to use the language. Even today there are many professional C++ devs who've never really learned RAII because they write C with classes style code. I first started learning C++ about 20 years ago and IIRC at the time usage of RAII was still in the minority but there was real momentum towards it being considered the "right" way to do C++.
I'm not claiming that it's good C++ code (or good code by any measure) but I imagine those "C with classes" devs would do something like:
my_string* s = new my_string();
s->initialize("hello world");
// ...
s->destroy();
delete s;Also RAII is not (just) about scope, but bout tying, recursively, the lifetime of a resource to another one. You might even have manual destructor calls at the bottom of the tree, the rest would still be RAII. If it was just about scope, higher order functions would be sufficient.
Your power supply is specified to accept 90v-260v 50-60Hz and deliver 12v at 1 to 20 watts, in ambient temperatures between -5°C and 55°C? You can test over the entire input range, your expert knowledge assuring you that if it's tested at 20°C and 22°C there's no need to test at 21°C.
On the other hand, if your software is specified to correctly validate a SAML assertion? It's simply not possible to enumerate all the states the system might encounter.
(This isn't to say software isn't more complex than hardware: just that I think software engineers have a tendency to romanticize the level of competence and confidence other engineering disciplines have in their designs)
I agree that the point where the power supply dissipates the most power, or the point where it starts making an audible whine, might be in the middle of its operating range rather than at its limits. You would certainly want an experienced engineer who can say what density of parameter sweep is appropriate.
This is what I was trying to say when I said that when testing a system designed to operate between -5°C and 55°C, expert knowledge might assure you there was no need to test at 21°C if it had been tested at 20°C and 22°C successfully.
One way we assess stability is by doing frequency sweeps. What allows us to infer stability from that test is the assumption that the system is linear time invariant (LTI). We assume it's LTI because we tried to design it to mostly act that way, even though it's really not.
For an LTI system, a frequency sweep and a step response are completely equivalent and interchangeable, it doesn't matter which one you use. But what actually happens is the step response test reveals different information. This can only happen if the system is not LTI. Therefore neither test is conclusive about stability, though they're still informative, which is why we do them. 10x density would be no less inclusive.
Another problem is that some stability issues have very low observability. The blip or offset they cause in testing is indistinguishable from normal switching noise and measurement imperfections. They only really reveal themselves when they become a problem in the field. 10x density wouldn't find the issue because it's caused by some other combination.
Explaining and fixing those issues is tough, and anticipating them requires an arsenal of models developed from someone's hard earned experience.
I don't mean to diminish the density issue. That's still a real thing, but it's kind of an orthogonal problem. The formal term is optimal design of experiments, and in simulation we use search methods like Monte Carlo because it's not feasible to enumerate the design space even on a computer, much less in a real test.
Testing doesn't enumerate the physical design space. It only enumerates a model. Only very simple theoretical models can be enumerated in practice. We have to design with much more sophisticated and accurate models that can't be enumerated, and we have to settle for knowing that even those models are inadequate to describe everything we need to account for. We do our best to design in a way that makes the simple, testable models valid and informative, but it's impossible to completely succeed, so we only ever test "enough" (to make money).
It's probably similar in a lot of areas, you stand on the tip of an iceberg and you think you've seen the whole thing.
I see something similar in trading code. You get someone who knows a lot about how markets work, and they figure out that you can hack a few things together in python. Now they're a software engineer.
to be clear I'm not a hw eng myself so I don't have a deep understanding of hw eng, but I have a friend who's studying EE and from what he asks/tells me sometimes, there's a non-trivial amount of coding involved depending on what it is you're working on. So mabye it's because hw engineers may have experience writing lots of code which is non-trivial, but nowhere close to what a sw eng does still, hence giving a wrong impression.
I see the same with a certain subset of finance people who learn Python, and start thinking coding is easy. Yeah, fair you can whip some simple Jupyter notebook using Pandas to analyze time-series. Now build out a distributed, fault-tolerant ETL (CRUD++) system that follows all business rules, is maintainable/readable, and can scale to atleast 100 "servers."
Perhaps not the most apt comparison -- but the fundamentals in every field are easy to learn; but working at the edge is something you have no experience in until you do.
Ironic post from the person who thinks Reddit would be trivial to recreate. Your whole account reads like a parody.