How proficient do you rate yourself in your most coded language?

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

This is probably the true highest level of expertise you'll get out of most professional coders.

It takes a real monk level of confinement to understanding the language to break out of being proficient in looking shit up and start being proficient in being the person that writes the shit people are looking up.

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.

But I still mostly learn by suffering.

That resonates so much. Almost every time someone is deeply impressed with something I know, it brings back a painful memory of how I learned it.
I really like brain twisters. It can get frustrating at times, but it's the most fun out of the profession to me.

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

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

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.

After almost 12~15 years of programming in C and C++, I would give myself a solid "still don't know enough" out of 10.

After almost 12~15 years of programming in C and C++, I would give myself a solid "still don't know enough" out of 10.

That resonates so thoroughly.

And while it can 100% also be the case in any tool or language, it's somehow 300% true for C and C++.

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.

Yeah, but they make me MISRAble.
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.
- 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.

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

By any chance, do you use a niche language that has only two programmers?
- Nope. I'm just that bad. I feel like I have a logical mind but it just seems like the command don't do what I think they will, won't operate on a certain type of variable or Holy crap I forgot a friggin space or semi-colon or something.
  
  Languages in order of proficiency: C++ HTML/CSS Matlab Basic Fortran (1 class taken)
  
  But when I say proficient I seriously mean looking stuff up on the internet for every single line. And I haven't used Basic in decades.
Who is the first?
- The guy who was using my name to make code submissions 2-3 years prior.
- Odds are the worst one is still using Twitter.
- You mean the worst? I don't know. I'm just hopeful that I'm not actually the worst. Fingers crossed.
Imposter syndrome is strong

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.

I just have to say "tastes like c" is a visceral way to say it. I approve.
I think I'll never not make & &&, | || or = == operators mistakes. It's so easy to go over it fast and not notice the mistakes.

I like developing MCU firmwares because there is limited amout of resources and you usually have direct control of what is running when.

I feel the better than many, but mediocre in my soul. I mean, I get paid to code, so I certainly have a good enough knowledge to do so. But I have the tendancy to undersell myself.

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.

I've been writing code for 25+ years, and in tech for 27+.

I'm a novice at all languages still. Even though they tell me I'm a Principal Engineer.

There's always some new technique or way to do what I want that's better I'm learning every day. It never stops. The expectations for what I consider to be good code just continues to climb every day.

I try to tell this to all young guns getting in.

The amount of information due to the dearth and depth of theory, practical, and abstraction I would need to where I'm comfortable enough to consider myself an expert would take a lifetime to learn.

Hence, it's, "Stay in the dojo, young padawan!"

I should know more about what's happening under the hood.

You've just identified the most important skill of any software developer, IMO.

The three most valuable topics I learned in college were OS design basics, assembly language, and algorithms. They're universal, and once you have a grasp on those, a lot off programming language specifics become fairly transparent.

An area where those don't help are paradigm specifics: there's theory behind functional programming and OO programming which, if you don't understand, won't impeded you from writing in that language, but will almost certainly result in really bad code. And, depending on your focus, it can be necessary to have domain knowledge: financial, networking, graphics.

But for what you're taking about, those three topics cover most of what you need to intuit how languages do what they do - and, especially C, because it's only slightly higher level than assembly.

Assembly informs CPU architecture and operations. If you understand that, you mostly understand how CPUs work, as much as you need to to be a programmer.

OS design informs how various hardware components interact, again, enough to understand what higher level languages are doing.

Algorithms... well, you can derive algorithms from assembly, but a lot of smart people have already done a ton of work in the field, and it's silly to try to redo that work. And, units you're very special, you probably won't do as good a job as they've done.

Once you have those, all languages are just syntactic sugar. Sure, the JVM has peculiarities in how its garbage collection works; you tend to learn that sort of stuff from experience. But a hash table is a hash table in any language, and they all have to deal with the same fundamental issues of hash tables: hashing, conflict resolution, and space allocation. There are no short cuts.

Any good resources you can share for/on each topic?
- College.
  
  I'm one of those folks who believes not everyone needs a degree, and we need to do more to normalize and encourage people who have no interest in STEM fields to go to trade schools. However, I do firmly believe computer programming is a STEM field and is best served by getting a degree.
  
  There are certainly computer programming savants, but most people are not, and the next best thing is a good, solid higher education.
Thanks for the input, it will make me think about how to approach how to get the skills I need.

I'd say I am decent with FreeRTOS which is pretty much just a scheduler with a few bells and whistles.

I haven't used assembly in a long while, so I know where to look to understand all the instructions, but I can't tell right off the bat what a chunk of assembly code does.

