2022 年离开 Uber 是我为自己做的最好的事 🚶💼

tl;dr📖

我在 Uber 的工作很轻松——工作体面，同事也很棒。但繁文缛节让人应接不暇。太多的审批和许可让事情难以完成。我希望开发并交付优秀的产品，而不是每次需要完成某件事时都要等待十几个人的基本审批。而且，Uber 当时的开发效率指标也不太合理。

当与经理交谈没有帮助并且我无法尽快产生影响时，我决定离开并从外部解决这个问题。

“摆脱枷锁！”他们说……

现在，更长的版本...

Uber 的舒适度

曾几何时……作为一名技术主管，我拥有一切：丰厚的收入、有趣的工作和认可。但总觉得少了点什么。工作虽然重要，却缺乏成就感。交付大多数成果往往耗时过长。衡量开发人员生产力的指标显得捉摸不定、不充分，而且并不总是能反映出真正的成效。

离开 Uber 那份舒适、高薪的工作是我做过的最艰难的决定之一（我花了几个月的时间才决定）。

超级办公室S01E01 🏢

我在 Uber 的第一个项目非常棒，所有经理都很棒。事实上，就我个人经验而言，我很喜欢所有与我共事的人。他们友好、技术娴熟、体贴周到。

这个项目几乎是我和我的小团队从零开始打造的。它非常注重可访问性，背后投入了大量的设计精力，正是我乐意参与的项目。

而且由于它是从零开始构建的，所以没有太多过去的包袱需要背负。核心团队之外也不需要太多的“批准”。规划、设计和执行都在“核心团队”内部进行。这意味着协作非常快，执行也同样如此。

但这种情况不会持续太久。

然后蜜月期就结束了……

每个人的经历都不尽相同，我后来的项目也没什么意思。对大多数人来说，这只是一些小功能或维护工作。即使是中等规模的功能，我也只是成千上万个开发者中的一个，最初的敬畏之情很快就消失了。感觉好像我缺席几天，或者休假一周，都不会对任何事情产生重大影响。我不喜欢这样。

我的表现也并非不佳。我的表现一定很棒，因为这在我的反馈周期、评估以及我获得“影响力奖”的事实中都得到了一致的体现。
只是感觉尽管如此，我并没有做我想做的事情。

繁文缛节

大公司就像一艘又大又重的船，它会去到它该去的地方，但这需要时间，而且它改变航向的速度肯定非常慢。

在 Uber，他们拥有数千个代码库。随着时间的推移，内部的“审阅者”配置会不断更新，将新的审阅者添加到列表中，通常不会删除较旧的审阅者或那些不再相关或参与该代码库的审阅者，而是根据具体情况进行处理。

Uber 也拥有令人惊叹的 ERD 概念（当然，这并非 Uber 独有）。ERD 本质上就是 PRD，但具体到工程和实现层面却非常具体。但这个想法也因为繁琐的流程和最终需要参与的人数过多而进展缓慢。

这个阶段可能会耗费数周时间！当然，这能带来一些非常扎实、经过深思熟虑的实施，而像 Uber 这样的公司，为了更稳健的实施，可能会承受一些延迟。只是……

没有人验证实施是否与文档一致。
初衷是好的，但执行得并不好。

“有一天，我想成为那种在交付代码之前要经过 5 个繁文缛节的开发人员！”——从来没有人这么说过。

当 Metrics Nation 发起攻击时，一切都改变了🔥

在我任职的前半段时间，年度考核需要一段时间才能完成。经理和其他团队负责人会组成一个小组，手动收集数据，通过数字来评估开发人员。
当时我并不知道这些指标是什么，也不知道它们的权重有多大。我所知道的是，当时几乎没有自动化手段，这是一个相当手动的过程（后来这种情况有所改变）。

人际反馈和经理的直接评估非常重要，整个流程总体感觉相当透明。我对此还算满意。不过，他们也努力让这个过程自动化……

创建仪表板是为了跟踪各个团队的个人统计数据。

