保密协议于去年 12 月到期，虽然我怀疑自己仍旧与疲劳带来的后遗症斗争，但我有更多的精力来回顾我在 GitLab 的时光。我将把这篇文章分为两个主要部分：根据我仍然记得的内容概述我在 GitLab 的工作时光，以及我在工作经历中学到的经验。

在加入 GitLab 之前，我在阿姆斯特丹的一家小型初创公司工作。和大多数初创公司一样，在我离开前的几个月里，公司资金开始短缺，不得不采取一些极端的解决方案，例如出租部分办公空间来抵扣成本。

彼时，我认为在技术层面上已经做了所有我想做的、能做的事情。同时，我也在业余时间研究 Rubinius项目，我们考虑过在各种场合使用它，尽可能确保所有代码在该项目正常运行。这也促进了Oga项目的创建 ，是一个可替代 Nokogiri 的XML/HTML 解析库。

不幸的是，缺乏资金加上各种技术问题意味着我们未能推进 Rubinius 的进一步使用。基于以上因素，我开始寻找新工作，至少保证留给 Rubinius 更多工作时间，使它更加稳定以便人们在生产环境中使用。

在此期间，我参加了在阿姆斯特丹举行的各种 Ruby 聚会，并协助举办了一些Rails Girls研讨会。在其中一次研讨会上，我遇到了 Sytse（GitLab CEO）及其夫人，并在后来的研讨会或聚会上再次遇到了（印象是，但时间久远我记忆有些模糊）。通过这次活动，我了解了 GitLab，并对在那里工作产生了兴趣。

2015 年夏，我给 Sytse 发了一封电子邮件，表示我想为 GitLab 工作，并询问他们是否同意我每周留有一天为 Rubinius 工作。随后的对话和面试让我于 2015 年 10 月开始在 GitLab 工作，担任第 28 号员工。我的任务是提高 GitLab的性能，同时公司允许我将 20% 的时间花在 Rubinius 上。任职期间，我参与了很多团队的工作，具有相当大的自主权，多年来向 10 位不同的经理汇报，差点让公司倒闭，构建了 GitLab 至今仍在使用的各种关键组件，见证公司规模从30多位员工增长到大约2000位，最终陷入了倦怠状况。用荷兰谚语形容就是：“Lekker gewerkt，pik！（做得好）”。

我在前司的最后一天是 9 月 30 日，星期三，紧接着第二天我就开始在GitLab 工作。这意味着我从每周在办公室工作五天变成每周远程工作五天。虽然我以前也尝试过在家工作，主要原因是铁轨上有少量积雪或树叶造成火车停运，但适应新的工作安排还需要一些调整。

我对这段时期的特殊记忆之一是，白天拎着一袋杂货回家，并意识到在白天做这件事比晚上下班后更加美好。另一个记忆片段是和我的猫在沙发上小睡，我当时拍下了这张照片：

是的，那是荷马·辛普森拖鞋。

当时我租的公寓不大，只有一个小厨房、一个小客厅和一个同样小的阁楼。这意味着我的客厅同时充当卧室、客厅和办公室。这样的房间布局不太理想，但租金在我的负担范围之内，也许与昂贵的 Aeron 椅子有关。

尽管GitLab是一家全员远程工作的公司，但它也是一家重视社交的公司，多年来经常举办聚会和活动。例如，我加入几周后，公司在阿姆斯特丹举办了一次聚会，白天举办各种活动，晚上聚餐。

那时，还能将整个公司安置在餐厅的一角。

不久之后，GitLab 出现了第一次增长，大约有 100 名新员工（如果我没记错的话）。2016 年在奥斯汀举行的公司聚会上，餐厅的一个角落已经不够了：

这段时间也有很多负面的经历。GitLab 遭受了糟糕的性能、频繁的停机（几乎每周都会出现一次）、管理不善以及许多初创公司会面临的问题。这导致“GitLab 运行慢”成为用户最常抱怨的问题，尤其是Hacker News网站上，无论原帖主题是什么（比如新功能公告），都能见到用户在抱怨（GitLab 运行缓慢）。GitLab 自然也意识到了这一痛点，他们雇用我的原因之一就是解决以上问题。

事实证明，解决这些问题挑战难度相当大，在 GitLab 没有足够的性能监控基础设施的情况下，挑战性尤为突出。顺便说一句，（我的评价）毫不夸张：当时唯一运行的服务是 New Relic 试用帐户，它只允许监控一两台服务器（那时我们应该拥有15到20台服务器）。这意味着无论输入什么数据都不能准确反映实际情况，同时测量和解决性能成为了难题。

