amzn-throw

To me this is just a simple artifact of size & attention.

Another example of this is stuff like Bluesky. There's a lot of reasons to hate Twitter/X, but people going "Wow, Bluesky is so amazing, there's no ads and it's so much less toxic!" aren't complimenting Bluesky, they're just noting that it's smaller, has less attention, and so they don't have ads or the toxic masses YET.

GenAI image generation is an obvious vector for all sorts of problems, from copyrighted material, to real life people, to porn, and so on. OpenAI and Google have to be extraordinarily strict about this due to all the attention on them, and so end up locking down artistic expression dramatically.

Midjourney and Stable Diffision may have equal stature amongst tech people, but in the public sphere they're unknowns. So they can get away with more risk.

Oops, my bad.

I meant an AWS cloud native application, yes.

But I use "cloud native" in a way that actually makes sense, not the way that GCP dubbed Kubernetes and all of it's ecosystem of friends "cloud-native".

"Native" development on a desktop OS means using primitives specific to that OS. As opposed to using something like Java Applets or Electron which will give you cross-platform compatibility, but you're not developing "natively" for the platform. That has the obvious pros and cons to each way.

Kubernetes is very much the Electron way: Rely on a generic high-level abstraction that will then create awkward bindings of running on abstract generic servers - whether they're in your data center or in the cloud.

Calling that "cloud-native" is some Orwellian post-truthness. I hate it.

If you want to develop in the cloud and make the most of it, use Azure, use GCP, use AWS, I don't care (not true: AWS is the best; use AWS). Just use the cloud provider's NATIVE primitives.

Otherwise, you might as well go back to running your own data centers, what are you even doing.

