And that demonstrates the difference between a developer that is ready for promotion vs one that isn't. You need to be able to make the correct choices for your employer (even if they are not the best choices, or most interesting choices), and being able to recognize these is a skill.
It's fine to prefer the comfort of familiar problems and obstacles, but you shouldn't pretend to yourself that you haven't chosen to embrace them over fear of the unknown.
Instead of talking about skills, or personal efficiency, talk about technologies that you're going to introduce to your product, or some specific difficult problem that you're intending to solve.
Another next career step is to take ownership of things without needing to be asked or told, to create and execute plans, to raise and address problems pro-actively etc. And if your workspace doesn't give you opportunities to do it, and you want career progression, then go somewhere else.
This is bait right? Obviously the answer to this question is there is some population that are happy for there to be suffering so long as it benefits them, and then there is another population that is vehemently against this, and then there is one that is apathetic and tries to just get on with their lives.
This is just not true. The Lisp family contains all conceivable variants of languages, from statically typed Coalton, to dynamically typed Scheme. From functional, immutable by default Clojure to the imperative-style of Common Lisp.
There are prologs, constraint solvers, ffis, JavaScript alternatives, garbage collected and not garbage collected languages that call themselves lisps.
I've seen a few of your comments here today, and generally speaking they are appeals to authority, ad-hominem attacks dressed in allusions to superiority in either knowledge or manners, and truisms without substance. In a manner of speaking: bait. So I guess I'm probably unsurprised if your experience of this is people seeming disagreeble towards you.
I wouldn't argue about things that are a matter of taste normally, except that I've had the experience where I've turned down optimizer settings in order to debug some code better and then the had stack overflow.
Sigh and yet it continues to be true. You can make a pragmatic decision and rely on tail call optimisation for your specific case, but if you are writing a CL library, then it is not idiomatic to use recursion in the same way that you would for Clojure or Scheme.
Even with SBCL, for example, it doesn't have tail-call optimisation for all architectures at all optimisation levels.
Senior Engineer means many different things, even within the same company. It could mean, "This person is more productive than everybody else around them" or it could mean, "This person isn't that great at software development but they know some product area so deeply that it would be too expensive to replace them."
First of all, congratulations. As somebody that also achieved the senior developer title within the first three years of being hired out of University, mostly by luck: Yay money, but I wasn't a senior engineer really for another five years. For me, I needed to see the long term effects of the changes that I'd made and the software I had written to really understand the difference between cargo cult behaviour and what really mattered for the business I was working for.
If you don't have personal examples of using a profiler to diagnose an issue like "too many round trips" and identify where those round trips are coming from, then you've never inherited a complex performance problem before.
I agree with this article fully, but there is a problem that most blog posts about identity don't talk about before telling you what do with your own. What is identity actually for? This is the only article I know of that talks about this: