Programming

17352 readers

311 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 !webdev@programming.dev

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

MaungaHikoi@lemmy.nz

How proficient do you rate yourself in your most coded language? (sh.itjust.works)

submitted 3 weeks ago* (last edited 3 weeks ago) by Croquette@sh.itjust.works to c/programming@programming.dev

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

[–] hperrin@lemmy.world 19 points 3 weeks ago (1 children)

Knowing the footguns in your language is always useful. The more you know, the less you’ll shoot your foot.

[–] Croquette@sh.itjust.works 6 points 3 weeks ago (3 children)

I think that one of my issue is that I'd like to be more knowledgeable to the smaller bits and bytes of C, but I don't have the time at work to go deeper and I don't have any free time because I have young kids.

[–] MajorHavoc@programming.dev 9 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

I don't have any free time because I have young kids.

That's a healthy thing to acknowledge.

It's a brutal phase for professional development, hobbies, free time, sex, basic housekeeping...

It gets better as the little ones grow.

[–] Croquette@sh.itjust.works 3 points 3 weeks ago

At least, we know emotionally that it will get better with the second one haha, even if the day to day is rought.

With the first one, it felt like we would never get to the other side of it. But we did and we will for the second one.

I am eager to learn new things, so having so little free time is definitely tough. And the lack of sleep/energy makes it even harder.

Thanks for the encouragement, it's nice to be acknowledged by someone else that went through the same thing. We often forget that we are not alone and a lot of people got through it before us.

[–] arendjr@programming.dev 4 points 3 weeks ago (1 children)

I don’t know about your workplace, but if at all possible I would try to find time between tasks to spend on learning. If your company doesn’t have a policy where it is clear that employees have the freedom to learn during company time, try to underestimate your own velocity even more and use the time it leaves for learning.

About 10 years ago I worked for a company where I was performing quite well. Since that meant I finished my tasks early, I could have taken on even more tasks. But I didn’t really tell our scrum master when I finished early. Instead I spent the time learning, and also refactoring code to help me become more productive. This added up, and my efficiency only increased more, until at some point I only needed one or two days to complete a week’s sprint. I didn’t waste my time, but I used it to pick up more architectural stuff on the side, while always learning on the job.

I’ll admit that when I started this route, I already had a bunch of experience under my belt, and this may not be feasible if you have managers breathing down your neck all the time. But the point is, if you play it smart you can use company time to improve yourself and they may even appreciate you for it.

[–] Croquette@sh.itjust.works 1 points 3 weeks ago

I work in a startup, so I'd say that almost every day, I learn something new. So I don't really need to look in-between tasks because a lot of tasks bring new challenges.

When I worked in corpos, my job was restricted to the same tasks and specific knowledge. Now it's the opposite where I need to learn what I need to create a feature or fix an issue.

I guess that lately, a lot of new things have popped up and I need to absorb a lot of information to implement the features I need. And that is probably what is triggering the imposter syndrome.

Thanks for the insight, it is appreciated.

[–] nebeker@programming.dev 2 points 3 weeks ago (1 children)

There’s a lot to talk about from this point alone, but I’ll be brief: having gone through university courses on processor design and cutting my teeth on fighting people for a single bit in memory, I’m probably a lot more comfortable with that minutia than most; having written my first few lines of C in 10 years to demo a basic memory safety bug just an hour ago, you’re way way ahead of me.

There are different ways to learn and gain experience and each path will train us in different skills. Then we build teams around that diversity.

[–] Croquette@sh.itjust.works 2 points 3 weeks ago

Thanks for the insight. I guess one thing that causes my imposter syndrome is that I want to know how everything works in details.

I agree that for other people, what I know seems like magic to them. It's easy to look at what we don't know, but we don't take the time to appreciate how far we've come. We should do that more often.