Current sde1 bluebadge. I also see exactly what the parent comment mentioned. I also saw a few nasty episodes such as L6 managers quitting in less than a year in because they hated the pressure they were subjected to, and a yellowbadge say during a all-hands to a bunch of newly arrivals that he was at the company when they joined and he will still be at the company when they all left. I know of a team where SDE2s and SDE3s felt the need to pull in all-nighters and even work the entire weekend to meet the deadlines that their L7 leadership pulled out of their ass. I myself felt compelled to work close to 12 hours a day and weekends during a period just because my senior manager wanted to shine. And yes, I've already see a fair share of colleagues disappear.
Of course YMMV but I'm baffled why I'm seeing accurate descriptions of what I'm personally experiencing on a daily basis being faced with such a sense of incredulity.
> because the engineering quality is so shoddy and the business plan prioritizes maintaining system uptime,
I've created this throwaway account just to comment on the issue of engineering quality being shoddy.
It's true that engineering quality is shoddy but the problem is caused by Amazon's structure and not by the engineers themselves. For example, each and every single engineer is expected to deliver major tasks alone as part of their evaluation process, and this means that by design we are placed on tasks where we are way over our head and we are still expected to deliver things out of thin air. This sort of trial by fire is sold under the premise of allowing us to deliver consistently at the next level before being considered for a promotion, but in practice if you screw up that's expected to also be held against you.
Things are very dependent on team and manager and org but I will say that one of the things I'll never miss is our Re:Invent launch. That was horrible. Our team (startup acquisition) basically had a giant retro after the launch to figure out how we could avoid doing that again. Most of the startup members left the team of the company 2 years in. I learned a lot.
blue = full-time/permanent employee
white = seasonal/temp employee
yellow = vendors (and DSP employees, if I remember right).
It's more or less their way of tagging you with a yellow star so they know who they can treat like shit. Hah, just kidding, they treat everyone like shit.
I've worked at two different facilities in CA and never once seen those. We still used the white/yellow/blue badge scheme.
Are there any ambassadors in this thread who know what those are?
Saying someone is a yellow badge badge is saying that they are a full time employee with 5-9 years of tenure, most SDEs don't work with contractors so we don't talk about yellow badge contractors all that often.
If you're interested in this sort of thing, the color is actually supposed to be orange, but the color came out yellow.
TL;DR DSP drivers don't encounter many blue badges.
Is an entity imposing an identification system for quickly singling out populations with invisible but immutable characteristics? If so, the Yellow Badge comparison is apt because that's exactly what the nazis did with their badging system.
Amazon identifying people within certain buckets of employment doesn't fit this comparison because opportunities exist (in theory) for people to take other roles, to quit, or to be terminated, making Amazon badges identifiers of a mutable characteristic.
Now, is badging people by employment class a crappy thing to do? Probably. Easy way to enable eyeballing a worker and denying certain perks, for instance. But it's also useful in determining whether a person is qualified to hear certain company-confidential information.
---
tl;dr: There's never a good reason to compel visible identification for an immutable trait, but that's also not what Amazon's badging scheme is, so using the comparison risks cheapening the original sin.
Hope this helps anyone reading. And to any historians who probably know better than I do, kindly fact-check me. I only know enough to be dangerous, not useful.
I can understand how junior devs end up in these positions for a while and stay on the ride, but what is making someone with your level of experience you stick to Amazon? Is the compensation that good?
Quit now, and encourage your teammates to do likewise. I understand where you're coming from, but the attitude you have can be a source of exploitation (e.g. using loyalty to peers to keep you while the org screws all of you more).
Some of the problems you can work on in such an environment are interesting.
Combine that with the fact that you don't see this before joining and that some.manager s might be able to shield some of it you are where you are.
And then throwing hands in the air and leaving is a step, as most other companies have "smaller" problems to solve and "also bad management" ...
> the engineering quality is so shoddy
What stuns me is just how well AWS works. I mean, did you ever try to use Azure in 2015? Hell, even GCP was worse in that era. Now, it's on-par, but IMO "more confusing" which beggars belief considering how confusing AWS is.
Disclaimer: Former logistics Amazonian.
This is systemic in Technology companies because, to me, the “bean counters” try to run the companies like a basic Manufacturing organization of commodities where line items and people are substitutable things and can be dialed and tweaked at the planning stage.
GCP is an odd duck. It really wants you to do things its way. But if you are doing a multi-cloud strategy the last thing you want is to go all in on the GCP way. Also they just don’t seem to treat customers as seriously as Amazon and Azure. It isn’t life or death for Google and it shows.
I mean this how Amazon treats all of its employees. It can't quite lock devs and ops people to a desk and have them piss in bottles, but they would if they could.
So on what basis ia Amazon incompetent at software? It sounds like Amazon is results driven, and pretty well-unit-tested code isn't critical for that.
It may also be relevant to point out that Amazon is first and foremost a retailer, unlike the other companies mentioned.
I feel these days that it's more correct to say Amazon was first and foremost a retailer, but these days they are just UberMegaCorp across so many businesses (Amazon site proper, AWS, WholeFoods, Kindle, Echo/Alexa, movie studios, etc. etc.) that it's hard to say they are foremost a retailer.
I have a similar question, though, in that I've heard lots of nightmare anecdotes about Amazon code quality, but obviously whatever they are doing is working on some level.
1) Amazon has been incredibly successful frontrunning two MASSIVE verticals: online retail, and cloud computing. They were early winners and invested an INSANE amount of money to be #1. That gives them a lot of leeway to fuck up and still be on top. Even if they stopped doing anything at all but maintaining whatever shit show is going on behind the scenes, it'll be a while before they aren't #1 in at least one of those two huge markets.
2) Tech debt doesn't hurt you today, it hurts you tomorrow. You can cut corners and get products out the door fast, but eventually features and products that should take X amount of time, instead take 5X. Given their lead in their units heavily reliant on software, I doubt it would hurt them anytime soon.
3) You can shit on a lot of people for a long time before it hurts hiring when your stock has shot up the way Amazon's has. Money will make people do dumb things.
4) It takes a long time for poor hiring and management practices to incapacitate an organization the size of Amazon. Turn over at the bottom may be high, but I doubt it's the same at the top, at least up until the past few years. When leadership starts turning over more you'll see a lot more business mistakes.
Everything the parent comment mentioned is exactly what we see. Laughably, our middle manager berates us as incapable noobs, entirely unaware that some of us at least actually have been very valued and trusted and dependable hard core results driven engineers for decades. It's like a failed brainwashing attempt, and it's embarrassing to be associated with such idiocy.
I contrast it with excellent experiences at Sun, Motorola, Apple and others over the past 20+ years, where in some cases I had very high engineering ranks with fabulous results, in very well run and just healthy orgs.
I do believe there's intentional treatment of engineers as fungible assets, because the engineering quality is so shoddy and the business plan prioritizes maintaining system uptime, with no true priority given to tech debt removal, which actually would in short order surface measurable benefits.