本文永久链接 – https://tonybai.com/2025/12/02/advices-from-uber-distinguished-engineer

大家好，我是Tony Bai。

“如果你不写代码，你就不是一个软件工程师。”

这句话出自前 Uber 杰出工程师 (Distinguished Engineer) Joakim Recht 之口。在他看来，无论你的级别有多高，哪怕到了 Principal 或 Distinguished 级别，只要头衔里还有“工程师”这三个字，你就必须保持手感，持续编码。

近日，Joakim 接受了一次深度访谈，回顾了他在 Uber 从一名普通高级工程师一路成长为杰出工程师的完整历程。他不但分享了那个让他获得关键晋升的“史诗级”项目，还坦诚地谈论了办公室政治、不公平的晋升制度、以及他对“影响力”的独特理解。

这既是一个成功者的故事，也是一份关于如何在大型科技公司中保持清醒、持续成长并最终实现自我价值的深度指南。

晋升的秘密 —— 影响力不是“求”来的，是“做”出来的

Joakim 的晋升之路，始于一个朴素的愿望：懒惰。

起初，他只是负责管理一个名为 Schemaless 的数据存储系统。每次由于硬件故障需要替换主节点时，都需要手动操作 Puppet，繁琐且易错。

“我真的不喜欢重复做同样的事情。” Joakim 说。于是，他和团队开始尝试将数据库容器化，通过 Docker 来自动化管理这些操作。

这个最初只为了解决“自己团队痛点”的小项目，最终演变成了一个庞大的内部平台（Odin），接管了 Uber 几乎所有的有状态负载。在他离开时，这个平台管理着 12 万台物理服务器和 50 万个数据库实例，而核心维护团队只有 20 人。

给我们的启示：

Joakim 并没有在一开始就画一个“我要掌管全公司数据库”的大饼。他的影响力扩张遵循了一个自然的路径：

1. 解决自己的痛点：自动化自己团队的重复劳动。
2. 解决邻居的痛点：把工具推广给旁边的团队。
3. 解决公司的痛点：逐步扩展到更广泛的组织，最终成为全公司的基础设施。

真正的晋升，是对你影响力范围 的自然确认，而不是因为你填写了一份完美的晋升文档。

关于“写代码”的执念 —— 拒绝成为“白板架构师”

在许多大厂，晋升往往意味着“远离代码”，转向文档、会议和 PPT。但 Joakim 对此坚决说 不。

“如果你停止写代码，你就会失去对系统的感知。你或许能画出高层的架构图，但那些设计往往会脱离现实。当你把设计扔给别人实现时，他们会想：‘这是哪个不懂装懂的家伙画的？’”

他认为，保持 Hands-on (亲力亲为) 有两个巨大的好处：

1. 保持信任：如果团队成员知道你不仅懂业务，还能写出高质量的代码，甚至愿意干“脏活累活”，他们会更愿意听取你的建议。
2. 保持敏锐：只有在代码一线，你才能第一时间感知到系统的腐坏和痛点，从而做出正确的架构决策。

对于那些只想做“高大上”设计，把“简单工作”丢给下属的高级工程师，Joakim 建议反其道而行之：把困难的、有趣的工作委派给团队成员，让他们成长；你自己去承担那些枯燥的、修修补补的“脏活”。 这不仅能赢得尊重，还能让你从微小处发现系统性的改进空间。

面对“不公平”的晋升 —— 心态决定一切

Joakim 并不避讳谈论大公司的阴暗面。他回忆起早期的 Uber 晋升委员会，那就是一场“没有任何数据支持的、纯粹靠经理口才”的辩论赛。

“这完全取决于你的经理有多擅长推销你。如果你有一个糟糕的经理，你就完蛋了。”

即使在制度完善后，绝对的公平依然不存在。项目被砍、依赖方掉链子、甚至仅仅是因为团队整体表现不佳，都可能成为你晋升路上的绊脚石。

他的建议：

• 不要成为“晋升驱动开发” (Promotion Driven Development) 的奴隶。专注于提供价值。
• “只要你持续地解决问题、消除浪费、帮助他人，晋升通常会随之而来。如果你整天焦虑于‘如何找到一个能让我晋升的项目’，你反而可能动作变形，最终一无所获。”

影响力的最高境界 —— “盗梦空间”

当被问及如何有效地影响他人时，Joakim 分享了一个类似《盗梦空间》的技巧：最好的结果，是让对方觉得那是他们自己的主意。

不要试图用权威压人，也不要指望每个人都能立刻被你的逻辑说服。有时候，你只需要在对话中种下一颗种子。

“也许几个月后，你会听到他们在讨论你的想法，甚至充满激情地捍卫它，仿佛那是他们自己想出来的。那一刻，你就赢了。不要去争夺功劳，要享受这种‘想法生根发芽’的成就感。”

小结：给年轻自己的建议

在访谈的最后，Joakim 给年轻的自己（以及所有年轻工程师）提了一条建议：保持好奇，不要被吓倒。

“那些看起来很厉害的人，其实也是普通人。他们可能只是比你多了一些经验，或者更擅长包装自己。不要因为觉得某件事‘太难’或‘太高端’就不敢去尝试。计算机科学不是火箭科学（虽然有些也是），它只是计算机而已。保持好奇心，去尝试，去犯错，这是成长的唯一捷径。”

资料链接：https://www.youtube.com/watch?v=feNh_ubBAMI

你的看法是什么？

Joakim 的观点非常犀利，尤其是关于“级别越高越要写代码”的论断。结合你所在的团队或公司，你认同这个观点吗？在你身边，那些高T/P的架构师们，还在坚持写代码吗？如果不写，他们是如何保持对系统的敏锐度的？

