5 ms·

Embedded jobs usually get listed as C/C++, and most of the C developers I know stay away from them.

by yayana 8y ago

yitchelle 8y ago
Why? I could guess that these jobs are not as "sexy" as using Java, Python etc?
- tom_mellior 8y ago
  I think your parent was saying that people using the term "C/C++" are often muddy on the considerable differences between these two languages, and that it is a red flag in a job description if the company cannot even manage to properly name the language they use.
  - gameswithgo 8y ago
    If you are pedantic enough that you get irritated by "C/C++", which clearly denotes that they understand they are different languages, and only implies they may disagree with you on how much crossover knowledge there is, you probably won't be happy anywhere on earth except maybe the linux kernel team.
    - tom_mellior 8y ago
      Back when I was reading comp.lang.c, people would often wonder by to ask for help with their "C/C++" programs which typically turned out to be C++. Such people were usually surprised when it was pointed out to them that they were in a C newsgroup and that that is a different language from C++. The confusion was widespread. It may have changed, but I wouldn't really expect that to be the case.
    - sacado2 8y ago
      Not parent but I tend to think there are broadly 3 "languages", with 3 very different cultures and mindset: - C, which is, well, pure, raw C, - C++, which tends to gravitate toward modern C++ (C++11 and later), and focuses on avoiding C constructs (except when needed, eg for legacy reasons), - the so-called C/C++, which is C with a small subset of C++98 constructs, mainly classes, the public/private distinction, the string type, references, and not much more For a purist (either a C purist or a C++ purist), the third category feels like losing most advantages of the original language (simplicity and orthogonality of C, relative safety and expressiveness of C++) and getting drawbacks of both (name mangling and dangling pointers, both at the same time, yay!) For me, it would not be a red flag, but definitely a yellow one.
  - yitchelle 8y ago
    But surely that is a function of the recruiter and not a function of the employer. Most recruiters are clueless about the technology they are recruiting for.
    - fiedzia 8y ago
      Not in my experience. Recruiters may be clueless, but they will only pass what was given to them. Companies with well-defined requirements will either make sure they have recruiters who understand what they require or copy it precisely, or don't use recruiters as much and rely on communicating with developers directly. I had way better experience with those who say "you will be working on a project involving mainly X and maybe some Y" than ads stating "we are looking for C, Scala, CSS etc.". Some of course say "we have range of project and we want polyglots", but if they don't, its definitely lack of care and understanding of technology.
- user5994461 8y ago
  It's a pain to develop in C and it's an order of magnitude more pain to develop in embedded. You're looking forward to development tools that have neither refactoring nor auto completion. I have yet to see an embedded micro controller with an API documentation and working examples.
  - scns 8y ago
    Clion?
  - simias 8y ago
    That's part of the fun of it for me. Getting close to the metal, having to worry about electronics, debugging with an oscilloscope or, if you're lucky, an UART etc... Regarding development tools that's a bit orthogonal, you can code for your 8bit AVR controller with Visual Studio if you really want to. Personally I don't care much for full blown IDEs and automatic refactoring so I use Emacs with dumb completion and cscope/ctags and I'm good to go but to each their own. If you like quick prototyping and are used to develop iteratively through heavy use of the debugger I can see how it could be incredibly frustrating though. It's a different mindset and a different approach. Still, as far as I'm concerned I wouldn't trade it for all the JS jobs in the world.
    - user5994461 8y ago
      The electronics and oscilloscope is the funnier part but that doesn't help with software development. For some microcontollers and FPGA I had to work with, there is hardly any API documentation. It could take a whole week just to figure out how to blink a LED. It's frustrating. There is zero help available on the internet because nobody uses that. It comes with its own tool chain and there isn't the option to use something else, like CLion or Visual Studio. I'm supposed to make some home automation devices, or an inertial navigation system, or god knows that. It's enough work on its own, I don't have time or energy to fight broken tools. By comparison, android development is a wonder. Development tools that work, long form documentation of every single API and guides and examples. Just plug the USB port and the program loads and it shows debugging output and you can debug line by line and use breakpoints. Having used better development tools, I just have higher standard. I can't tolerate embedded anymore. I hope there are some working tools for some chips of some manufacturers nowadays, but wouldn't know.

