5 ms·

I've been saying this about hardware engineers since forever. If a hardware engineer tells you they're a good software engineer they're going to be a problem. I

I've been saying this about hardware engineers since forever. If a hardware engineer tells you they're a good software engineer they're going to be a problem. I guess one day I'll find a unicorn, but practically always it's massive red flag. It just begs the question in which way are they flawed: Do they write shit software and think it's great? Do they have so little experience that they think that software is simple? Do they just disregard everyone else's skillset? Do they fundamentally not understand their own limits? What is it that leads them to make such an utterly silly claim?

deleted 3y ago
[deleted]
ZephyrBlu 3y ago
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?
- wadd1e 3y ago
  >classic underestimating a domain you have no understanding of 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.
- rgbgraph 3y ago
  Same reason we (SW engineers) think X field is easy and can be self-taught: the fundamentals are easy to learn, but figuring out where and how to deal with edge cases when they pop up is something that can only be learned with experience. 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.
  - nullityrofl 3y ago
    > Same reason we (SW engineers) think X field is easy and can be self-taught: the fundamentals are easy to learn, but figuring out where and how to deal with edge cases when they pop up is something that can only be learned with experience. Ironic post from the person who thinks Reddit would be trivial to recreate. Your whole account reads like a parody. https://news.ycombinator.com/item?id=36147180 https://news.ycombinator.com/item?id=36147180
    - rgbgraph 3y ago
      I've worked on problems much harder than Reddit. Reddit is a trivial problem.
- lordnacho 3y ago
  There's probably a danger in commenting on adjacent fields. If you're a HW guy and you write some software to exercise your hardware, you might think it's easy because you've only stepped one layer into the interface. 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.