欢迎在评论区分享你的观察和思考！ 让我们一起探讨工程师的终极成长之路。

如果这篇文章给你带来了新的职业启发，别忘了点个【赞】和【在看】，并分享给身边正在为晋升或成长感到困惑的朋友！

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/12/01/proposal-sync-v2

大家好，我是Tony Bai。

当 Go 核心团队前成员、著名 Gopher、net/http包的设计者 Brad Fitzpatrick 在 GitHub 上留下上图中的这句评论并甩出一个自己移植的库时，我们知道，sync/v2 的到来不仅仅是一个提案，更是一种迫切的刚需。

随着 math/rand/v2 在 Go 1.22, json/v2 在 Go 1.25 中的成功落地，Go 标准库的 v2 化进程似乎已经按下了加速键。今年1月份，Go 核心团队成员 Ian Lance Taylor 就提交了sync/v2 的提案 (#71076)。

这可不仅仅是一次简单的版本号升级，它标志着 Go 语言最核心的并发原语包，也终于要拥抱泛型，告别 interface{} 时代了。

在本文中，我们将深入剖析这份提案的核心内容，探讨它将如何重塑 Go 的并发编程体验，以及社区为此展开的激烈辩论。

核心痛点：any 的原罪

目前的 sync 包，特别是 sync.Map 和 sync.Pool，设计于 Go 支持泛型之前。它们被迫使用 any (即 interface{}) 来处理各种类型的数据。这带来了两个无法忽视的问题：

1. 类型安全缺失：编译器无法阻止你往一个本该只存字符串的 sync.Map 里塞进一个整数，或者从 sync.Pool 里取出一个你以为是 []byte 实际上是 *bytes.Buffer 的东西。所有的错误只能在运行时通过 panic 暴露。
2. 性能损耗：将非指针类型（如 int、string）存入 any 类型的容器，必须进行装箱（boxing），这不仅增加了 CPU 开销，更重要的是会产生额外的内存分配，加重 GC 负担。对于追求极致性能的并发场景，这是不可接受的。

sync/v2 的提案，就是要通过泛型彻底解决这些问题。

sync/v2 的新面貌：类型安全与 API 进化

根据提案，sync/v2 将不仅是 sync 的泛型翻版，它还趁机对 API 进行了现代化的打磨。

Map[K, V]：终于等到了你

新的 sync.Map 将拥有两个类型参数 K (comparable) 和 V (any)。

// sync/v2
type Map[K comparable, V any] struct { ... }

// 方法签名变得清晰且类型安全
func (m *Map[K, V]) Load(key K) (value V, ok bool)
func (m *Map[K, V]) Store(key K, value V)

此外，提案还计划顺应时代潮流，移除了老旧的 Range 方法，取而代之的是返回迭代器的 All 方法：

func (m *Map[K, V]) All() iter.Seq2[K, V]

Pool[T]：更安全的资源复用

sync.Pool 的改造稍微复杂一些。目前的 Pool 有一个导出的 New 字段，这很容易被误用。v2 版的提案曾经历过一次修改，最终方案倾向于移除导出的 New 字段，转而通过构造函数来设定：

type Pool[T any] struct { ... }

// 通过构造函数传入创建新对象的逻辑
func NewPool[T any](newf func() T) *Pool[T]

func (p *Pool[T]) Get() T
func (p *Pool[T]) Put(x T)

社区的激辩：v2 真的必要吗？

提案虽然诱人，但也引发了社区关于 Go 语言演进哲学的激烈讨论。

反方：分裂生态的担忧

有声音质疑：sync 包的大部分类型（如 Mutex, WaitGroup, Once）并不需要泛型。如果为了 Map 和 Pool 而引入整个 sync/v2，会不会导致生态分裂？以后我们是不是要在同一个项目里同时维护 v1 和 v2 的锁？

对此，Ian Lance Taylor 及其支持者给出的方案是：sync/v2 将包含 sync 包的所有类型。对于不需要泛型的类型（如 Mutex），通过类型别名 (Type Alias) 将其指向 v1 版本，或者保持 API 完全一致。这样，用户可以平滑迁移，最终完全切换到 v2，而无需混用。

正方：性能与体验的刚需

支持者们（包括 Brad Fitzpatrick）则指出，泛型带来的性能提升和开发体验改善是巨大的。特别是对于 Pool[[]byte] 这样的高频场景，避免每次 Put/Get 时的切片头分配，是实打实的性能红利。

小结：不仅是代码的升级，更是理念的升级

sync/v2 的提案目前仍在活跃讨论中，尚未尘埃落定。但它释放了一个明确的信号：Go 团队正在审慎而坚定地推动标准库的现代化。

对于我们 Gopher 而言，这意味着：

1. 拥抱泛型：这不再是尝鲜，而很可能是未来的标准范式。
2. 关注性能：标准库的升级将带来免费的性能提升，特别是对于重度依赖 sync.Map 和 sync.Pool 的项目。
3. 准备迁移：虽然 Go 承诺兼容性，但 v2 包的引入意味着我们需要开始思考如何优雅地过渡。

Brad Fitzpatrick 的“等不及”或许代表了许多资深开发者的心声。让我们拭目以待，看 sync/v2 将如何重塑 Go 的并发编程体验。

你的选择是？

面对 sync/v2 带来的泛型红利和潜在的迁移成本，你更倾向于第一时间拥抱它，还是持观望态度？在你的项目中，sync.Map 或 sync.Pool 的性能瓶颈是否真的困扰过你？

欢迎在评论区留下你的看法，让我们一起探讨 Go 标准库的未来！