Embedded jobs usually get listed as C/C++, and most of the C developers I know stay away from them.

by yayana 8y ago

Embedded jobs usually get listed as C/C++, and most of the C developers I know stay away from them.

yitchelle 8y ago

Why? I could guess that these jobs are not as "sexy" as using Java, Python etc?

tom_mellior 8y ago
I think your parent was saying that people using the term "C/C++" are often muddy on the considerable differences between these two languages, and that it is a red flag in a job description if the company cannot even manage to properly name the language they use.
- gameswithgo 8y ago
  If you are pedantic enough that you get irritated by "C/C++", which clearly denotes that they understand they are different languages, and only implies they may disagree with you on how much crossover knowledge there is, you probably won't be happy anywhere on earth except maybe the linux kernel team.
  - tom_mellior 8y ago
    Back when I was reading comp.lang.c, people would often wonder by to ask for help with their "C/C++" programs which typically turned out to be C++. Such people were usually surprised when it was pointed out to them that they were in a C newsgroup and that that is a different language from C++. The confusion was widespread. It may have changed, but I wouldn't really expect that to be the case.
  - sacado2 8y ago
    Not parent but I tend to think there are broadly 3 "languages", with 3 very different cultures and mindset: - C, which is, well, pure, raw C, - C++, which tends to gravitate toward modern C++ (C++11 and later), and focuses on avoiding C constructs (except when needed, eg for legacy reasons), - the so-called C/C++, which is C with a small subset of C++98 constructs, mainly classes, the public/private distinction, the string type, references, and not much more For a purist (either a C purist or a C++ purist), the third category feels like losing most advantages of the original language (simplicity and orthogonality of C, relative safety and expressiveness of C++) and getting drawbacks of both (name mangling and dangling pointers, both at the same time, yay!) For me, it would not be a red flag, but definitely a yellow one.
- yitchelle 8y ago
  But surely that is a function of the recruiter and not a function of the employer. Most recruiters are clueless about the technology they are recruiting for.
  - fiedzia 8y ago
    Not in my experience. Recruiters may be clueless, but they will only pass what was given to them. Companies with well-defined requirements will either make sure they have recruiters who understand what they require or copy it precisely, or don't use recruiters as much and rely on communicating with developers directly. I had way better experience with those who say "you will be working on a project involving mainly X and maybe some Y" than ads stating "we are looking for C, Scala, CSS etc.". Some of course say "we have range of project and we want polyglots", but if they don't, its definitely lack of care and understanding of technology.
user5994461 8y ago
It's a pain to develop in C and it's an order of magnitude more pain to develop in embedded. You're looking forward to development tools that have neither refactoring nor auto completion. I have yet to see an embedded micro controller with an API documentation and working examples.
- scns 8y ago
  Clion?
- simias 8y ago
  That's part of the fun of it for me. Getting close to the metal, having to worry about electronics, debugging with an oscilloscope or, if you're lucky, an UART etc... Regarding development tools that's a bit orthogonal, you can code for your 8bit AVR controller with Visual Studio if you really want to. Personally I don't care much for full blown IDEs and automatic refactoring so I use Emacs with dumb completion and cscope/ctags and I'm good to go but to each their own. If you like quick prototyping and are used to develop iteratively through heavy use of the debugger I can see how it could be incredibly frustrating though. It's a different mindset and a different approach. Still, as far as I'm concerned I wouldn't trade it for all the JS jobs in the world.
  - user5994461 8y ago
    The electronics and oscilloscope is the funnier part but that doesn't help with software development. For some microcontollers and FPGA I had to work with, there is hardly any API documentation. It could take a whole week just to figure out how to blink a LED. It's frustrating. There is zero help available on the internet because nobody uses that. It comes with its own tool chain and there isn't the option to use something else, like CLion or Visual Studio. I'm supposed to make some home automation devices, or an inertial navigation system, or god knows that. It's enough work on its own, I don't have time or energy to fight broken tools. By comparison, android development is a wonder. Development tools that work, long form documentation of every single API and guides and examples. Just plug the USB port and the program loads and it shows debugging output and you can debug line by line and use breakpoints. Having used better development tools, I just have higher standard. I can't tolerate embedded anymore. I hope there are some working tools for some chips of some manufacturers nowadays, but wouldn't know.