3 ms·

German here. From my perspective it's hard to find - embedded systems programmers, meaning people who know real-time systems, have good C/C++ knowledge, know t

by deng 6y ago

German here. From my perspective it's hard to find - embedded systems programmers, meaning people who know real-time systems, have good C/C++ knowledge, know their way around the Linux kernel and are also able to do basic things with a scope. - good(!) C++ programmers in general - people who know devops and software development infrastructure C++ might not be sexy, but there's a vast amount of legacy software out there which is not going away anytime soon.

jeffreygoesto 6y ago
That is true. I found that for embedded C++ to be successful, you need to have some good (excellent sometimes was harmful, but that's a different topic) C++ _as well as_ good domain and optimization skills. It's a combination that is more and more scarce. C++ tends to be used in domains where size and speed matter. You need to know what the compiler and machine will do with your code to be fast. And what's more, only the domain knowledge will let you pick the right data structures to be fast and compact in the first place. And there are a lot of foot guns around... ;-)
- wallscratch 6y ago
  > I found that for embedded C++ to be successful, you need to have some good (excellent sometimes was harmful, but that's a different topic) Why were excellent C++ skills sometimes harmful?
  - jeffreygoesto 6y ago
    First of all, it leaves the team behind if you use features that are too advanced. Makes collaboration hard if you have wildly diverging skills (in both ways). Also, it did in our case take you away so far from the bare metal, that the code was elegant, but slow. It did not play well with our static allocators and allocated/deallocated way too much, especially temporaries. You might i.e. check out talks like [0]. [0] https://m.youtube.com/watch?v=NH1Tta7purM https://m.youtube.com/watch?v=NH1Tta7purM
    - deng 6y ago
      I agree. Another thing to consider is portability. You might have to port your software to obscure platforms with bad C++ compilers where compiler bugs are not uncommon at all, so it's better to stay clear of more advanced features. Also, you might have a legacy system which does not have modern C++ compilers, so you might have to restrict yourself to C++03. Another thing is code size, so templates should be used judiciously.
      - dmurray 6y ago
        These replies both don't seem like they describe someone with "excellent" C++ skills. Sounds more like someone who knows a lot of advanced features of the language, but doesn't make the correct tradeoffs considering portability and/or performance. Maybe it could be that he didn't know all the requirements up front and his mediocre colleague accidentally wrote code that better suited the company's unstated requirements (e.g. portability to niche systems). But that's hardly the most likely explanation.
        jeffreygoesto 6y ago
        Ah, ok. In my head I do have a distinction between excellent C++ and excellent domain skills. So that person had excellent C++ skills but did not properly choose which C++ subset to use for the domain. From your comment I think you would say "excellent" implies "in all relevant aspects", whereas I just meant the pure programming language. What I tried to write in my first comment is that it is more and more difficult to find both combined in one person.
user5994461 6y ago
It's funny because I have all these (though it's been a few years since I've been doing C++ development daily), yet if I were laid off tomorrow I know from experience it could take me a whole year to find a new job in any of that domain. By the way junior C++ developer is an euphemism because no company will hire a junior C++ developer. It's the most difficult programming languages that can take years of practices/studying to be able to use.
chefkoch 6y ago
But all three are by no means junior.
markus_zhang 6y ago
I think for C++ programmers either you have to pay a premium and hire senior people in their 40s (like 60s and 70s for COBOL), or find someone who is willing to learn and have the patience to get him on road not now, but 3-6 months from now. I feel that it's rare that companies choose the second road so usually they pay a premium.

by deng 6y ago

jeffreygoesto 6y ago

That is true. I found that for embedded C++ to be successful, you need to have some good (excellent sometimes was harmful, but that's a different topic) C++ _as well as_ good domain and optimization skills. It's a combination that is more and more scarce. C++ tends to be used in domains where size and speed matter. You need to know what the compiler and machine will do with your code to be fast. And what's more, only the domain knowledge will let you pick the right data structures to be fast and compact in the first place. And there are a lot of foot guns around... ;-)

wallscratch 6y ago
> I found that for embedded C++ to be successful, you need to have some good (excellent sometimes was harmful, but that's a different topic) Why were excellent C++ skills sometimes harmful?
- jeffreygoesto 6y ago
  First of all, it leaves the team behind if you use features that are too advanced. Makes collaboration hard if you have wildly diverging skills (in both ways). Also, it did in our case take you away so far from the bare metal, that the code was elegant, but slow. It did not play well with our static allocators and allocated/deallocated way too much, especially temporaries. You might i.e. check out talks like [0]. [0] https://m.youtube.com/watch?v=NH1Tta7purM https://m.youtube.com/watch?v=NH1Tta7purM
  - deng 6y ago
    I agree. Another thing to consider is portability. You might have to port your software to obscure platforms with bad C++ compilers where compiler bugs are not uncommon at all, so it's better to stay clear of more advanced features. Also, you might have a legacy system which does not have modern C++ compilers, so you might have to restrict yourself to C++03. Another thing is code size, so templates should be used judiciously.
    - dmurray 6y ago
      These replies both don't seem like they describe someone with "excellent" C++ skills. Sounds more like someone who knows a lot of advanced features of the language, but doesn't make the correct tradeoffs considering portability and/or performance. Maybe it could be that he didn't know all the requirements up front and his mediocre colleague accidentally wrote code that better suited the company's unstated requirements (e.g. portability to niche systems). But that's hardly the most likely explanation.
      - jeffreygoesto 6y ago
        Ah, ok. In my head I do have a distinction between excellent C++ and excellent domain skills. So that person had excellent C++ skills but did not properly choose which C++ subset to use for the domain. From your comment I think you would say "excellent" implies "in all relevant aspects", whereas I just meant the pure programming language. What I tried to write in my first comment is that it is more and more difficult to find both combined in one person.

user5994461 6y ago

It's funny because I have all these (though it's been a few years since I've been doing C++ development daily), yet if I were laid off tomorrow I know from experience it could take me a whole year to find a new job in any of that domain. By the way junior C++ developer is an euphemism because no company will hire a junior C++ developer. It's the most difficult programming languages that can take years of practices/studying to be able to use.

chefkoch 6y ago

But all three are by no means junior.

markus_zhang 6y ago

I think for C++ programmers either you have to pay a premium and hire senior people in their 40s (like 60s and 70s for COBOL), or find someone who is willing to learn and have the patience to get him on road not now, but 3-6 months from now. I feel that it's rare that companies choose the second road so usually they pay a premium.