There is the problem of literal style though. The aesthetics of say clothes do evolve overtime, not year to year big changes, but every 3-5? Sure. Just laughing at the thought of the model where any image generated is say stuck in 1990s grunge attire.
It's all about the RSUs. That all kicks in after year 2. If you're a lower level maybe you don't feel it as much. But for a high performing L6+ RSUs typically are -- or at least were designed to be -- the majority of your income compared to base pay.
I was an L6 and, at the time, my RSUs certainly gave me pause for leaving, but in the end the urgency of my mental health won out. My timescale was dictated by getting my Green Card, not (primarily) by finances.
yeah...different story now. The target comp numbers ) assume 15% stock growth per year from when it's allocated to you. That model is now broke for the first time in a decade+. How it gets fixed... I'm not sure, but, there is history of cash payments to compensate.
Point being, if you're not making more in year 3 than year 2 -- something is broke and/or your manager wasn't supporting you appropriately, or not hitting high enough on the performance ladder.
Ideally incident handling should "just" be rolling back the broken change. Fixing the problem should be done in the morning with no time pressure, not in the middle of the night half asleep with customers on the other side of the world yelling at you. Of course it's not always that simple, but most of the time that's what on call should be about
It would be nice if things only broke during "business" hours and didn't have real world impact. Nevermind impact millions of people around the world. But if you look at the customers of say code that is running cloud infrastructure it is running airlines reservations/checkins, government workloads, banks, hospitals, critical infrastructure, netflix, gaming services. That's a lot of things that can't typically wait for morning.
This is the pat answer Amazon gives to defend this absurd practice, but it breaks down really easily.
>If your code breaks something, you should fix that code. Who else should?
What if it wasn't my code, but code written by someone 3 years ago who quit because most people only work at the company for 2 years? And it's in a part of the codebase I've never touched. That's a much more likely scenario.
The problem is that he has a big pile of half-working spaghetti code that he never has time to touch except when it malfunctions in the middle of the night
The problem behind that is that Amazon is a completely dysfunctional corporate hellscape. Like TFA said, you just don't have time or resources to actually fix things
You should join Amazon and do that, and you can come back here and apologize in a couple of years when you get pipped for wasting too much time on legacy code
Yes I am well-aware of how SDEs work at Amazon. However there is a role at AWS called SDE - System Development Engineer which is very much DevOps which is very different than SRE and the reason I was asking.
PSA: In exposures like this, Contact the cloud provider too. They tend to have the right contacts for customers. And I'm guessing there are actions they can take as well.