让解决这些问题变得格外困难的是 GitLab 的要求，即我们使用的任何工具都必须可供自托管客户使用，并且最好是开源的（甚至好像是硬性要求，我不记得了）。这意味着我不仅要提高性能，而且先要构建提高性能所需的工具。

与此同时，编写高性能代码（或者至少不是非常慢的代码）不被视为公司其他部门的优先工作事项，GitLab还倾向于更多地听取Hacker News网站上的投诉而非内部投诉。这导致了我们内部流传一个笑话：如果你期望改变某些事项，最好在黑客新闻上匿名抱怨，而非通过合理渠道传达。

接下来的几个月里，我试图提高性能、构建必要的工具、尝试改变公司文化/对性能的态度，以便随着时间的推移，真正改善情况，并处理 GitLab 对所做改进不满意的难题。我清楚地记得至少有几次视频通话中我差点对 Sytse 大喊大叫，好在从未真正发生。

尽管面临这些挑战，我还是设法构建了必要的工具，并提高了各个部分的性能（其中一些很重要，另一些则不那么重要）。该工具成为了 GitLab 的官方功能，名为为“GitLab 性能监控”，尽管经过多年它已产生很大变化。我构建的另一个工具是“Sherlock”，一个用于开发环境的重量级分析器。在此期间，GitLab 开始意识到仅雇用一个人无法解决此类问题，尤其是在公司其他部门不优先考虑性能的情况下。这导致的变化之一是，我不再直接向 Sytse 汇报，而以新“性能”团队成员的身份，向一位专务经理汇报。同时，这个新团队拥有更多增员预算，我记不清具体预算金额了，但并不多，可能是两到三个人。考虑到公司总体规模以及推出尽可能多功能的生产重点，这还远远不够，但算是一个开始。

在GitLab工作的第二年，大部分时间我都是作为这个团队的一员度过的，也获得了一些喘息空间。我继续争取更多资源，并倡导将良好性能作为新代码要求之一，但结果好坏参半；同期，我和整个团队都在持续提高性能。

在此期间，GitLab 经历了第一波裁员潮，人们自愿离开，这主要是因为 GitLab 一开始就聘用了错误的人才。这意味着 GitLab 的员工人数从 30 多名增长到（我预计）130 多名，然后缩减至80余名，并在随后的几个月里增长。

至于 Rubinius：虽然我们尝试让 GitLab 在 Rubinius 上运行，但我们从未成功。结合 Rubinius 的项目维护者希望将该项目引向不同的方向，以及由此在 Ruby 社区内引发的争议等因素，我们最终决定放弃 Rubinius，我也完全停止了这方面工作。可惜的是，Rubinius 多年来累积了许多优点，但最终被维护者以不同于项目成功所需的方式阻碍。

在经历了艰难的一年半之后，情况开始好转。性能获得极大提高，GitLab 开始更加认真地对待这一问题。招聘流程得到了很大改进，如同下棋排兵布阵般，GitLab 开始将合适的人调动到合适的位置。性能团队的工作范围也发生了变化：不再关注总体性能，而是关注数据库性能，并且作为其中的一部分，创造性地将其重命名为“数据库团队”。这一变化还提升了招聘人员和基础设施工程师的预算，新入职的基础设施工程是被指派来协助我们建立新的数据库等工作。

我在这段时间构建的一个极其重要的功能是GitLab 的数据库负载均衡器。此功能允许开发人员继续像往常一样编写数据库查询语句，而负载均衡器负责不将这些查询发送到副本或主数据库。执行写操作后，负载均衡器确保使用主数据库，直到写入的更改可供所有副本使用，这通常称为“粘滞 (sticking)”。

引入负载均衡器对性能产生了重大而积极的影响，我确信如果没有这个负载均衡器，GitLab 将会遇到很多麻烦。我最自豪的是能够透明地引入这个系统，迄今为止，我还没有见过一个只需添加至项目就能直接使用的数据库负载均衡器（更不用说 Ruby on Rails）。相反，现有的解决方案更像是只提供一块拼图，需要自己将所有内容粘合起来，通常没有任何形式的粘滞支持。遗憾的是我们从未将其提取为独立库。

