Should I be wary of what tools I work with to maximize delivering impact?

I have a couple of thoughts here, though they are based on my own time in Amazon as SDE1/2.

Generally, I would NOT worry getting the chance to work on new technologies or new tools. Instead, I would index on areas/packages that (1) critical to my team's success (2) yet to be owned by another engineer.

In Amazon (and other big tech too), the key to be a successful SDE1 on promotion track to SDE2 is ownership and independence.

That means, being the go-to person of a high-impact area that no one else wants to touch (maybe due to its tooling or technology) is extremely helpful for your own performance and career growth to SDE2, as that typically gives you the room to exemplify ownership and independence.

When I was SDE1, I was tasked to onboard onto a Javascript Library as replacement for the departing SDE2 who owned it. This thing was gnarly. It was written in vanilla ES3 javascript (this was in 2017 and ES3 was released in 1999), with no concept of classes, and most frustratingly of all, it was deployed to production by... manually issuing an update request to the server hosting it.

It was a huge source of pain for myself and caused sev2s frequently, and almost nobody wanted to touch it because it was vanilla javascript.

But I took it on and became the go-to person for it. It was really painful the first few months, and then I got comfortable with its internal logic and these helped me address some of the sev2s. Then I realized a huge problem was the manual, human-driven deployment process so I managed to fit the existing process into an automated release pipeline that reduced deployment outages to nil. Eventually a colleague and I migrated the thing to ES5 and even added unit tests! It was really easy to prove my impact during performance season because I became an expert of a critical system in my team.

The point here is that it's more important for you to find important areas to own rather than looking for the newest tech or tooling. Once you've spent enough time with it, find ways to solve the painpoints you are facing - after all, you will have become an expert, and your work will go a long way to helping others in your team.

I really like Kuan's advice around "When life gives you lemons, make lemonade". A lot of engineers see pain as something bad; a big mindset shift I see a lot of engineers make to really start leveling up is seeing pain as opportunity.

At a Big Tech company like Amazon, there is always going to be legacy jank like what you described. I was more than familiar with it back at Meta. The instinct here shouldn't be to try and avoid it, but to ask yourself these questions to gauge the opportunity:

1. Is this legacy area high-impact for the team? - In so many orgs, the legacy code is literally generating 80%+ of its impact.
2. Is it a good place to lay down roots and establish myself as an owner? - If #1 is true and it's a relatively uncontested area (this is often the case with areas like these), then it probably is. This is huge for an SDE 1, and establishing ownership is generally a big piece of SDE 1 -> SDE 2 promo packets.
3. Can I make it better so it's easier to work with? - This is the "Have my cake and eat it too" when it comes to owning a messy legacy modules. If you can modernize it and make it actually smooth to work with, you now have this clean high-impact scope with you as the clear owner. It's like remodeling a beat-down fixer-upper into a beautiful new property. You can do this through a mix of refactoring, building new tooling, and adding more automation.

You don't need to figure out these questions on your own either, especially as an SDE 1. Talk to your manager and tech lead to see what they think.