Thanks for your response, and you've given me a lot to think about in regards to it as an actual compsci term! And yeah, if we consider the scale and complexity of certain applications, sugar makes sense due to not repeating oneself, cutting down lines of code, etc. I think my disgruntlement was over the blurriness of its meaning. It could be a feature, a transpiling/intermediary syntax on a framework, it could be a bunch of new syntax in a newer version of a language... etc. And coming from a learner's perspective, it seemed like jargon that was a hindrance to understanding exactly what that "add-on sidedish" of a syntax did.
On the same lines of logic, being able to talk about code doesn't mean I know how to code proficiently. But I'm definitely enjoying reading more about the details of how JS works and making quantum leaps in my own way.
I know where I stand given the general response and performance on the job. There's been a bunch of failures in the last two years, but I enjoy coding. I believe intellectual vulnerability is important for learning and creating good vibes. In case I seem to devalue myself too much I have salary negotiated and tried to prove myself as much as I could that I was a valuable member in previous positions. Previous experience has made me feel inauthentic when acting confident or burying insecurity in addition to trying super hard to fit in various work cultures. Guess time will tell. In a few years I may regret this style of writing. I appreciate your encouragement and know what you mean though--used to teach/mentor art students. Hated that they felt nerves over explaining their relatively young practices. I'd be like, "It's art, not brain surgery. You're doing it! Who cares what kind of artist you are?!"
I completely understand where you're coming from about feeling inauthentic. That's actually called "imposter syndrome", and talking down about yourself feels like a cure. In reality, self-debasement will make the imposter syndrome worse.
I suggest you adopt a different line of describing yourself. (This is the one I use myself):
Be as honest about your strengths as your weaknesses. For example: I am an expert in C++ memory management, but I have no skills in machine learning. I am fairly good at designing vector-based logos, but I cannot draw a decent stick figure to save my life. Keep your positive and negative self-statements in balance.
Own your mistakes, only allow yourself to apply negative terms to what you did, not who you are. For example: I once a wrote a scripting language in ActionScript 3.0 using regular expressions. It was terrible, slow, and I made sure to destroy that source code so it would never see the light of day again. I say: "the language design sucked." I don't say: "I suck at language design."
Avoid exaggerations. I'm a quantitatively verified expert in some areas of coding, but pretty dismal in others. Thus, I wouldn't say "I'm a programming expert" (unqualified), as that'd be an exaggeration; I'm only an expert in certain things. But I wouldn't say "I'm a mediocre programmer", because I've written some definitely non-mediocre things.
By the way, programming is art, so everything you told your students applies here. It's programming, not brain surgery. You're doing it! Never allow yourself to say "I'm not a real programmer." If you've written code, you're a real programmer.
Be honest about what you have yet to learn, but be just as honest about what you can do. Keep praise and criticism of self in balance.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.