Programming

I am very proficient in my primary language, C#.

Writing more context out feels like boasting, so I think I will skip that and go to a summation/conclusion directly.

Knowledge and expertise comes from more than the language. Which you hinted at. The language is only our interface. How is the language represented, how will it transform the code, how will it be run. There's a lot of depth in there - much more than there is in the language itself.

I learned a lot, through my own studies and reading, studying, projects, and experience. I'm a strong systematic thinker. It all helps me in interpreting and thinking about wide- and depth- context and concerns. I also think my strengths come at the cost of other things, at least in my particular case.

You're not alone. Most developers do not have the depth or wide knowledge. And most [consequently] struggle to or are oblivious to many concerns and opportunities, and to intuitively or quickly understand and follow such information.

Which does not necessarily mean they're not productive or useful.

I don’t think your question relates to the language as much as to the platform. The language of choice is somewhat irrelevant and what you care about is what actually happens under the hood.

For the likes of java and go you want to have some understanding of what runtime does for the memory allocations and how their GCs work. For python you sometimes end up in the spots where you need to understand what limitations the GIL imposes (even more important now that they are trying to get rid of it). When you run C (or C++ or Rust) on the embedded hardware it really helps to understand what exactly bit flipping does in specific registers and what DMA means for how you write your code.

You don’t really have to know it all. You can absolutely write code without caring about anything of that and I know plenty software engineers that do. Some people write amazing functional things in java without ever questioning what it does to the machines and what resources you need to run it.

If you start questioning it, that will only expand your understanding. It's not a lateral move from e.g. C to Rust where you need to learn a lot to write your code in a memory-safe way, it's a movement deeper into the stack and what you learn there will be applicable to any language you use for this stack.

Answering your question: I always feel bad about not understanding some low-level concept. I have stacks of MCU reference docs lying around, printed, highlighted; I have archives with sample code, and hand-annotated CMSIS reversing notes. Embedded world is hard because you can’t just know C and be done with it. You have to know the hardware, too.

Here's my advice for you. Make notes of things that you learn from people smarter than you. Create a web of those notes and see where your gaps are. Then, work on learning something in those gaps in particular and see if you can make a blog post or something of your own. When you share what you learn you become one of those people with deep understanding that others look up to. There's always someone struggling with something that you either know or know how to figure it out.

Even the creators of languages don't know their own languages 100%. I wouldn't even call them the limit. So, I'm good enough in my main language that a lot of code doesn't surprise me. And I try very hard to write code that others can understand as well when in a team.

Anti Commercial-AI license

I'd say average.

In every project and in every team, I end up being strong because I fix the hard stuff. I debug better and I deliver mostly bug free code. My code is more efficient and performant than my coworkers most of the time.

That's gotta count for something.

Imposter syndrome is good for me. Keeps me learning.

A solid 5.

I'm happy with it too. They still pay me so I must be doing something right. Almost two decades now.

A one out of ten. I consider myself the world's second worst programmer.

I've learned a lot by breaking things. By making mistakes and watching other people make mistakes. I've writing some blog posts that make me look real smart.

But mostly just bang code together until it works. Run tests and perf stuff until it looks good. It's time. I have the time to write it up. And check back on what was really happening.

But I still mostly learn by suffering.

I got pretty good with BASIC back in 1983.

how do you rate yourself in your most used language?

I know things that no human should have to carry the knowledge of

Do you understand the subtilities and the nuance of your language?

My soul is scarred by the nuanced minutia of many an RFC.

in the hope of reducing my imposter syndrome.

There's but two types in software - those who have lived to see too much...and those who haven't...yet.

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.

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

Better than many, mediocre.

With my coworkers I've got a strange ability to pick up any language that tastes like c, and get stuff done. I'm sure I've confused our c# guys when I make a change to their code and ask for a code review, because I'll chase down quality of life improvements for myself. (Generally, I will make the change and ask if I have any unintended side effects, because in an MCU, I know what all my side effects are, multi threaded application?, not at all)

Edit: coming from a firmware view, I've made enough mistakes to realize when order of operations will stab me, when a branch is bad because that pipeline hit will hurt, and I still get & vs && wrong more often than I would like to admit.

The more I learn about my language the less I think it matters. Maybe in embedded C you can’t just leave everything to the compiler though.

If you step in enough shit you eventually learn to realise when you are about to step in it again. I think the most knowledgeable people are those that have failed the most and found something helpful along the way, seems you are well on your journey so just keep steeping. At some point the abstractions you have control over become unreliable until you understand how they interact with lower level systems and the balance of control comes back because you know know the circumstances in which these abstractions work in your favour.

With about 12 years in my primary language I'd say my expertise is expressed in knowing exactly what to Google..