I have one other comment to make. In my opinion, being a strong programmer is mostly a "knack," meaning it's not a particularly teachable skill. Some people are just amazingly good at it. If you are, great. If not, I suggest acknowledging that and fashioning a career that doesn't rely primarily on programming skills.
> fundamentals of things like memory allocation, data types, call stacks, etc. remain a mystery to them.
I don't think C is especially good at teaching these.
Unless you roll your own malloc, the big difference in memory allocation in C vs. say, Java is that C requires the programmer free memory after allocation on the heap. This is more tedious than difficult.
Data types exist in other languages. You can unpack raw bytes of data using Java and simulate the behavior or unions.
You'll have to explain how call stacks are more exposed in C. Best I can think is calling conventions, but that's more the domain of compilers than language. Buffer overflow prevention, maybe (but again, I think that's more tedium to deal with).
C is great because it's a small language. But I don't think it's an especially educational language.
Many times that doesn't matter, but to me it's important to have a supple and complete understanding of the underlying ideas. Java fails at that.
When I referred to memory I meant more than malloc and free. It's things like understanding how an array of ints is laid out in memory and what happens when you treat it as an array of chars instead. If you talk about this to a Java programmer, their eyes are likely to cross.
> It's things like understanding how an array of ints is laid out in memory and what happens when you treat it as an array of chars instead.
This is one of said landmines, as the size of both is architecture/compiler specific. The only thing you learn by stepping on this one is, "use fixed-width integers when you care about exactly how many bytes the value is."
I just wanted to make this point because I've repeatedly seen folks frustrated by others who just get things faster and ultimately make progress much more quickly in their careers.
I think it's useful/important to acknowledge that programming is a bit like sports. It's not fair, but some people start with an incredible genetic (or something) advantage built in. I've seen this time and again.
Incidentally, the best programmer I've ever met (he co-authored a very popular programming language) happens to be one of the slowist typists I've seen. I once asked him why, and he said "because I have to think."
Take your time and have fun.
For some it means writing hard mathematical algorithms. For some it means writing the efficient and secure low level code. For some it means solving real problems fast by efficiently glueing existing code. For some it means great communication/management with 30 other programmers on team.
I think it is more about finding who you really are and following that than trying to become some dogmatic idea of what "amazingly good programmer" is.
Find your niche. The bubble effect is strong in all of us.
Yes!
If we assume that about a third of all programmers are "average" (whatever that means), another third is "above average", and one third is "below average". So, it's not actually a tiny minority, despite what Hackernews might make you think.
Programming consists of many different aspects: creating an architecture, designing algorithms, implementing them, hunting bugs, testing etc.
If you think you are "below average" in one of these areas, you can team up with other developers who are good in that area, and let them guide you.
For example, I work with somebody who is amazing at digging deep and really understand the low-level nitty gritty of bugs. But, they are not that great at building high-level abstractions. So when a task involves building high-level abstractions, we discuss these abstractions beforehand, write some mock examples that use the new abstractions etc.
Some developers aren't good at low-level stuff, but build great user interfaces. Some don't do that very well, but shine when it comes to automation.
To sum it up, "below average" programmers can be very useful to an organization with the right amount of specialization and collaboration/mentoring.
I used to hate (the lack of elegance of) JS but I got used. After a lot of dabbling, I'm still between React and Vue. While I prefer Vue, all jobs ask for React. Framework marketability seems to be crucial when/while you perceive yourself as below average.