- SilverBirch 3y ago
  Well, I see it from the hardware engineering side because I'm a hardware engineer who works closely with software engineers and have read one too many CV that lists "C/C++" as language, normally "So, tell me about SFINAE" or "Explain RAII" is enough to cut through that pretty quick. 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.
  - deredede 3y ago
    RAII is a good question to weed out inexperienced C++ programmers, but I don't think asking about SFINAE is a very good interview question, unless the job involves heavy template metaprogramming, and even then it is such an obscure name for a fairly intuitive concept ("yeah so the compiler will only use the template definitions that work") I am sure there are many people good at template metaprogramming that don't know the term. Edit: changed "incompetent" to "inexperienced" as it better reflect my opinion.
    - SilverBirch 3y ago
      It's not a pure "if you don't know SFINAE you're out" but it gives you a very strong indication of which parts of the language they're actually familiar with (although maybe it's a little dated now), and for a lot of candidates you could go through a list of dozens of these acronyms and they wouldn't be able to reasonably identify any of them.
  - orwin 3y ago
    I'm pretty sure my brother doesn't know what RAII is, but he's a way better C++ developer than me. 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).
- michaelt 3y ago
  In the vast majority of fields of engineering, it's possible to exhaustively test your product. 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.
  - rcxdude 3y ago
    I wouldn't say this is actually true: while there are generally fewer dimensions in hardware testing, it's not actually a given that if you have tested over the range in each of them that you will certainly be OK across the entire space (in the same way that having unit tested each of your functions at extremes doesn't mean the whole system will work as intended), not to mention it's not very common that you actually have anywhere near proper coverage of each of those dimensions (and don't get me started on lifetime and aging testing). Also, testing is often very expensive so it's also very common that you don't actually have test results for the version you're actually building (one of the reasons safety critical hardware is so expensive is because regulations generally require you do this as opposed to handwaving). (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)
    - michaelt 3y ago
      > I wouldn't say this is actually true: while there are generally fewer dimensions in hardware testing, it's not actually a given that if you have tested over the range in each of them that you will certainly be OK across the entire space 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.
iainmerrick 3y ago
I'm a software developer who's led some embedded development projects in the past, and I definitely know where you're coming from. There are hardware developers who are fantastic at some parts of software development, but other parts require totally different skills. In my projects, where we partly used DSPs and software-defined radio, I found that the hardware guys could be amazing at writing neat modules of DSP assembly, with carefully benchmarked time and space usage. I felt that they thought "hey, software is easy, it's just wiring a bunch of filters together!" But for anything requiring more sophisticated architecture (like interpreting an EPG embedded in the data stream) they wrote spaghetti code. Often their stuff would be nice and terse, so it could look good at first glance if you didn't really understand software. Some parts would be efficient but buggy; other parts would be correct but with terrible scaling or arbitrary size limits. Similarly, I'm sure if I tried to get involved in hardware, and confidently thought "this is easy, it's just wiring a bunch of functions together!", I might get some of the small stuff right, but the actual higher-level hardware architecture would be equally terrible.
- Vanit 3y ago
  This is reminding me of similar issues I've had with engineers that have been stuck in the backend bubble too long. They seem to operate in a constraint free environment and it's other devs who have to live with the awkward limitations the backend dev thought "is the right way".
  - bob1029 3y ago
    You can solve this problem by performing schema design with stakeholders in the loop. If everyone agrees upon the tables/columns/relations ahead of time, then constraints can be enforced before any code is touched.
  - wellanyway 3y ago
    Backend bubble as opposed to what? JS apps that require 6 gigabybes to render some text?
giraffe_lady 3y ago
> Do they just disregard everyone else's skillset? If there is one thing I would consider the hallmark of a programmer this is it.
shapefrog 3y ago
People who are honest about their skills dont get the job. People who say they are the living embodiment of sunshine and rainbows get the job. They say it as it is the correct answer in an interview, maybe they believe it, maybe they dont - they however are saying the things that they need to say to be employable.
Sarkie 3y ago
The worst C++/C# code I've ever seen that wasn't a student was hardware engineers. Device Drivers are a minefield.
- gpderetta 3y ago
  I bet that Hardware Engineers have nothing on PhD students :)
deleted 3y ago
[deleted]

deleted 3y ago

[deleted]

ZephyrBlu 3y ago

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?

wadd1e 3y ago
>classic underestimating a domain you have no understanding of 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.
rgbgraph 3y ago
Same reason we (SW engineers) think X field is easy and can be self-taught: the fundamentals are easy to learn, but figuring out where and how to deal with edge cases when they pop up is something that can only be learned with experience. 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.
- nullityrofl 3y ago
  > Same reason we (SW engineers) think X field is easy and can be self-taught: the fundamentals are easy to learn, but figuring out where and how to deal with edge cases when they pop up is something that can only be learned with experience. Ironic post from the person who thinks Reddit would be trivial to recreate. Your whole account reads like a parody. https://news.ycombinator.com/item?id=36147180 https://news.ycombinator.com/item?id=36147180
  - rgbgraph 3y ago
    I've worked on problems much harder than Reddit. Reddit is a trivial problem.
lordnacho 3y ago
There's probably a danger in commenting on adjacent fields. If you're a HW guy and you write some software to exercise your hardware, you might think it's easy because you've only stepped one layer into the interface. 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.
SilverBirch 3y ago
Well, I see it from the hardware engineering side because I'm a hardware engineer who works closely with software engineers and have read one too many CV that lists "C/C++" as language, normally "So, tell me about SFINAE" or "Explain RAII" is enough to cut through that pretty quick. 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.
- deredede 3y ago
  RAII is a good question to weed out inexperienced C++ programmers, but I don't think asking about SFINAE is a very good interview question, unless the job involves heavy template metaprogramming, and even then it is such an obscure name for a fairly intuitive concept ("yeah so the compiler will only use the template definitions that work") I am sure there are many people good at template metaprogramming that don't know the term. Edit: changed "incompetent" to "inexperienced" as it better reflect my opinion.
  - SilverBirch 3y ago
    It's not a pure "if you don't know SFINAE you're out" but it gives you a very strong indication of which parts of the language they're actually familiar with (although maybe it's a little dated now), and for a lot of candidates you could go through a list of dozens of these acronyms and they wouldn't be able to reasonably identify any of them.
- orwin 3y ago
  I'm pretty sure my brother doesn't know what RAII is, but he's a way better C++ developer than me. 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).
michaelt 3y ago
In the vast majority of fields of engineering, it's possible to exhaustively test your product. 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.
- rcxdude 3y ago
  I wouldn't say this is actually true: while there are generally fewer dimensions in hardware testing, it's not actually a given that if you have tested over the range in each of them that you will certainly be OK across the entire space (in the same way that having unit tested each of your functions at extremes doesn't mean the whole system will work as intended), not to mention it's not very common that you actually have anywhere near proper coverage of each of those dimensions (and don't get me started on lifetime and aging testing). Also, testing is often very expensive so it's also very common that you don't actually have test results for the version you're actually building (one of the reasons safety critical hardware is so expensive is because regulations generally require you do this as opposed to handwaving). (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)
  - michaelt 3y ago
    > I wouldn't say this is actually true: while there are generally fewer dimensions in hardware testing, it's not actually a given that if you have tested over the range in each of them that you will certainly be OK across the entire space 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.

iainmerrick 3y ago

I'm a software developer who's led some embedded development projects in the past, and I definitely know where you're coming from. There are hardware developers who are fantastic at some parts of software development, but other parts require totally different skills. In my projects, where we partly used DSPs and software-defined radio, I found that the hardware guys could be amazing at writing neat modules of DSP assembly, with carefully benchmarked time and space usage. I felt that they thought "hey, software is easy, it's just wiring a bunch of filters together!" But for anything requiring more sophisticated architecture (like interpreting an EPG embedded in the data stream) they wrote spaghetti code. Often their stuff would be nice and terse, so it could look good at first glance if you didn't really understand software. Some parts would be efficient but buggy; other parts would be correct but with terrible scaling or arbitrary size limits. Similarly, I'm sure if I tried to get involved in hardware, and confidently thought "this is easy, it's just wiring a bunch of functions together!", I might get some of the small stuff right, but the actual higher-level hardware architecture would be equally terrible.

Vanit 3y ago
This is reminding me of similar issues I've had with engineers that have been stuck in the backend bubble too long. They seem to operate in a constraint free environment and it's other devs who have to live with the awkward limitations the backend dev thought "is the right way".
- bob1029 3y ago
  You can solve this problem by performing schema design with stakeholders in the loop. If everyone agrees upon the tables/columns/relations ahead of time, then constraints can be enforced before any code is touched.
- wellanyway 3y ago
  Backend bubble as opposed to what? JS apps that require 6 gigabybes to render some text?

giraffe_lady 3y ago

> Do they just disregard everyone else's skillset? If there is one thing I would consider the hallmark of a programmer this is it.

shapefrog 3y ago

People who are honest about their skills dont get the job. People who say they are the living embodiment of sunshine and rainbows get the job. They say it as it is the correct answer in an interview, maybe they believe it, maybe they dont - they however are saying the things that they need to say to be employable.

Sarkie 3y ago

The worst C++/C# code I've ever seen that wasn't a student was hardware engineers. Device Drivers are a minefield.

gpderetta 3y ago
I bet that Hardware Engineers have nothing on PhD students :)

deleted 3y ago

[deleted]