在这段时间，我不仅收获了令人难以置信的生产力和进步，也经历了我在 GitLab 以及整个职业生涯中最低谷和最可怕的时刻：1 月 31 日，我经历了漫长而紧张的一天，在处理持续存在的问题指导深夜，我意外解决了GitLab的性能问题，不小心删除了GitLab 的生产数据库(事故详情：99%数据被误删，5类备份全部失效，怎么破？)。这导致我们发现，由于系统长时间不工作，没有任何备份，并且发送备份错误通知的系统也未能正常运行。

最终我们进行了恢复，得益于当天工作的一部分，我在大约 6 小时前将生产数据复制到了临时环境中，不过恢复过程耗费大约 24 小时。虽然大约6个小时的数据丢失从各方面来说都很糟糕，但我不确定如果我没有进行备份会发生什么更可怕的事。可以说，那天我的心漏跳了几拍，我确信自己瞬间多长了几根白发。

这段时间反复引发挫败感的来源是 GitLab 希望对数据库进行分片，即使在引入数据库负载均衡器之后也是如此。我、其他工程师以及我的经理不仅认为这并非正确的解决方案，而且我们也有数据佐证。例如，如果写入数据量远多于读取数据量，则分片很有用，但在 GitLab 中读取数据量远远超过写入数据量，比例大约为 10:1。

此外，我们存储的数据量不足以证明引入分片的复杂性是合理的。我清楚地记得我们聘请的一位顾问说了这样的话：“无意冒犯，但我们的客户的负载和存储量要高出几个数量级，即使对他们来说，分片也是小题大做了。”尽管如此，多年来，GitLab 仍将继续推动分片技术的发展，直到管理层将其搁置。一直到我在GitLab 的工作即将结束，他们才再次提出分片技术（只是这次使用了稍有不同的名称和想法）。

2018-2019 年的某个时候，我从数据库团队过渡到新成立的“交付”团队，因为我已经厌倦了过去四年的性能和可靠性工作。此外，现在有很多人正在研究性能和可靠性，所以我觉得现在是转向新事物的正确时机。这个新团队的目标是改进 GitLab的发布流程和工具，因为当时的状态用“混乱”来形容再合适不过了。

例如，我们研究了提交到主分支及部署更改到 GitLab.com 之间的时间间隔。结果数据显示，平均需要几天时间，在最坏的情况下可能需要长达三周的时间。造成问题的主要瓶颈是 GitLab 社区版和企业版之间的分裂，两者都作为单独的 Git 存储库存在，需要定期手动合并和解决冲突。针对这个问题，我们花费了数月时间将这两个项目合并为一个。虽然我们将工作分为前端和后端工作，并让各个团队负责为工作贡献自己的一份力量，但我最终实现了大部分后端相关的更改，而另一位同事则负责了大部分前端工作。

在此期间，我与团队的其他成员一起对发布流程进行了重大改进，并且达到了可以在几个小时内部署更改的程度。虽然这远没有达到应有的速度，但从部署时间最长从三周缩减到一天，也是一个巨大进步。

与以往一样，这一时期依旧充满动荡与变化。

2018 年是我们举办以员工为重点的 GitLab 峰会的最后一年，2019 年及随后几年的形式更像是传统会议，更多针对客户而不是员工。从财务角度来看，这是可以理解的，因为组织 2000 多人的聚会非常昂贵。从社会角度来看，这是一种损失，因为峰会的企业氛围远不如旧形式那么有趣。我对Sytse 在舞台上跳舞以回应团队赢得比赛、以及他和妻子穿着长颈鹿服装上健身课等美好记忆仍历历在目。在接下来的几年里，这种有趣的事件不会再发生了。

然后是笔记本电脑管理的问题：人们会申请一台公司的 Mac 笔记本电脑，并且或多或少可以自由使用它，或者像我一样使用自己的硬件。多年来，GitLab 的管理层开始讨论使用软件来远程管理笔记本电脑。这些讨论中反复出现的一个问题是，所提出的软件是侵入性的（例如，它们可用于记录用户活动），无法保证不被滥用的，并且员工的反馈（有很多）被忽略，直到关键员工开始向管理层施压。然后，这些计划就会被搁置，直到几个月后重新开始讨论。

最突出的问题不是拟议的变革，而是管理层处理反馈的方式，以及这些改变总体上散发出一种为解决问题而解决问题的感觉。值得一提的是，参与这些讨论的大多数人（包括我自己）都理解对某种形式的笔记本电脑管理（例如防盗）的需求，但认为所提出的侵入性解决方案太过分了。

