Getting started in big tech – Amazon

I am two months into my new job, moving away from sciences to software engineering as a Software Engineer at Amazon. So many new challenges, fun moments and subtle differences, all and more in this week’s article on “how to survive your first month at Amazon“, just kidding, but it could well be the realities of the job I find myself in sometimes. So many posts out there with bleak and shocking experiences yet my experiences here (albeit limited) have been everything but that. If you romanticize the idea of the 9-5 with some good ol’ work life balance, let me spare you the pain and suggest you look for reflection elsewhere. I suspect I find the experiences thus far “fun” because I don’t mind the long after hours grind and an over shadowing prospect of social suicide. Dark, too dark, I know, I am working on it.

Day 1 (every day is day 1 at Amazon, or something to that effect hehe) and I go in at 8am, get my card ready, walk around the office get coffee and wait (what felt like forever) for my manager to turn up. Small talk out of the way, we get to onboarding, if you are a Software Engineer like me, that means you get a shiny new mac-book, a trashy head phone and protocols (lots of it) on getting started and staying in Amazon. Nothing out of the ordinary here, but hey its the post-COVID era, at-least I get to meet my manager in person (sweetest person ever), rest of the team work remote, mandate is get people to office, but we usually come and go at will, unless your like me and come in everyday (Hey I have been starving for some work buddies having worked remote (read as incognito) for the last couple of years, don’t judge.)

What I look for in my workplace – My Tenets

Having worked for three fast paced companies in as many years, I have come to appreciate some aspects of work more than others. So at the risk of being impractical or naive I have these tenets to what a successful workplace means to me.

Tenet 1 – Time to Impact

Cliche as it may be, I value independence and respect within teams the highest. I believe successful teams provide for successful engineers, not the other way around. My team here at Amazon has been generous in the impact I could leave behind on active customer projects. Two weeks in, I pushed my first code to production. Time to impact, sooner than expected, verdict, happy individual contributor. A few breakages and alarms later, I find myself content and worthy of my team.

Tenet 2 – Delegation

When I was leading data science efforts at my old consulting firm, a lesson I learnt the hard way was delegation isn’t a choice. As appealing as it may sound to dabble in all things everywhere, understanding who can do what best in the interest of the teams bandwidth, sets the tone for the team. My team here and hence the leadership, are new and still learning of each others capabilities, with that being said, its’ working out surprisingly fast. We might just be a few months away from being a well oiled ship.

Tenet 3 – Find new tenets

If my workplace does not push me out of the know and teach me new things, thats usually when I know I have to look elsewhere. Ideally few months in, is when I anticipate this to happen. Until then I’ll continue to put my head down and grind through.

Tech stacks and the big tech way

Everything you would ever need in your day to day work is an internal amazon service. with a very enterprising community of developers (usually in the thousands), this seems to be the natural course of progression. We have our own internal stack overflow, versioning software and a host of deployment tools I haven’t even scratched the surface off.

Pushing my first change

The run of the mill software dev cycle happens as follows.

Good teams and companies have efficient strategies set in place to optimize every part of this process, great companies like Amazon make ground braking progress while doing so.

Apollo – Amazon’s answer to Deployment

While all four components are important optimization pieces, none requires more attention than deployment, especially when you are talking about the scale of amazon services and products.

Deploying software starts off easy, when we simply have a host machine to deploy to, and immediately starts increasing in complexity when production environments run across large fleets of hosts or even regions as is common these days. The more points complexity, the more applications are susceptible to human error.

So once we build and test our software, we have Apollo that lets us push button deploy to any production environment. The more I learn and work with Apollo, the more I understand it is not simply an exhaustive list of scripts to do things humans do, it has damage control, for instance halt deployment across reminder of the system when a failed update damages hosts, or efficient rollbacks [1] to bring hosts back to healthy state etc. The closest external tool I have seen is AWS codeDeploy.

Version Sets – Simple is beautiful

I’d like to think version sets as git on steroids (Not really accurate, but think of it as git branches with dependency branches with their dependency branches and so on). Every possible dependency version (recursively) and the code all packaged into one and is in all totality, the snapshot of our application or package’s version, hence the name. Amazon being amazon has something called version in live, which is the approved (and vetted) list of software that everybody in Amazon can use. Good practice mandates we merge with live before adding our changes, this helps solve a problem once in a central repository (like say the log4j issue) instead of everyone working on similar or same fixes in isolation for their package.

Now the juicy bits, version filters. They are the final part of the puzzle, your version set houses multiple versions of your software, version filter is just as the name sounds, a filter of the version you want to deploy. Once you have your filter, one-click deploy using Apollo and there you have it, your first changes as an Engineer at Amazon.