Algorithms, I am terrible at these because I rarely use them. I haven't worked in a big enough project where an algorithm is needed. I tend to work in finite state machine which is close to algorithms, but it's not quite it. And a big part of my job is interfacing peripheral chips for other to use.
- Thanks for the input
  
  You're welcome!
  
  I haven't used assembly in a long while, so I know where to look to understand all the instructions, but I can't tell right off the bat what a chunk of assembly code does.
  
  Oh, me neither. And that's not what I think is necessary; what's important is that you can generally imagine the sorts of operations which are going on under the hood for any given line of code. That there's no magic "generate a hash for a string" CPU operation, and that, ultimately, something is going to be iterating over a series of memory locations and performing several math operations on each to produce a numeric output. I think this awareness is enormously valuable in developers, and helps them think about the code they're writing in a certain way, and usually in a way that improves their code.
  
  Algorithms, I am terrible at these because I rarely use them.
  
  You use them all the time! Anything longer than a single operation is an algorithm.
  
  Nobody is going to ask you to write a search function; however, being aware of Big-O notation, and being able to reason about time and space complexity, is important. On the backbend, it's critical. It's important if you're a front end developer - I blame the whole NodeJS library fiasco on not enough awareness of dependency complexity by a majority of JS developers.
  
  I tend to work in finite state machine which is close to algorithms, but it's not quite it.
  
  I'd absolutely call FSM work "algorithms", and it sounds as if the projects you're working on is where these fundamentals are most important. Interfaces between hardware components? It's the most fraught topic in CIS! So. Many. Pitfalls. Shit, you probably have to worry about clock speeds and communication sheer; there's absolutely a huge corpus of material about algorithms for handling stuff you're working with, like vector clocks. That's a fabulous, interesting field. It's also super tedious, and requires huge attention to detail which I lack, so in a way I envy you, but an also glad I'm not you.

After 6 years of seriously using Python regularly, I'd probably give myself a 6/10. I feel comfortable with best practices and making informed design decisions. I have no problem using linting and testing tools. And I've contributed to large open source projects. I could improve a lot by learning more about the standard library and some core computer science concepts that inform the design of the language. I'm pretty weak in web frameworks too, unfortunately.

After 3-4 years of using python I'm bumping you up to a 7 so I can fit in at a 5. Congrats on your upgrade. I've never contributed to open source but I've fixed issues in publocly archived tools so that they aren't buggy for my team. I can see errors and know what likely caused them and my code literacy is decent. That being said, I think I'm far from advanced.

8/10 Server-side JavaScript

7/10 Ampscript

3/10 SQL

There is something about SQL that I can't get to click with me. I can run basic queries and aggregation, but I can never get nested queries to work right.

All of these also assume I have access to documentation. Without documentation, all of them are like a 2. 🤷

I have advice that you didn't ask for at all!

SQL's declarative ordering annoys me too. In most languages you order things based on when you want them to happen, SQL doesn't work like that- you need to order query dyntax based on where that bit goes according to the rules of SQL. It's meant to aid readability, some people like it a lot,but for me it's just a bunch of extra rules to remember.

Anyway, for nested expressions, I think CTEs make stuff a lot easier, and SQL query optimisers mean you probably shouldn't have to worry about performance.

I.e. instead of:

SELECT one.col_a, two.col_b FROM one LEFT JOIN (SELECT * FROM somewhere WHERE something) as two ON one.x = two.x

you can do this:

WITH two as ( SELECT * FROM somewhere WHERE something ) SELECT one.col_a, two.col_b FROM one LEFT JOIN two ON one.x = two.x

Especially when things are a little gnarly with lots of nested CTEs, this style makes stuff a tonne easier to reason with.
- I'm 100% going to try this, but I have a feeling that it isn't going to work in my application. Salesforce Marketing Cloud uses some pared-down old version of Transact-SQL and about half of the functions you'd expect to work just flat out don't.
  
  The joys of using a Salesforce product.
I loathe debugging ampscript and anything to do with marketing cloud with a passion..
- Wrap the Ampscript in an ssjs try/catch block and debug all your shit on a cloudpage. ;)
  
  Everyone that works in SFMC for an extended period of time hates SFMC. Or at least has a love hate relationship with it. I think Salesforce is the most worthless company in existence and John Mulaney's anti-SF rant at Dreamforce brought a little light to my life.
  
  I very rarely actually use Ampscript anymore. Almost everything is done in ssjs in my instance. Thank fuck I'm not consulting anymore and don't have to deal with other company's stuff.

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.

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.

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.

It's a strong typed language with a minimal set of guard rails, so there is certainly some considerations to take into account, but the compiler are pretty good and give more leeway to the dev.
Not every thing, but still most things by far.

I got pretty good with BASIC back in 1983.

Nice!

I'm still struggling to get good at BASIC, myself.

BASIC was my first language, and I still don't feel like I've mastered it, so I still study it on some weekends.

I take so many modern tools for granted, now. It makes my learning progress in BASIC feel slow.

