Taro Logo

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

Profile picture
Entry-Level Software Engineer [SDE 1] at Amazona year ago

I've always been the one to dive into problems and solve them without thinking about how difficult they are but recently I've been running into this failure mode where many of the problems I work on involve using old tools that are cumbersome to work with. The result is that it takes much longer to deliver my work compared to those that work on packages with newer tools (I'm talking about native AWS lambda, s3, dynamo, etc) and sometimes I wonder if I'm doing what's best for my career.

Some cumbersome tool examples include

  • One package uses an old technology that doesn't allow us to test our changes in our dev desktop before we can submit a PR
  • Another package doesn't map correctly our dev desktop to the prod environment so it's sometimes difficult to reproduce the issue
  • Some non aws tools do not really provide much information to help the user debug their problems compared to the native aws tools

My company has at least acknowledged the issues with the above first two bullets and has slowly started deprecating those tools. Oftentimes the senior and mid-level engineers work with newer tools and therefore aren't as familiar with the older ones, which is fine. I could just avoid working with these packages altogether and only work on the packages that involve the shiny new aws tools but I'm not sure if that mentality is what's best for my career.



  • 7
    Profile picture
    Senior Software Engineer [L5] at Google
    a year ago

    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.

  • 3
    Profile picture
    Tech Lead @ Robinhood, Meta, Course Hero
    a year ago

    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.

Amazon.com, Inc. is an American multinational technology company which focuses on e-commerce, cloud computing, and much more. Headquartered in Seattle, Washington, it has been referred to as "one of the most influential economic and cultural forces in the world".
Amazon140 questions