GitLab 采用 SentinelOne 作为笔记本电脑管理解决方案。虽然 GitLab 要求员工在用于访问 GitLab 资源的硬件上安装此软件，其中包括个人硬件（或者至少正在考虑要求这样做），但我（使用自己的台式计算机）却不知何故被蒙在鼓里，未被要求安装相关软件。也许是因为我是使用的不是公司配发的笔记本电脑，GitLab 忘记对我进行检查。

企业文化的改变，加之我个人生活的各种变动，导致我失去了动力、工作效率下降、压力增大工作时间不稳定。团队经理（个人认为他是我遇到过的最好的经理）也转换了岗位，现在由一位新聘的经理领导团队。我与这位经理相处得不好，由此产生的冲突导致了“绩效提升计划（PIP，performance improvement plan）”出台。该计划的目的是在需要制定“绩效改进计划”（PIP）之前让事情回到正轨的程序。PIP 旨在作为改善员工、他们的工作和雇主之间关系的最后尝试。

让我恼火的是 GitLab 处理 PEP 的方式：我承认有一些地方需要改进，但我觉得部分问题在于新经理的工作方式。管理层向我保证，PEP 旨在改善两端的状况，即它不仅关注我的 改进，还关注经理的改进。但这种情况并没有发生，PEP 只关注我需要改进的部分，同时PEP 对于必须满足哪些要求也有些含糊不清。最初的计划是 PEP 持续一个月，但到了第一个月末，我的经理决定将 PEP 延长一个月，因为他们认为这是必要的，但原因并没有明确说明。我决定顺其自然，两个月后我完成了 PEP，管理层认为结果令人满意。

乐观地看，我相信只是因为我是第一个被列入 PEP 的员工，因此管理层不得不边做边想。而悲观来说，我对于这件事的看法则消极得多，但我不打算多说。

经历这番，我意识到也许是我离开的时候了，因为我和 GitLab 正朝着不同的方向前进，而且我对当时的状况很不满意。

这个机会在 2021 年底出现：GitLab 即将上市，考虑到我在行使股票期权之前的等待时间，我最早可以在2021年12月离职。由于当时荷兰的股票期权政策，我不能提前离职：行使股票期权意味着必须就行使费和估值之间的差额缴纳全额所得税（52％），即使股票不是流通股。就我而言，税额高得难以支付，因此不得不等到 GitLab 上市。几个月后，法律变更，如今可以选择在行权时或股票流动时缴税。需要注意的是，如果推迟到股票流通时再缴税，将根据当时价值而非行使股票期权时的价值。当然这不是理想选项，而且会带来巨大的财务风险，但至少你有这样选择的余地。

因此，在获得股票后，我于 2021 年 12 月离开， 在Inko进行全职工作，用积蓄负担生活开支。

抛开历史，让我们来看看我在 GitLab 期间学到的一些东西。需要记住的一件事是，这些发现都基于我的亲身经历，因此在某些方面不太可能是错误的。

GitLab 曾经犯过，并且在我离开后一直在犯的错误，就是对可扩展性不够重视。是的，主管们会说这很重要，也确实做出了改进，但它没有受到和其他目标一样的重视。这个问题的核心在于 GitLab 的盈利方式：主要通过客户自托管的 GitLab 企业版赚钱，而不是从 GitLab.com 赚钱。事实上，GitLab.com 的成本总是高于收益。这自然导致我们将重点放在自托管市场，而我们在 GitLab.com 上遇到的许多性能问题并不适用于许多自托管市场。

更令人沮丧的是，许多开发人员实际都想提高性能 ，但却没有时间和资源来做这件事。

另一个因素是 GitLab 产品经理驱动的本质。虽然一些关键开发人员可能有能力影响产品决策（只要进行足够的死缠烂打），但主要还是由产品经理和总监决定实际操作。有时这些决定很有意义，有时似乎只是基于“我在 Hacker News网站上看到这个主意不错，所以我们必须实施”。

我认为，如果 GitLab 能在早期采用更简单的层次结构，而不是现在的传统多层结构，那么公司将会表现得更好。特别是，我认为产品经理的概念需要摒弃，应该赋予团队领导更多权力，让他们与用户有更多互动。在我看来，这才是“产品经理”应该做的事情：在技术层面帮助构建产品，同时充当团队和用户之间的联络人。

