Hi,

My question certainly stems from the imposter syndrome that I am living right now for no good reason, but when looking to resolve some issues for embedded C problems, I come across a lot of post from people that have a deep understanding of the language and how a mcu works at machine code level.

When I read these posts, I do understand what the author is saying, but it really makes me feel like I should know more about what’s happening under the hood.

So my question is this : how do you rate yourself in your most used language? Do you understand the subtilities and the nuance of your language?

I know this doesn’t necessarily makes me a bad firmware dev, but damn does it makes me feel like it when I read these posts.

I get that this is a subjective question without any good responses, but I’d be interested in hearing about different experiences in the hope of reducing my imposter syndrome.

Thanks

  • Ephera
    5·
    21 hours ago

    What helped me a lot with pushing deeper down into the language innards is to have people to explain things to.

    Last week, for example, one of our students asked what closures are.
    Explaining that was no problem, I was also able to differentiate them from function pointers, but then she asked what in Rust the traits/interfaces Fn, FnMut and FnOnce did (which are implemented by different closures).

    And yep, she struck right into a blank spot of my knowledge with that.
    I have enough of an idea of them to just fill in something and let the compiler tell me off when I did it wrong.
    Even when designing an API, I’ve worked out that you should start with an FnOnce and only progress to FnMut, then Fn and then a function pointer, as the compiler shouts at you (basically they’re more specific and more restrictive for what the implementer of the closure is allowed to do).

    But yeah, these rules of thumb just don’t suffice for an actual explanation.
    I couldn’t tell you why these different traits are necessary or what the precise differences are.
    So, we’ve been learning about them together and I have a much better understanding now.

    Even in terms of closures in general (independent of the language), where I thought I had a pretty good idea, I had the epiphany that closures have two ways of providing parameters, one for the implementer (captured out of the context) and one for the caller (parameter list).
    Obviously, I was aware of that on some level, as I had been using it plenty times, but I never had as clear of an idea of it before.

    • Croquette@sh.itjust.worksOP
      2·
      15 hours ago

      I work in a small start-up where I am the only one doing what I do, so my epiphanies come from the struggles I have.

      Other people I work with often have a blank look in their eyes when I try to explain some issues or what the code does because they don’t have the skillset to comprehend what I am doing. So this isn’t a path for me (yet, hopefully we can grow enough where we need more people in my field).

      But I appreciate your experience. I will certainly think about a way to play in the innards of my language so that I can understand it better.