Comment by willjp

3 years ago

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.

13 comments

willjp

Reply
trashtester  3 years ago

> I got the impression that there is much less of this in lower level languages.

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.

  • willjp  3 years ago

    This is what I’m hoping for. At least, I’ve noticed on the admin side that lower level tools and system calls seem to be more stable and better documented than the abstractions built overtop of them.

    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.

  • bryanrasmussen  3 years ago

    >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.

    But will you be hired for those roles? Not that many companies will do that I think.

    • trashtester  3 years ago

      That depends on your reputation, network and references, in that order.

      Also, some of the companies that hire look precisely for such abilities.

II2II  3 years ago

From an outside perspective, as someone who does embedded development as a hobby rather than a profession, the answer is both yes and no. The stability of C and C++ helps, but you still have some churn in libraries and you almost certainly have to deal with vendor specific libraries (which makes moving between vendors difficult). Trying to bypass libraries doesn't really help on that front, since you are simply trading of churn in libraries with churn in microcontrollers.

  • willjp  3 years ago

    That’s very frustrating. I suppose it would be very expensive to standardize apis at this level where everything is performance critical.

leoedin  3 years ago

In my experience it's the opposite problem. Advocating for modern development practices or languages (even unit testing, let alone Rust) for embedded projects is hard work. Most new embedded projects, even today, are written in C or C++.

  • doctor_lollipop  3 years ago

    How does the language matter? I write software (mostly) in C for a living (the simple man's "embedded" as in "Linux on an ARM board", not the "bits on a micro controller" kind) and I made sure we use test-driven development with proper version control and CI.

    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.

    • leoedin  3 years ago

      My comment wasn't saying that modern development practices only exist in newer languages - I agree that all those things are possible with C.

      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.

  • matt321  3 years ago

    I have the same experience. I cant event get people onto github. We spend thousands a month trying to keep our international teams connected to our local servers and they still have to zip up the project and send it to me over teams.