GitLab 的核心原则之一是始终从“最小可行变更”开始。这个理念是提供尽可能小的工作单元，为用户带来价值。理论上听起来不错，但实际上，人们对“最小”的定义并不一致。结果是，一个团队可能认为性能或良好可用性是可行的要求，而另一个团队则毫不关心。

在实践中，这导致 GitLab 多年来构建了许多毫无用处的功能：无人问津的无服务器平台，最终被淘汰；支持管理 Kubernetes 集群的功能在三周内无法运行，却无人察觉；我们不得不在 CI 产品之上构建 chatops 解决方案（因此带来了严重的延迟），而不是使用现有解决方案；或者需求管理功能仅支持创建和查看数据（甚至不支持更新或删除）；这些只是近年来的几个例子。

为了确定什么是可行的，就必须深入了解目标受众的需求。虽然 GitLab 确实每个季度都会进行用户调查，一些团队可以获得有关用户参与度的数据，但根据我的记忆以及与其他前同事的交流，这些数据似乎更多的是被偶然使用的，而不是每个团队工作流程的核心部分。

GitLab 提供两种类型的产品：自托管安装和软件即服务 (SaaS) 产品。我相信包括 GitLab 在内的大多数公司都无法有效提供这种设置。这不仅会造成利益冲突（如上所述），而且这两种设置的要求和更新方式也不尽相同。

例如，对于 SaaS来说，您希望能够快速部署，并且必须处理集中式基础设施上处理大量数据和工作负载。与 SaaS 产品相比，大多数自托管实例往往很小，因此，SaaS 所遇到问题的许多解决方案及其相应解决方案并不适用于自托管安装。这实际上导致平台的许多部分存在两条代码路径：一条用于 SaaS 版本，另一条用于自托管版本。即使代码在物理上是相同的（即你为自托管安装提供了某种易于使用的封装），你仍然需要考虑其中的差异。

相比之下，当您专注于 SaaS 或自托管设置时，你就可以将全部注意力放在为相关设置提供最佳体验上。当然也有例外，但那只是例外，而且是罕见的例外。

与之前的许多其他公司一样，GitLab 多年来雇佣了大量员工，如今员工数量已超过2000 人。我不知道其中多少人是开发人员，但根据快速浏览他们的团队页面，我猜测至少有几百人。众所周知，在一个项目中增加人手并不一定会提高生产力和结果（参见《人月神话》），但几乎所有拥有风险投资的西方初创公司都忽视了这一点，即使该产品不需要那么多开发人员，他们也会雇佣数百名开发人员。

我对这一观点没有任何数据支持，但我认为大多数公司所需的开发人员不超过20名，部分公司需要 20 到 50 名开发人员，只有少数公司需要 50 到 100 名开发人员。一旦你的开发人员数量超过 100 名，我认为你需要开始考虑产品范围会否失控，然后再雇佣更多的人。请注意，我这里说的是软件开发人员。例如，如果你正在构建定制硬件，你可能需要更多的人来扩大生产流程。销售和支持这两个领域通常也需要更多人手，因为这些类型的工作对人员之间的同步性要求较低。

GitLab 是使用 Ruby 和 Ruby on Rails 构建的，这是它能够取得今天成功的重要原因之一。同时，当项目规模达到一定程度，拥有众多不同经验水平的贡献者时，这种组合就会带来挑战。Rails 尤其容易引入性能不佳的代码。

例如，如果您想要显示项目列表以及显示项目成员数量的计数器，则很容易意外引入N+1 查询问题。虽然 Rails（或更具体地说是ActiveRecord）提供了解决此问题的功能，但它是一种选择加入机制，不可避免地会导致开发人员忘记这一点。我在 GitLab的头几年解决的许多性能问题都是 N+1 查询问题。

多年来，其他框架已经从中吸取了教训，并提供了更好的替代方案。通常的做法是，不能随意查询关联数据，而是必须提前传入数据。这样做的好处是，如果您忘记传入数据，您会遇到某种错误，而不是代码逐行查询数据，从而一路引入性能问题。

对于Ruby 本身，我也是褒贬不一。一方面，这是一门非常棒的语言，在不到10 年的时间里我一直喜欢使用它。另一方面，它大量使用元编程，即使引入了可选类型，也很难在大型项目中使用。我并不是吹毛求疵，几年前我在为Ruby 编写静态分析工具时亲身经历过这种情况。