(Note: i'm just some guy. You don't have to listen to me. It's just what I think)

* RDS is a managed relational database service. You got a database? We'll run it in the cloud for you. Exact same bits and bytes as you're running locally.

* Aurora is Amazon's own relational database. You can't run it yourself, only with Amazon. It can pretend to be either Postgres or MySQL. And it'll be cheaper and faster and have higher availability. But it won't be the exact same bits and bytes as your own Postgres, so there's some risks.

So far the stuff we said runs on clusters. You pick how big and how powerful and how many and in which AZ and configure how to scale it.

This has fairly pragmatic limits before at a certain point sharding and continuous horizontal scaling just gets too hard.

* Until Aurora Limitless that is which is, well probably not limitless (I don't know) but effectively.

* But you're still configuring cluster sizes and scaling policies. If you don't want to do that, Aurora has a Serverless option. It's the same Aurora but now you don't have to worry about scaling it yourself. The first version was Aurora Serverless but people said it wasn't very good.

* So they put out a 2nd one which is great and scales to zero.

* Now if you have globally distributed customers or care a lot about resiliency, you probably want your database in multiple regions. And you're going to be setting up eventual consistent updates for that. To make that easier there is Aurora Global Database, which is the same Aurora, but now with cross region replication.

* But it's not strongly consistent across regions. Aurora DSQL is. It's an even more bespoke version of Postgres. Actually it's not a relational database one at all, it just pretends to be one. But it uses atomic clocks and shit to cheat the cap theorem and give you global distribution and resiliency with strong consistency.

So in conclusion there's basically only 3 things here:

* RDS which is an unopinionated way of running a relational database in the Cloud

* Aurora, Amazon's highly opinionated relational database. That has Global, Serverless, and Limitless configuration options.

* And Aurora DSQL which is not Aurora a relational database at all but plays one on TV. But it gets to have the best of all worlds - SQL and NoSQL.

They probably should have called it something new but Aurora has good brand recognition. People know and trust Aurora.

In the long term all will probably continue to exist depending on where you are in your cloud journey. But I also expect that in the fullness of time if you're building a new Cloud native application and you don't have to worry about legacy migrations, you'll probably choose either DynamoDB or Aurora DSQL in 99.9% of cases.

Sounds good, but not true: https://www.awsgeek.com/AWS-History/

S3 launched in 2006.

EC2 didn't go GA until 2008.

Elastic Block Store (a proper block store) showed up in 2008 too, actually went GA before even EC2.

S3 was for the longest time pitched as storage for the internet, and remains so today.

I super doubt these limitations are there because of any EC2 requirements.

Andy Jassy was the first product manager on AWS, and while there is lore debates whether he "came up" with the idea of AWS (probably not), he's been on it from the beginning and through every single product.

I don't know much about Selipsky or Garman, but Jassy absolutely was/is technical enough to get to AWS to where it was today (or know when not to get in the way of those more technical than him).

Watch any of his interviews from before he was Amazon CEO. The man knew his shit.

As someone that works at AWS (but not on S3), that's wrong in like eight different ways.

But the only way that matters is the core one - analysis, data, and instrumentation.

AWS does not make these kinds of decisions without a look at the metrics.

I'm not lecturing them for leaving. I'm lecturing them for complaining about things that it WAS IN THEIR CONTROL TO ADDRESS. More than that - it was their actual JOB to ensure.

If you were L8 then the responsibility for setting the culture is 100% on you.

L10s don't micromanage, and L7s take their cues from L8s.

If you want to have fewer meetings, you can set that culture.

If you want less fungible engineers, reinforce specialization in your OLR process.

If you don't like a process, kill it.

This is worse than than the "you're not stuck in traffic, you are the traffic." This is "you're not stuck in traffic, you are the accident creating the bottleneck".

I know a lot of people here are writing about how this can be done for small consulting companies, but I also saw it in Big Tech.

Amazon until 2022 really genuinely exemplified this. I saw it for more than a decade leading up to this. Just an unbelievable collection of people that truly Gave A Shit. Publicly we called it "Customer Obsession" and through that lens you could move mountains around here in the pursuit of Doing The Right Thing.

The first sign of trouble was 2021. Salaries skyrocketed in the industry. Amazon didn't keep up. A lot of great people left because they got obscene offers, and you know, who could blame them? Our core of "intermediate" engineers (L5 here) got decimated - why bust your ass for a promotion when you can just get a Senior offer from one of 100 over-funded Unicorns for more money than you would've made here. Sensible.

Then in 2022 the stock price dropped in half and a bunch of folks who seems like were only putting up with the bullshit as long as the stock grew indefinitely left too.

Then 2023 brought layoffs.

There's still a lot of us around that Give A Shit, but I feel like we are outnumbered more and more by those that just want to punch in and out and no longer Make History. I get it. I can't blame anyone individually. But I miss it.

Been with Amazon for over a decade.

The frupidity used to be a huge sore spot, but being honest, is no longer a part of the culture.

Sure, there are no catered buffets or massage chairs, but the old inflexible rigid frupid systems are all gone. Engineers get top of the line M1 Macbooks, nice monitors and good chairs. The desks are all adjustable sit/stand, not doors. You can get and expense whatever software you need. And yeah you gotta fly coach but nobody is going to bite your head off for expensing some peanuts from the mini bar at your hotel.

1.5, but probably over a million of those are FC workers who are not on slack cuz they're running around the warehouse.

There are just over 400,000 office employees WW

So it's closer to 3.5%, and the announcement was only posted Friday morning before a long weekend so that's likely to grow.

Sorry dude, you don't have credibility based on "Unless your willing to put up with a huge ration of shit on a regular basis, or you make it into management,"

Management at AWS arguably puts up with much more shit on a regular basis.

I can't speak for Google, and Amazon doesn't have an L9, so our Distinguished Engineers are L10.

But a decent bunch of them are the types of folks to have wikipedia pages:

* https://en.wikipedia.org/wiki/Jim_Roskind

* https://en.wikipedia.org/wiki/James_Gosling

* https://en.wikipedia.org/wiki/Tim_Bray (not anymore I guess)

The ones that don't probably would if it was public about how much of a significant contribution they've made to some foundational AWS services everyone knows. I think they don't mind.

No, you like coding. Which is okay!

But it's the difference between an individual carpenter making a rocking chair for himself and his family, or maybe making a couple to sell to his friends, and being a structural engineer.

Bikeshedding is not a necessary antipattern to the process, but large software projects absolutely need group collaboration, and a discussion of processes, tools, and best practices.

Who hurt you? Do you even like software engineering?

Quit, and go make sourdough bread, shit.

Maybe so, but don't you think I talk to new employees? It's half of my job to support my whole team and deliver through others.

I battled those tools when I started. I watched them get better.

I've seen what new hires struggled with 5 years ago and what they struggle with 1 year ago.

Night and day.

The tools have gotten a lot better.

Here's the other ugly truth: That "40% of struggling with internal tools" may be saving the engineer 300% of time of having to implement the same from scratch themselves. Software engineering isn't all algorithms and data structures. A lot of it is just boilerplate code hooking up A to B. And better leave that boilerplate code to the internal tool that you have to figure out how to configure than implement it yourself.

Amazon has a lot of bad internal tools, but this person's experience doesn't match mine (being here for 8 years) at all

40% of my time trying to tame the bad internal tooling I was forced to use to submit my code, get it merged, deploy it, check logs, etc…

The tools for code submission, pull requests, pipelines, metrics, and logging are fantastic. Google is better. Most companies aren't.

I have never spent 40% of my time battling internal tools....

20% of my time in meetings

Developers complain when they're not invited to meetings, and they complain when they're invited. On my team we brutally introspect the value of every meeting, and if it looks like it's not delivering value, we find a new process.

20% of my time writing unit tests to hit the 100% coverage requirement of the codebase I worked on.

This makes no sense. This isn't a company mandate, every team is free to determine what code coverage percentage makes sense for them. Give this feedback to your tech lead, nearest Sr. SDE or PE -> 100% test coverage should never be "required"

10% of my time tracking down bugs in other team’s codebases for either internal tools or frameworks and trying to get them to acknowledge the problem by filing tickets.

So, software engineering?

Everyone's interpreting this as AWS is zipping every customer's S3 data and improved storage of their data with ztsd. That's now what Adrian said, and this is not an announcement - this was a "by-the-way" from a retired Amazonian.

AWS switched our own service's log storage (in S3) from gzip to ztsd a bunch of years ago -and reduced storage costs by 30%.

This is AWS's service data (which is still exabytes) and AWS realized the efficiency.

So all the comments of "where is my 30% discount" are offbase.

Source: I've worked on AWS for a bunch of years.

Since we're sharing anecdotes and that's good enough for this thread, here's my own:

I'm a white guy - pretty much a typical one. My manager is a white guy - possibly even more typical, follow along North American Dude Stereotypes for both of us.

For most of the last 2 years, he had 8 reports - 3 managers, 3 product managers, and 2 principal engineers (me being one of them).

I was the only white guys out of 8 - the rest were all Indian.

Why?

Because the other 6 were the best people for the job. They applied for it (some external, some internal), and we hired them, cuz they were rad (and still are).

Demographically, that just happens sometimes, including all-Indian reports

My main message was that NO - that's not how it is ANYWHERE at the company. Connections data isn't available to managers de-anonymized. Period. On any team.

This post also has nothing to do with Amazon's business practices, but rather HR practices with employees.

Lastly, yes, there are some facets of what I wrote that are about my team. But this is the case anywhere. Some teams have good manager. Some have bad ones. Good ones rise. Bad ones fall. That includes using the same tools and techniques for good or for evil.

I absolutely do see Amazon as one whole team. That's why I felt the need to comment to make people working on other teams not think that this poster is revealing some secret insider information, and new SDEs be scared thinking what is happening with their 'private survey' results.

The REASONS for why there is such a variability in process and culture between AMazon teams would need a whole other blog post, but the tl;dr is: The #1 focus of Amazon development teams is delivering results and getting things done. This is done by removing road blocks and incentivizing RADICAL autonomy on the teams - way more than is available at tech giants of comparable stature (whether Apple, Google, Facebook, or Microsoft).

The upside of this is a tremendous sense of autonomy and responsibility offered to every engineer which is empowering and addictive.

The downside of this is that toxic managers can thrive temporarily and ruin good teams through misused autonomy. They do get weeded out, but it takes time. And good people can be lost along the way.

This is not an excuse, this is an explanation.

My primary HN account has a lot of other things in it that I'd rather not be associated with me being an "Amazonian", hence this one :)

Manager performance is not tied to connections data. However, manager's performance is tied to the kind of facets of team cohesion, productivity, satisfaction, and delivery that the Connections data. Does that make sense?

And it's not a terrible proxy. For example, it would be relevant if a manager was measured on their ability to hire and retain people, right? Well, if certain connections questions have a direct correlation with people leaving the team, you can imagine someone would tell the manager "Fix this connections score, or else people will leave the team."

But if they fixed the connection score, but people still left the team, they wouldn't be able to get away with that as a success. The metric is a proxy, not the target.

That's bullshit and you're gonna scare the shit out of any junior Amazonian reading this unnecessarily. Obviously nothing is TRULY anonymous - at the end of the day there is a super secured database that HR can go into if there is a need. The data is there much in the same way that every email you send is discoverable in a lawsuit. Or if you get fired and bring a USB key and copy all your data they'll get it. Nothing you do on a work computer is truly private.

But that doesn't mean anyone's manager has access to some secret dashboard to get any of this data or is able to view it on demand. Short of a serious legal case it just won't be relevant.

Noone's manager has access to individual answers and neither does anyone in their org chart.By default, week-over-week, that connections information is private.

What actually (probably) happened is your team's scores were shitty and somewhere up in your org chart noticed and started giving your manager shit to improve them. Then they went in and decided to use their best guesses about who voted for what to start harassing people to figure out how to improve things.

They absolutely epitomized Goodhart's law and they got the result they wanted - you stopped giving a shit and voted for whatever got them off your back.

That sucks but thats not how it is on most teams. Every team I've been on used this data bi-weekly or monthly to have an honest review of what we're doing well and where we need to improve. Nobody gets picked on. If there is a clear outlier where one person was unhappy we don't try to find out why but I (as a senior leader) try to be vocally self-critical and try to come up with multiple guesses and/or reasons for why they might have said that, and what could be done about different root causes. (TO not force whoever was the outlier to speak up).

Your manager sounds like an idiot/asshole, but the least I can say from looking up your name is at least your former manager isn't managing anyone anymore!

Every competitive has a stack ranking system whether they admit it or not.

They put lipstick on a pig but everyone's getting ranked and the lowest performers getting weeded out.

The whole "People get fired even if they're doing a good job just by being a low performer on a strong team" is an edge case that happens INCREDIBLY rarely but when it does gets all the attention.

That's not a conspiracy theory,

I work for Amazon - for a decade. I love it - best job I've ever had. And historically, while it's been a tough place to work, we've always been able to attract top talent. Partially - impactful work. Partially - stock doubles every year.

Well guess what happened in 2020/2021? Despite incredible perseverance through the Pandemic, the stock stopped doubling.

Meanwhile, Microsoft, Meta, and others figured out that they can poach our engineers with a promise of way more base salary, and a less intense work environment.

We've had SDE1s (Juniors) leave Amazon for Meta because they got more money than our SDE3s (Seniors) were getting.

SDE2s (Intermediate) looked at their status quo thought "I COULD bust my ass and get promoted to Senior...or I could go to Microsoft TODAY, get a Senior offer for what I'm already doing, and for more money than my raise would be". (No offense to any of my friends at Microsoft, but https://www.levels.fyi/?compare=Amazon,Microsoft&track=Softw... doesn't lie)

I've talked to a few acquaintances that have left and the universal responses is: "My job is so boring now. I miss Amazon. But It's not stressful (because there is no pressure on me), and I get paid more money".

How can anyone think there is anything wrong with that? You can't. You can speak about Mission and Impact, and some engineers will be attracted to that - I work on building Forever APIs in the AWS Cloud that gets millions of transactions per second. That to me is WAY more interesting than working on Chat app 15/18.

But for most people they just want to make money and live their lives. Fair enough!

The result? Even though Amazon has adapted somewhat by bumping salaries, they've still lost an ocean of people to nothing particularly ambitious or interesting. They're being parked by Microsoft/Google/Facebook to work on boring unimpactful projects so they can't help Amazon kick their asses.

Sometimes one way to make your house nicer is by breaking the windows in the neighbor's house.

For what it's worth, working at Amazon for a bunch of years now, this is the highest percentage of people that truly Give A Shit, I've ever encountered.

I know it's not universal but in the parts I've worked in, it's intoxicating.

Very team-specific again.

There are definitely horror stories of teams that are struggling to hire (because of misinformation like in this thread), yet still have to maintain a service operationally, so have an oncall rotation of 4 people. 25% of your life getting paged? No thank you, not for me.

Usually, these get identified, escalated, and some form of help is brought in. But it requires a manager not to be too proud to ask for help.

Most coworkers I know do maintain 40-45 hour weeks, and most oncall rotations are 8-10 people so you're oncall ~once every 2 months.

COVID has been interesting - some folks went off the deep end and ended up working too much and burnt out. Some found a happy work life balance and realized there are more important things in life than work.

That said, if you're a foundational AWS service, and when you go down half the internet goes with you, when there is an issue, it's all hands on deck to try to fix it (up to the CEO level. When there is a public announcement of AWS impairment, the CEO gets updates every 10 mins whatever the time of day. Because of deep deep ownership). Those don't happen very often (maybe quarterly?)

And if you're not on a team on such critical path, things are a lot more relaxed. But the people that are on this critical path think it's worth it because the fulfillment and pride in being on the critical path for so much technology is itself a worthwhile mission.

You're right, but when they adjusted the L6 role guideline (circa 2016), it was specifically to clarify that the L6 role was never intended to have that span of influence. Rather, every 2-pizza team (8-13 people) should have a sr. engineer. What at Google would be a Tech Lead.

I'm glad you asked because it's a subtle thing, and may be related to me personally. But I would venture I'm not the only engineer like this.

For me, I spent my whole career bouncing against the walls constraining of what an engineer role was supposed to be. I'd push back against requirements from Product Managers and be told I'm ruffling feathers. (Not directly, but indirectly). I'd see QA or Documentation struggling, and I'd jump in to help, and be told later that my contributions there are not appreciated.

I'd see another part of the company do something wrong, bring it up, and be told there's nothing I can do.

I'd have a great idea and be told "that makes sense, but we can't do it for <unsatisfying reasons>"

Amazon, on the other hand, always nurtured this within me. Good ideas reign supreme. Most people I work with have very little ego - they just want to do the Right Thing for customers, and ship great solutions that solve real problems. NOTE: I'm not claiming this is universal. There are plenty of egomaniacal assholes that ruin whole teams. Those horror stories are out there too. But in my experience, working on 4 different teams, in 3 different geographies, they are by far the exception.

My last 3 years in my career before Amazon, I was the tech lead for 3 different year-long projects in 2 different companies. Each we built exactly what we set out to do. Each went into production. Each was a collossal failure. Why? Customers didn't want it. We didn't solve the right problem.

This has NEVER happened to me in a decade at Amazon. The "Working backwards" process is LEGIT. There are notable exceptions (Firephone!), but every single project I've personally worked on has been a monumental success. That's super important to me. I want my work to have meaning. I don't want to write code, exchange it for cash, and move on to the next thing. I want the things I build (mostly AWS services) to be useful to someone.

So, this is what fulfillment means to me:

* I can define my own job description via a lot of Ownership, and work on big problems within my job role (SDE), and outside of it. Despite Amazon's huge size, I never feel like a cog in a machine. I have a lot of power to fix problems I see in my team, org, and in the rest of the company.

* Everything I've built I know has made an impact on people's lives (Developers, and their productivity) and that impact only grows. It feels really good knowing hundreds of thousands of developers are each a little (or a lot) more efficient and can spend more time on interesting problems rather than boring cruft, by using stuff I built.

The "learning and improving" part is interesting. I would unequivocally say yes, and was a huge part of what I loved about the company a decade ago when I first joined. But that part is also as much a curse as is a blessing. Sometimes I actually wish I could just pause and keep doing what I'm doing and be GOOD at it without tackling the next tier of challenges. But it seems that as soon as I get good at anything, I find myself seeking the next level of complexity, and the company is equally happy to throw me into an even deeper part of the pool. So to some degree I always feel like I'm on the edge - always not sure if the problem I'm working on is solvable. At this point I just know that I'll get through it and figure it out in time. And if I don't, I'll learn a lot about why it doesn't work. So maybe I just take this for granted now. It doesn't spark joy day to day, unlike the other 2 bullet points.

This comment isn't directed to you specifically, but the many many others who feel the same.

"What have you got to lose?"

By that I mean, we're in a hot tech market. If it doesn't work out, you can likely find a job elsewhere with ease.

OK, but we're about to hit a recession. I'd venture Amazon is a lot safer than many other tech companies to ride out a recession in - the core business (cloud and retail) is fundamentally sound. The company is only ever not profitable when it chooses not to be because it invests all gains into new R&D and lines of business. When things tighten in the market, Amazon refocuses on core optimizations, and realizes massive profits again. Certainly I can't predict layoffs or no layoffs, but noone can, at any company.