But I'm getting better at it.

A solid 5.

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

5 years professionally and I can find jobs, so yeah I must do something decent. But that imposter syndrome is strong these las weeks

I would give myself a solid 4.2/5 on python.

I have in deepth knowledge of more than a few popular libraries including flask, django, marshmallow, typer, sqlalchemy, pandas, numpy, and many more.
I have authored a few libraries.
I have been keeping up with PEPs, and sometimes offered my feedback.
I have knowledge of the internals of development tooling, including mypy, pylint, black, and a pycharm plugin I have created.

I wouldn't give myself a 5/5 since I would consider that an attainable level of expertise, with maybe a few expections around the globe. IMO the fun part of being really good at something is that you understand there still is to learn ❤️

novice still learning everyday

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.

Through the different replies, I reflected on what I know and what I do for work and I feel like my skillset is more akin to a generalist/integrator, which is needed. But I also feel like everyone in my domain does that. Which might or might not be true.

I guess knowing our strengths and weaknesses is also a skill in itself and a little bit of self doubt here and there can help us grow and direct our knowledge in a certain direction.

Thanks for the insight.

I've been using c# since .net 2 which came out around the turn of the century (lol)

I'd happily call myself an expert. I can do anything I need to and easily dive into the standard library source code or even IL when needed.

But even then there are topics I could easily learn more on particularly the very performance focused struct features and intrinsics.

I've found LLMs to be super useful when you have a very specific question about a feature. I use bing ai at work so it sources all its answers and you can dive into the articles for more detail.

Programming is a never ending learning journey and you just have to keep going. When you get something you don't fully understand to a deep dive there are always resources for everything.

I’m mostly working in Java now. I’m proficient to the degree that I can solve most things without looking for reference online. I think that matters most to me.

It's funny because I often have to look for the prototype of a function because I often forget all the arguments a standard C function uses, but otherwise, i feel like I am proficient enough to know where to look for, which in my case is normal because I won't memorize all the details of how each peripheral of the mcu works.

Being proficient isn't about getting something right the first time, it's about how easily you recognize something as wrong and knowing how to get the knowledge to fix it. Under that definition I rate myself 5/5 if I'm not trying to be humble or sorry about tiny details.

Good enough to make my own things or mod things.

But not good enough to get a job as a programmer.

But not good enough to get a job as a programmer.

This is as weird of a time for getting hired as a programmer as we have ever had. Hang in there. Once we let AI deployment pipelines start causing production outages and shareholder bankruptcies, we will start falling over ourselves to hire human programmers again.
- I mean that it's quite a leap going from making, like, a text-based adventure in C++ or BASIC and changing/adding lines of code to someone else's thing making mods to doing actual, professional level programming of systems I have never even fucked with for fun. Like, I can't make the screen display an image. I don't know how to do any sort of networking, at least from a programming standpoint (hardware and shit, no problem; I was CISCO and A+ certified at one point).
  
  I guess if all they need me to do is make what is essentially a database or calculator, I could do that. 🤷🏻‍♂️
- Feels good to hear this. I'm also struggling to enter the industry and it's nice to read something hopeful for a change

1/10 in python. I took a college course or two and enjoyed it.

I have no fear of implementing anything I'm asked to in typescript go rust java c# f# or nix... They're all the same tool just kinda different in some places.

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.

I think my job requires me to work in too many different areas. So although I can work in several languages and dev stacks, I am probably only a 2 or 3 or less out of 5 in all of them. However, network and server infrastructure, and cybersec/opsec I am probably more in the realm of a 4-4.5.

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

What I like about embedded is that it's between software and hardware, where you have to know both to a certain extent. It kinda feels like being a mad scientist bringing a monster to life. Seeing that my code makes physical actions (lighting a LED or controlling a motor) never seems to get old, even when trivial.

I am confronted everyday about the things I don't know because I work in a startup and I am the only one that does what I do. Any issue that I have tells me what I need to learn to fix the issue.

You are right that for a lot of people, what I do seems like magic and we often forget the extent of our knowledge because it has become innate.

Thanks for the insight, I appreciate it.

I’ve been using Scala professionally for 3 years. I don’t know what I’m doing most of the time because we have a ton of implicites and monads and extension methods. I just know the general idea and can get where I want by reading types.

I’ve been creating a language for fun for nearly 6 years. I often don’t know what’s going on under the hood because it’s somewhat complex. I think this is normal for every language. You don’t have to know everything to be able to use it. You don’t have to write blog posts once a week about the language subtleties you found.

The blogposts are the example I had because this is usually where I find my solutions.

I do understand that I don't need an in depth knowledge of everything about my language, but I sometime feel like I should know more. But again, this is the imposter syndrome talking.

I am thinking about blogging once my kids are older and I have more time because I am grateful when someone else does and I want to contribute as well.