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

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.

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

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.

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 ❤️

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

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

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

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.

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.

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

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.

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.