(You can read Part 1 of this article here: https://dev.to/bytebodger/what-it-was-like-to-code-for-amazon-part-1-5034. And Part 2 here: https://dev.to/bytebodger/what-it-was-like-to-code-for-amazon-part-2-5aon)

If you've read any of the first two articles from this series, you already know that my Amazon experience was... suboptimal. But the first thing I have to acknowledge is that I don't actually know what it's like to code for Amazon in general. In fact, even if you've coded for Amazon in the past, or even if you're coding for them now, you don't know what it's like to code for them in general. The company's far too big and there are far too many devs strewn across myriad teams and locations for any single person to say, with authority, exactly what the overall dev experience is like.

In a company that large, all you can really do is assess your own experience. Some people may have had experiences similar to mine - or worse, even. But I'm also certain that some Amazon coders are perfectly happy there. It all depends, to some extent, on exactly which team/group you worked within, who exactly you worked for/with, and of course, what you brought to the experience.

But while I can't paint a broad, definitive picture of exactly what it's like for anyone, in any Amazon team/group, I did see enough to draw some curious conclusions.

Lip Service To "Principles"

Amazon constantly touts their "Leadership Principles". They ask you about them when you're interviewing. They talk about them in company meetings. On the surface, at least, they pour a lot of effort into these principles. (If you're curious, you can see them all here: https://www.amazon.jobs/content/en/our-workplace/leadership-principles)

Unfortunately, a lot of this emphasis is empty talk. (I know, I know. A megacorporation that doesn't always live up to its own stated ideals. SHOCKING!!!) I could go through them one-by-one and nitpick them based upon my short tenure there. And my perspective is, undoubtedly, biased by my own negative experiences and my own (admittedly brief) tenure. But in my experience, the most glaring example of a completely-failed "principle" is this:

Have Backbone; Disagree and Commit
Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.

I saw so many examples that made this principle an outright joke that I can't even list them all here. And I'm not just talking about my experience. I'm talking about things I witnessed in other areas of the organization, and things I was told directly by other employees.

I witnessed so many instances where people were simply afraid to speak up. I sat in meetings where no one but the "talking head" dared utter any kind of objection. And when they did bother to raise concerns, I also saw where those concerns were bulldozed because there was no alternative that pleased management.

A Telling Observation

When I wrote this article about working at Amazon (https://dev.to/bytebodger/what-its-like-to-code-for-amazon-4nke) a senior dev from an entirely different part of the company reached out to me on Slack. He praised the article, thanked me for writing it, and said he was glad to see that I was getting along nicely.

I thanked him for his feedback. But I also told him that, in the time since I wrote the article, I'd run into some very difficult situations. (I didn't deluge him with the full, insanely-long story of everything that had happened. I just gave him the high-level bullet points.) His response was very telling.

He was Australian. He told me that, in his previous job, there were many times when the dev team would be discussing some particular bit of an application that had already been built. And frequently they would find themselves saying to each other, "Yeah... this is all a bit crap, isn't it?"

But he also told me that, when he came onboard at Amazon, he had very similar problems. Because, for a good bit after he was hired, no one wanted to hear any kinda dissenting opinions - even if they were only "dissenting" as a means to talk out the problem and to (hopefully) come to a better solution.

His specific advice was to lay low for a good while. Don't say much. Just kinda "go along" with whatever was being dictated to you. And then, only after you've been onboard for a good bit, maybe possibly speak up about a few targeted things.

To be clear, I get this. I'd be the first one to tell you that no one wants the Brand New Guy to show up, on Day 1, and immediately tell everyone that they've been doing crappy work. And that the legacy app is shite. And that all of their current practices should be thrown out the window.

But there's a difference between being an arrogant know-it-all versus just being... a humble - but confident - member of the team. Sometimes some of the best suggestions come from the new guys. Because everyone else has grown accustomed to everything as "the way it's always been done". As long as the New Guy isn't a cocky jerk, there's a lot of value in seeing how someone views the situation with a fresh set of eyes.

That's what Have Backbone; Disagree and Commit is supposed to be about. If you see something that seems "off"... say something. Talk about it with your colleagues. Or your manager. Or your stakeholders.

Sometimes, when you raise those concerns, you'll be "voted down". And that's fine. Other times, you may find that people actually agree with you - but there are other practical reasons why it will continue to be done that way. And again - that's fine. But it's far healthier to at least have those conversations, rather than being afraid that you'll be labeled as a malcontent merely because you raised reasonable concerns.

A Big Brother Mentality

Here's something that I encountered multiple times at Amazon. And I found it to be a bit... disturbing.

I'd be chatting with someone on Slack about something that seemed "off". Maybe it was about a project. Or about a particular person. Or even about the company in general. And in these scenarios, with multiple different people, the Slack conversation would end when the other person typed this:

Maybe we should delete this Slack conversation?

Now to be clear, we weren't talking about bombing the CEO's house. We weren't calling anyone an asshole. In fact, we weren't discussing anything in those Slack threads that I woulda been afraid to say to anyone else, directly to their face. We were just discussing problems that we'd run into, and potentially how to fix them.

And yet, on numerous occasions, my Slack counterpart would close the conversation by suggesting that we delete the thread. Think about that... Honestly, every time I encountered it, it felt rather chilling.

Blatant Backstabbing

After coding for a quarter century, I've lost track of the number of coworkers who simply didn't like me. Work at enough companies, with enough colleagues, and it's inevitable that some people simply won't "take" to you. But that's not what I'm talking about here.

Despite all the interpersonal conflicts I've navigated throughout my career, there is only one company where I've experienced open backstabbing. And, yes, that company was Amazon.

When I say "backstabbing", I'm not referring to someone saying that I'm a jerk (take a number - it's a long line). Nor am I referring to someone badmouthing my code, or my deliverables, or anything about my work effort. I'm specifically talking about someone saying, to my face, that I'm doing great work. Then turning around, whenever a project suffers from any kinda setback, and telling everyone else that I've screwed everything up.

Throughout my career I've had people tell me, to my face, that they thought I really screwed something up. To be honest, once you get past the raw emotions of those moments, sometimes those interactions can end on an extremely positive note. But I've never been anywhere else where someone told me one (extremely supportive) thing to my face, and then told someone else (in senior management) the exact opposite when I wasn't there.

Frontend Myopia

The vast majority of Amazon's software engineers specialize in backend development. (Specifically, Java.) And there's nothing wrong with that. But the company's overall view on frontend development seems to be mired in 2015.

As a frequent Amazon customer, I'd noticed long before I ever worked there, that their UX was pretty, well... lacking. Now I know why.

To be fair, they successfully drive billions in revenue through their website. So I'm not gonna claim that their frontend interfaces are somehow "broken". And whenever you're operating a site that runs on that kinda epic scale, there are bound to be many considerations that simply don't apply to 99.99% of the other websites that are out there.

I'll also acknowledge that there are some teams in Amazon doing frontend work that utilizes modern standards. But it's kinda disturbing to see how many teams are oblivious to modern frontend capabilities. Heck, I even witnessed teams that were hostile toward any kinda modern frontend approaches.

In Amazon's internal knowledgebase, some lifelong Java coder wrote a long screed talking about how frontend apps (and modern frameworks - like React) were simply unmanageable and unscalable. It's quite a long read. Shortly after I came onboard, I was asking one of our Java devs why we were doing things a certain way. His response was... to send me that internal article.

Nevermind the fact that the article in question was written in 2017. And nevermind the fact that, on the article itself, there's long been a disclaimer, right at the top of the article, stating that most of its contentions are now in doubt. None of that mattered. All that mattered was that JS frameworks were "bad" (mmmkay...) and old-skool client-server architecture was "good".

A Silver Lining

My last observation comes with a bit of a silver lining (for me, at least). We all know that Amazon is just one of many Big Tech companies that's jettisoned scores of people in the last six months. While I understand that layoffs are, in a macro sense, a sad reality of corporate life, Amazon did everything they could to ensure that their internal and external communications around the matter were absolutely clumsy and, quite frankly, unprofessional. I'm not gonna go through all of that in detail here. I'm sure you've read the articles in the tech/business news.

Last month, a new bit of ugliness came from Andy Jassy. Effective May 1st, they're requiring everyone to be in the office at least three days per week. I'm sure that, in the final analysis, there will be some people who manage to get excused from this edict. But every indication so far is that there will be few exceptions.

In a sick sort of way, this actually made me feel kinda... relieved. You see, I live in Florida. I'm a remote worker. When I was hired, my offer specifically stated that I would be a remote worker. There were others on my team working under the same pretenses. And even if all the crap of the last year hadn't happened to me, and even if I was never laid off in January, I'd now be stressed and infuriated by the whole situation.

So I guess that, in the final analysis, the last year of "hell" wasn't gonna turn out any better for me, even if I never had any problems on my team and even if I was never booted under any of their layoffs. As odd as it sounds, that actually makes me feel somewhat "better" about the whole experience.

I'm not gonna make any attempt to sugarcoat this: What Amazon's doing now is an outright betrayal to the scores of people they hired over the last couple of years with the express understanding that they would be remote. It's also a betrayal to so many of their Seattle workers who made significant life changes (like... moving away from Seattle to other parts of the country) because they were given repeated assurances that they would not be forced to come back to the office.

Moving On...

I've put 112 articles on this site (so far). I wrote all of the others to, hopefully, spread knowledge, learn from the Dev.to community, and foster discussion. This little series of my-life-at-Amazon articles was the first time that I ever wrote anything here that was not for those purposes. I wrote these last three articles for me. As I stated in Part 1, this has basically been my self-administered therapy - a way for me to yell into the void about crap that I experienced over the last year.

That being said, this (not so) little tale is not a tragedy. Far from it. I'm currently evaluating one very-solid offer from a potential employer. I expect to receive a few other solid offers in the next coupla days.

The simple fact is that, regardless of where I'm working next month, and regardless of what anyone on here thinks about my Amazon tale - I'll be fine. Beyond fine, in fact.

As you've no-doubt surmised from these three articles, there are absolutely some aspects of my Amazon experience that still feel crappy as hell. And there was a period, mostly from November 2022 through January 2023, that all of this took a serious toll on my mental and physical health.

But you know what? That passes. Life goes on. And I'll be pissing people off at some new company before you know it.

Take care!