为亚马逊编写代码是什么感觉(结论)一线希望正在继续……

2025-06-04

为亚马逊编写代码是什么样的体验(结论)

一线希望

继续...

(您可以在此处阅读本文的第 1 部分:https://dev.to/bytebodger/what-it-was-like-to-code-for-amazon-part-1-5034。第 2 部分:https://dev.to/bytebodger/what-it-was-like-to-code-for-amazon-part-2-5aon

如果你读过本系列的前两篇文章,你就知道我的亚马逊经历……不太理想。但我首先要承认的是,我其实并不了解在亚马逊编程究竟是什么样的。事实上,即使你以前为亚马逊写过代码,或者现在正在为他们写代码,你也不知道为他们写代码究竟是什么样的。这家公司规模太大,开发人员太多,分布在各个团队和地点,任何一个人都无法权威地描述出亚马逊的整体开发体验究竟是什么样的。

在这么大的公司里,你真正能做的就是评估自己的经验。有些人可能有过和我类似的经历,甚至更糟。但我也确信,有些亚马逊程序员在那里过得很开心。这在某种程度上取决于你具体在哪个团队/小组工作,你为谁工作/与谁共事,当然,还有为这份工作带来了什么。

但是,尽管我无法描绘出一幅广泛而明确的画面,确切描述亚马逊任何团队/团体中任何人的状况,但我确实看到了足够多的情况,可以得出一些有趣的结论。


图片描述

口头上坚持“原则”

亚马逊不断宣扬他们的“领导原则”。面试时他们会问你这些原则,公司会议上也会讨论这些原则。至少表面上,他们为这些原则倾注了大量精力。(如果你感兴趣,可以在这里查看:https://www.amazon.jobs/content/en/our-workplace/leadership-principles

不幸的是,这些强调很多都是空谈。(我知道,我知道。一家超级企业并不总是践行其宣称的理想。令人震惊!!!)我可以逐一分析这些原则,并根据我在那里的短暂任期挑出毛病。毫无疑问,我的观点受到了自身负面经历和(诚然短暂的)任期的影响。但以我的经验来看,最明显彻底失败的“原则”例子是:

坚守主心骨;敢于表达不同意见,勇于承诺。
领导者有义务在意见分歧时,以尊重的态度挑战决策,即使这样做会令人感到不适或疲惫。领导者坚定信念,意志坚韧。他们不会为了维护社会凝聚力而妥协。一旦做出决定,他们就会全力以赴。


我见过太多例子,让这条原则成了彻头彻尾的笑话,我甚至无法在这里一一列举。而且,我谈论的不仅仅是我的经历。我谈论的是我在其他部门目睹的事情,以及其他员工直接告诉我的事情。

我目睹过太多人们根本不敢发声的例子。我参加过一些会议,除了“发言人”之外,没有人敢提出任何反对意见。即使他们费心提出担忧,我也看到这些担忧被强行搁置,因为没有其他办法能让管理层满意。


图片描述

一个有说服力的观察

当我写这篇关于在亚马逊工作的文章(https://dev.to/bytebodger/what-its-like-to-code-for-amazon-4nke)时,公司另一个部门的一位高级开发人员在 Slack 上联系了我。他称赞了这篇文章,感谢我写了这篇文章,并说很高兴看到我相处得很好。

我感谢他的反馈。但我也告诉他,自从我写这篇文章以来,我遇到了一些非常棘手的情况。(我没有像他一样,滔滔不绝地讲述所有发生的事情,只是大致地概括了一下要点。)他的回复很有启发性。

他是澳大利亚人。他告诉我,在他之前的工作中,开发团队经常会讨论某个已经开发完成的应用程序的某个特定部分。他​​们经常会互相说:“是啊……这有点糟糕,不是吗?”

但他也告诉我,他刚加入亚马逊时也遇到过类似的问题。因为在他入职后的很长一段时间里,没人愿意听到任何异议——哪怕他们只是把“异议”当作一种讨论问题、(希望)找到更好解决方案的手段。

他的具体建议是,先低调一段时间。别说太多。只要“顺从”别人给你下达的任何指令就行。然后,只有当你加入一段时间后,才有可能针对一些具体的事情发表意见。

坦白说,我明白这一点。我得先告诉你,没人希望新人第一天上任就立刻告诉大家,他们的工作做得很糟糕。老款应用简直糟透了。他们现在的所有做法都应该彻底废除。

但是,傲慢自大、自以为是和谦逊自信的团队成员之间是有区别的。有时,一些最好的建议来自新人。因为其他人已经习惯了“一成不变”的行事方式。只要新人不是个自大狂,观察别人如何以全新的视角看待问题就很有价值。

这就是“有骨气、不同意、不承诺”的精髓所在。如果你发现任何“不对劲”的地方……就说出来。和你的同事、你的经理,或者你的利益相关者讨论。

有时,当你提出这些担忧时,你会被“否决”。这没关系。有时,你可能会发现人们实际上同意你的观点——但还有其他实际原因导致他们继续这样做。再说一遍——这没关系。但至少进行这些对话,比仅仅因为提出了合理的担忧就担心被贴上“不满者”的标签要健康得多。


图片描述

老大哥心态

这是我在亚马逊多次遇到的事情。我发现它有点……令人不安。

我会在 Slack 上和别人聊一些看起来“不对劲”的事情。可能是关于一个项目,也可能是关于某个人,甚至可能是关于整个公司。在这种情况下,和几个不同的人聊天时,Slack 对话会在对方输入以下内容时结束:

也许我们应该删除这个 Slack 对话?


现在要澄清的是,我们不是要炸CEO的家。我们也没骂谁混蛋。事实上,我们在Slack上讨论的那些我不敢当面跟别人说的事情,我们只是在讨论我们遇到的问题,以及潜在的解决方法。

然而,很多时候,我的 Slack 同事都会建议我们删除帖子,以此来结束对话。想想看……说实话,每次遇到这种情况,我都觉得挺心寒的


图片描述

明目张胆的背后捅刀

编码二十五年了,我已经记不清有多少同事不喜欢我了。在太多公司工作,和太多同事共事,难免会有人对你“不顺眼”。但这不是我在这里想说的。

尽管我的职业生涯中经历过各种各样的人际冲突,但只有一家公司让我经历过公开的背后捅刀子。没错,这家公司就是亚马逊。

我说的“背后捅刀子”并不是指有人说我是个混蛋(举个例子——这可是个很长的句子)。我也不是指有人说我的代码、交付成果或任何与我的工作成果有关的事情的坏话。我指的是有人当着我的面说我做得很好,然后每当项目遇到任何挫折时,就转过身去告诉所有人我把一切都搞砸了。

在我的职业生涯中,曾有人当面告诉我,他们觉得我把事情搞砸了。说实话,一旦你克服了当时的情绪波动,有时这些互动最终会以非常积极的方式结束。但我从未遇到过这样的情况:有人当面说了一句(非常支持我的话),然后又在我不在场的情况下对另一个人(高级管理层)说了完全相反的话。


图片描述

前端近视

亚马逊的软件工程师绝大多数专注于后端开发(具体来说,是 Java)。这本身并没有什么问题。但该公司对前端开发的整体看法似乎在 2015 年陷入了困境。

作为亚马逊的常客,早在我去亚马逊工作之前,我就注意到他们的用户体验相当……欠缺。现在我知道原因了。

公平地说,他们成功地通过自己的网站创造了数十亿美元的收入。所以我不会说他们的前端界面有什么“问题”。而且,当你运营一个如此规模的网站时,必然会有很多其他99.99%的网站根本不适用的考虑因素。

我也承认,亚马逊确实有一些团队在做采用现代标准的前端工作。但看到这么多团队对现代前端功能一无所知,真是令人不安。哎呀,我甚至见过一些团队对任何现代前端方法都抱有敌意。

在亚马逊的内部知识库里,一位终生从事 Java 开发的程序员写了一篇长文,大谈前端应用(以及像 React 这样的现代框架)如何难以管理且不可扩展。这篇文很长。我加入后不久,就问过我们的一位 Java 开发人员,为什么我们要这样做。他的回复是……把那篇内部文章发给我。

别在意这篇文章是2017 年写的。也别在意文章本身,文章开头早就有免责声明,指出其中的大部分论点现在都存在疑问。这些都不重要。重要的是 JS 框架“不好”(好吧……),而老式的客户端-服务器架构“好”。


图片描述

一线希望

我最后的观点也带来了一丝希望(至少对我来说是这样)。我们都知道,亚马逊只是过去六个月里众多裁员的大型科技公司之一。虽然我理解裁员在宏观层面上是企业生活中一个令人悲哀的现实,但亚马逊竭尽所能,确保他们在此事上的内外部沟通极其笨拙,坦率地说,非常不专业。我不会在这里详细阐述这些。我相信你已经读过科技/商业新闻里的文章了。

上个月,安迪·贾西又出了一件令人不快的事。从5月1日起,他们要求每个人每周至少在办公室待三天。我相信,最终会有人设法逃避这项规定。但目前为止,所有迹象都表明,几乎没有例外。

这让我感觉有点……轻松,虽然有点恶心。你看,我住在佛罗里达州。我是一名远程工作者。我被录用时,offer里明确写明了我会远程办公。我团队里还有其他人也打着同样的幌子工作。就算去年那些糟糕的事情没有发生在我身上,就算我一月份没有被解雇,现在的整个情况也会让我感到压力重重、怒不可遏。

所以我想,归根结底,最后一年的“地狱”生活对我来说不会有任何好转,即使我从未在团队里遇到过任何问题,即使我从未在裁员中被解雇。虽然听起来很奇怪,但这实际上让我对整个经历感觉“好了一些”。

我不想粉饰太平:亚马逊现在的做法是对过去几年雇佣的数十名员工的公然背叛,他们明确表示过这些员工会远程办公。这同样也背叛了西雅图的许多员工,他们做出了重大的生活改变(比如……从西雅图搬到了美国其他地方),因为他们一再得到保证,不会被迫回到办公室。


图片描述

继续...

到目前为止,我已经在这个网站上发布了112篇文章。其他文章我都是为了传播知识、向 Dev.to 社区学习并促进讨论而写的。这一系列关于我在亚马逊生活的文章,是我第一次在这里写一些不这些目的为目的的文章。最后这三篇文章,我是为了我自己而写的。正如我在第一部分中所说,这基本上是我的一种自我疗愈——一种让我向虚空呐喊的方式,让我可以倾诉过去一年里经历的种种不如意。

话虽如此,这个(并非如此)的小故事并非悲剧。远非如此。我目前正在评估一位潜在雇主提供的一份非常不错的录用通知。我预计在接下来的几天里还会收到其他几份不错的录用通知。

简单的事实是,无论下个月我在哪里工作,也无论这里的任何人如何看待我的亚马逊故事——我都会过得很好。事实上,我会过得非常好。

正如你从这三篇文章中无疑推测的那样,我的亚马逊体验中确实有一些方面仍然糟糕透顶。有一段时间,主要是从2022年11月到2023年1月,这一切都严重损害了我的身心健康。

但你知道吗?那都过去了。生活还要继续。很快,我就会去别的公司惹恼别人。

小心!

文章来源:https://dev.to/bytebodger/what-it-was-like-to-code-for-amazon-conclusion-3468
PREV
程序员和普通人的思维模式有什么不同?
NEXT
远程工作的风险