Thanks for making this post. Any other similarly experienced devs please feel free to chime in!
Some context before my questions:
Would you view the legacy nature of the project and entrenched attitudes of the lead as red flags or opportunities?
What is a good balance of knowing fundamentals/legacy vs. modern, marketable practices?
What advice would you give to younger programmers on how to interact with programmers of your generation who are set in their ways?
I hate to sell out a fellow developer but almost everything you described above doesn't seem like an opportunity to me, it seems like a whole series of red flags. About the only thing your lead and I agree on is no great love of Babel/TypeScript (though I use TS at work, I use straight ES6 code on my own personal projects outside of work). In my case however, it's just because I don't like a system with a lot of tooling and all of the modern browsers (Note: I'm excluding IE11 from that designation) handle ES6 just fine already.
It really doesn't seem to be about 'sink-or-swim' as much as it seems to be about discomforting an individual from his/her personal preferences. I'm going to come back to that in question 3.
In my case, my most marketable skill for quite some time has proven to be the ability to look at somebody and say convincingly, "I can fix your problems." Whether those problems were with performance, adding new features or fix bugs in an existing codebase, rewrite a codebase to make it modern, or the ability to get best practices of version control and continuous integration into place. I can listen to the problems they have and explain some of what they might need to fix it and tell a believable story about how I've helped others solve those problems in the past.
Let me extend that a little bit for you, because there are younger developers who at present think that webpack + TypeScript + React is literally the only way to build anything. They are as unwilling to consider any other tech because it would require them to learn something new and to consider that maybe some of the stuff they already know is actually starting to fade. It's not an age thing, it's a mindset.
Change is going to happen. Your favorite tools aren't going to be the favorites forever, it's a given. jQuery was king, it's not anymore, AngularJS, ditto. React is currently king but tomorrow it may not be. Ask them a simple question, "What is your current plan for change? What do you plan to introduce to simplify coding over the next few years, what do you plan to phase out, and how do you plan to acquire new talent with a good tech stack that solves our problems while still moving forward to well supported solutions?"
If you can lay out a convincing set of reasons why adoption of something new could make things better while not imposing a lot of tech debt and it would give the project a longer/better lifespan and they aren't willing to even consider it, do you want to work with that person or those people? If they can't articulate some kind of plan and they won't listen to yours, that is a big red flag.
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.