Programming

17670 readers

154 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Follow the programming.dev instance rules
Keep content related to programming in some way
If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]

founded 2 years ago

MODERATORS

[email protected]

How proficient do you rate yourself in your most coded language? (self.programming)

submitted 2 months ago* (last edited 2 months ago) by Croquette to c/[email protected]

83 comments fedilink hide all child comments

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

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 13 points 2 months ago* (last edited 2 months ago) (2 children)

In C in particular, you have to be very cognizant of the tricky ways the language can screw you with UB. You might want to try some verification tools like Frama-C, use UB sanitizers, enable all the compiler warnings and traps that you can, etc. Other than that, I think using too many obscure features of a language is an antipattern. Just stick with the idioms that you see in other code. Take reviewer comments on board, and write lots of code so you come to feel fluent.

Added: the MISRA C guidelines for embedded C tell you to stay with a relatively safe subset of the language. They are mostly wise, so you might want to use them.

Added: is your issue with C or with machine code? If you're programming small MCUs, then yes, you should develop some familiarity with machine code and hardware level programming. That may also help you get more comfortable with C.

[–] [email protected] 5 points 2 months ago

Yeah, but they make me MISRAble.

[–] Croquette 2 points 2 months ago (1 children)

My issue is with the imposter syndrome i'd say.

I don't know asm on the tip of the fingers because today's mcu are pretty full of features that makes it not useful most of the time, but if I need to whip up something in asm for whatever reason, I know the basics and how to search for documentation to help me.

I try to follow MISRA C guidelines because it's pretty easy to follow and it gives tool to reduce mistakes.

I have enough experience to avoid many common pitfalls such as overflows, but for whatever reason, it always feel like I don't know enough when I come across a tutorial or a post with a deep dive in a specific part of an embedded project or on the C language.

When I read these tutorials/posts, I understand what is being done, but I could not come to these conclusions myself, if that makes sense.

[–] [email protected] 2 points 2 months ago* (last edited 2 months ago) (1 children)

What are you working on and what kind of organization? Are you working with someone more senior? You could ask him or her for an assessment of where you should work on strengthening up.

You are in the right mindset if you are worried. Many C programmers greatly overestimate their ability to write bug-free or even valid (UB-free) code.

The AVR MCUs are pretty simple compared with 32 bit MCUs, so are good for asm coding.

Otherwise it's a matter of coding til it's reflexive.

Philip Koopman has written a book on MCU programming that sounds good. I haven't seen it yet but someday. You might look for it: https://betterembsw.blogspot.com/2021/02/better-embedded-system-software-e-book.html?m=1

John Regehr's blog is also good.

[–] Croquette 1 points 2 months ago (1 children)

Thanks for your input.

I think I would like to follow all these people and their work on C, and their in depth knowledge. But free time is sparse, and I don't have the mental energy when I do have some time.

As for my work, I work in a startup where I am the only one doing what I do. However, I have a lot of leeway in how I code, so I am always somewhat read on best practices. So I can't really refer to a senior dev, but I can self-teach.

I think I coded enough that a lot of what I do is a reflex, and I often can approximate a first solution,but I have doubts all the time on how I implement new features. That makes it so that I am a slower coder and I really struggle to do fast prototyping.

I am aware enough of what I do well, and what I struggle, so there's that.

[–] [email protected] 2 points 2 months ago* (last edited 2 months ago)

Fair enough. If your product isn't safety or security critical then it's mostly a matter of getting it working and passing reasonable testing. If it's critical you might look for outside help or review, and maybe revisit the decision to use C.

The book "Analysable Real-Time Systems: Programmed in Ada" was recommended to me and looks good. I have a copy that has been on my reading pile for ages. I was just thinking about it recently. It could be a source of wisdom about embedded dev in general, plus Ada generally fosters a more serious approach than C does, so it could be worth a look. I also plan to get Koopman's book that I mentioned earlier.