尽管如此，我还是不确定除了 Ruby 和 Ruby on Rails 的组合之外，我还会推荐其他什么语言。Go、Rust 或 Node.js 等语言可能比 Ruby 更高效，但它们都没有像 Rails 上的 Ruby 那样强大的框架。Python 和 Django可能是一个选择，但我怀疑您会遇到与Ruby 和 Ruby on Rails 类似的问题，至少在某种程度上是这样。如果新的网络框架不再纠结于如何定义路由树，而是更多关注整体生产效率，或许会有所帮助。

对于如何使用 Inko来实现这一点，我有一些模糊的想法，但在开始使用 Inko 中编写 Web 框架之前，还有很多其他工作需要做。

在加入 GitLab 之前，我就意识到了这点，我在过往工作中花费了大量时间建立良好的部署和测试管道，但在 GitLab 的工作让我更加坚定了这一信念：你必须能够快速部署代码，即在最多一个小时内将变更推送到您部署的任何分支/标签/事物。在 GitLab，我们花了大约四年的时间才接近这个目标，而且我们还有很长的路要走。

除了显而易见的好处之外，例如能够更有效地响应突发事件（无需热修补代码来解决数小时的部署问题），还有一项激励性好处：能看到自己的修改实时更新是件好事，因为你能真正看到并利用自己的工作。没有什么比花费数周时间进行一组变更，却又需要两周时间才能部署完成更令人泄气的了。

为了实现这一点，就必须非常积极地减少部署时间以及作为部署的一部分测试套件的运行时间。

根据应用程序的类型和您正在测试的服务的类型，您可能需要一定的时间来运行测试。这里的要点不是“测试和部署时间绝不能超过 X 分钟”，而是（作为一个组织）优先考虑能够在业务要求允许的范围内尽可能快地部署。

这一点看似显而易见的重要，但我怀疑许多组织在这一领域的工作并不尽如人意。

您在 GitLab 赚取的薪水受到各种变量的影响，变量之一是工作地点。地区的影响也并非微不足道，如果是一家拥有实体办公室的公司，需要在特定区域招聘员工，那么根据位置调整薪酬可能是有意义的，否则您可能无法在所需区域招聘到必要的员工。

但对于一家没有实体办公室、法人实体遍布全球的全远程公司来说，没有正当理由纯粹根据居住地点，向两个具有相同经验和职责的人员支付不同薪水。举个例子：当我离开 GitLab 时，我的税前工资约为每年 12 万欧元，或每月约8500 欧元。在荷兰，这是个不错的薪酬水平，你很难找到比这更好的公司，还能够全职在家工作。但如果我住在湾区，我的收入至少是这个数字的两倍，甚至可能更高。不是因为我能够以某种方式在湾区更好地完成我的工作，或者因为任何其他合理的原因，是因为我会住在湾区，而不是荷兰。

不管如何解释，纯粹因为居住地而给一个人支付比另一个人少的工资，从所有人看来都是一种歧视行为。想想看：如果一家公司因为肤色或性别而减少一个人的工资，那么该公司就会遇到大麻烦。但不知何故，根据一个人的位置减少报酬是可以的吗？

至于如何解决这个问题，对于企业来说很简单：只需根据职位要求付费即可，而不是根据应聘者的所在地来付费。无论您每年向湾区的某人或菲律宾的某人支付 10 万美元并不重要，因为作为企业，您的成本是相同的。对于员工，我唯一的建议是尝试通过谈判获得更高的薪水，但这可能会很困难，因为按地区支付薪水的公司也往往对此很固执。我希望有一天我们的法律能够跟进这种做法。

0xide 计算机公司似乎在这方面做得很好。0xide 不根据员工所在位置提供不同工资，而是向员工支付相同的工资金额，我对此深深钦佩，并相信更多的公司应该这样做。

回顾过去，我在 GitLab 的工作经历既有积极的一面，也有消极的一面。我为我所在的各个团队所取得的成就以及与我共事的人感到无比自豪，但我也对过去一年多的工作经历感到难过，这让我原本美好的经历变得暗淡无光。我并不后悔在 GitLab 工作，如果可以，我还会重来一次，只是由于事后诸葛亮，我的工作方式会稍有不同。我仍然推荐GitLab 作为工作选择，因为尽管它有很多缺点，但我认为它比许多其他公司做得更好。