Re: skill churn
I got the impression that there is much less of this in lower level languages. It seems like there is a fairly stable foundation of C, Cpp that everything else is built on top of. I wonder if embedded programmers have this problem.
I got the impression that there is much less of this in lower level languages. It seems like there is a fairly stable foundation of C, Cpp that everything else is built on top of. I wonder if embedded programmers have this problem.
Not only the lower level languages, but fundamental skills in general, I think. Undertanding the computer from the hardware level, OS level as well network protocols, filesystems etc tend to continue to provide benefits even if one fashionable technology is replaced by another.
Similarly, fully undertanding algorithms, data structures, design patterns and architectural patterns also generalize, provided you DO understand these concepts with their strengths, weaknesses, and when to use them and not use them.
If you have the skills above (+ some math and general troubleshooting ability), you are able to approach most software/compute problems from first principles. If so, you may find that you are able to take up senior roles even involving technology you have not used before, as long as the tech introduces few new fundamental ideas. (And if there are new fundamental ideas, you need to learn those to keep up, but such ideas arrive much more rarely than new tech).
People who do not learn these things from first principles, but instead are memorizing patterns they learn from other people, have to do a lot of new memorization when new tech becomes fashionable.
Not only does that take a lot of effort, it also makes it unlikely that they will be able to identify antipatterns by themselves, and it may cause them to end up trying to use the new and fashionable tech in ways it is not suitable for.
I think market pressures make this a difficult fit in the workplace. High turnover (~2yrs) and larger systems encourage shorter term results with a shallower understanding.
This isn’t a criticism (I have so so much to learn still, I’m in no position to judge, nor do I want to be), but more of an observation. Balancing learning churn(frameworks/languages) vs fundamentals(theory, concepts) is a struggle I think I will have for the rest of my life.
But will you be hired for those roles? Not that many companies will do that I think.
Also, some of the companies that hire look precisely for such abilities.
We have been trying to use Rust for some new projects but cross-compiling is still much more hit-and-miss with Rust (i.e. third-party libraries) than it is with C. I imagine it would be worse for proper embedded projects.
But the language does bring benefits. In my experience modern strongly typed languages with large standard libraries and nice tooling are more productive than C (and probably more than C++, although writing idiomatic modern C++ is quite nice). C's simplicity is nice, but it still exists in a world where your only option for 3rd party libraries are zips downloaded from some random Sourceforge. Trying to write a C program with effective string handling is an absolute nightmare. All those things are solved many times over in other languages.
As a tool for writing very low level routines handling fixed length data, C is pretty good. But embedded development is moving away from that - every project seems to have some sort of web API, and that's when the downsides of C really start to show themselves.