而且……其中一项衡量指标是每月代码行数和 PR 数量。😱
没错……你只需要 0.01234 微秒就能意识到这是个坏主意。几天之内，开发人员就开始人为地夸大 PR 数量，在不必要的情况下拆分 PR，以此来抬高这个数量。

我不怪他们。🤷

所以，我尝试解决这个问题💪

我一直喜欢解决问题。空闲时间我会做解谜游戏，也经常在电脑上玩策略游戏（除了在《德军总部》里射杀纳粹，或者在《星露谷物语》里拯救我的卷心菜地的时候）。

我经常会不遗余力地解决那些影响我或我团队的开发者体验、生产力、文档等方面的问题。我觉得这很有趣。🤷

我一直是一位充满热情的开发者。我关心自己构建的东西，也关心我的开发者同事。自然而然地，我也关心评估过程。

当自动化仪表盘开始用于评估我们开发人员时，我们自然而然地开始谈论它，而且随着时间的推移，讨论的频率越来越高，因为用于这方面的指标感觉存在很大缺陷。而在我留在 Uber 的那段时间里，与领导层讨论这个问题并没有改变什么。

可玩性指标

🗓️ 此刻，我们已经进入 2021 年下半年 🗓️

衡量开发人员生产力的指标常常感觉更像是一场游戏，而不是工作质量的真实反映。晋升有时基于这些有缺陷的指标，导致开发人员感到沮丧。我非常想在单独的 PR 中做一些较小的相关更改，而通常我可能不会这样做。感觉很假。

测量的一些具体内容包括：

1. 每月 PR 数量
   • 开发人员开始制作比需要的更小或更无关紧要的 PR
   • 如果 PR 数量不足，开发人员就会开始为旧的低优先级项目创建 PR
   • 一些 PR 开始被同一团队中友好的开发人员批准，以增加 PR 数量
2. 每个 PR 的行数
   • 开发人员开始编写更冗长的代码
   • 额外的换行符
   • 不必要的重构

当然，并非所有开发者都同意这样做。但有些开发者同意，尤其是那些在这些统计数据上得分较低的开发者。通常，得分较低可能是因为他们正在从事一些需要更多规划、设计或文档参与的工作。但这些仪表板并没有体现这些方面。

我们与领导层讨论了此事，特别是关于这可能更有害，以及以前的做事方式似乎更好，虽然他们似乎同意，但实际上什么也没有改变。

而那时我已经对自己在 Uber 的工作经历越来越不满意了……

这就到了 2022 年🗓️

中间件的理念

大约在这个时候，Dhruv 向我提出了中间件的想法。这个概念很有意思：一个旨在让开发人员真正完成工作的平台，并突出显示阻碍他们做自己喜欢的事情的因素、瓶颈、流程障碍等等。

我首先想到的是......
“如果我有这样的事情可以向我的经理展示见解，那将比他们现在所做的任何事情都更有帮助。”

经过几个月的讨论和考虑，我终于在2022年8月决定迈出这一步，和他一起踏上这段旅程。这个决定并不容易，但感觉很对。🚀
这也正好是我生日后的两天！🎂

创业热潮

从零开始打造一款产品非常艰难。我们必须筛选海量数据，并将其清晰地呈现。我们深知，并非所有指标都重要；我们只展示有用且可操作的数据。

我们的目标很简单：
打造一些连我们过去的工程师都觉得合理的东西。

打造合适的团队至关重要，而且需要持续不断的努力。在领导力、团队活力和公司文化方面，我们学到了很多宝贵的经验。事实证明，NERF 几乎解决了所有问题。😂 开个玩笑，开个玩笑。
发展一家公司意味着要处理财务、市场营销、合规性，当然还有客户。这比我在 Uber 工作时学到的要多得多。

回顾这段旅程，我可以自信地说，它既艰难又令人欣慰。创造一些有意义的东西比我在 Uber 放弃的舒适感更重要，然而，如果没有妻子 Mehak 的支持，这一切将会更加艰难。

是的，我会毫不犹豫地再做一次。💗

嘘！
如果你想看看我们一直在开发什么，就来这里吧。如果你能在这个代码库上点个星，那对我来说意义重大。😄