Daily Productive Sharing 1376 - Lessons From 14 Years at Google
One helpful tip per day:)
Addy Osmani 分享了他在 Google 十四年里学到的经验：
- 真正能脱颖而出的工程师，未必是最会写代码的人，而是那些搞清楚了代码之外一切的人：人、政治、协同、以及不确定性。
- 但真正创造最大价值的工程师是倒推思考的：他们痴迷于深度理解用户问题，让解决方案从这种理解中自然浮现。
- 真正理解问题的工程师，往往会发现：优雅的解决方案比任何人预想的都要简单。
- 关键技能不是“我对了”，而是走进讨论去对齐问题、为他人留出空间，并始终对自己的确定性保持怀疑。
- 强烈的观点，弱绑定地持有——不是因为你没有信念，而是因为在不确定性下做出的决策，不该和身份焊死在一起。
- 先把事情做出来，然后把它做对，最后把它做得更好。
- 发布一个让你略感尴尬的 MVP。一周的真实反馈，胜过一个月的理论争论。
- 软件工程，是在加入时间和其他工程师之后发生的事情；在这种环境里，清晰不是风格偏好，而是降低运营风险。
- 你的代码，是写给凌晨 2 点故障时维护它的陌生人的战略备忘录；优化他们的理解，而不是你的优雅。
- “最适合的工具”，往往是“在多种场景下最不差的工具”——因为维护一座工具动物园才是真正的隐性税负。
- 在大型组织里，很多决策发生在你未被邀请的会议中，基于你没写的摘要，由只有五分钟、却有十二个优先级的人做出。
- 你不写的每一行代码，都是你永远不必调试、维护或解释的一行。
- 问题不在于工程师不会写代码或不会用 AI 写代码；而在于我们太擅长写了，以至于忘了先问一句：这件事真的该存在吗？
- 这带来一个职业层面的洞见：你不能把兼容性工作当作“维护”，把新功能当作“真正的工作”。兼容性本身就是产品。
- 把弃用（deprecation）设计成迁移：给时间、给工具、给同理心。多数“API 设计”，其实是“API 退役”。
- 在大公司里，团队是并发的基本单元；但随着团队数量增加，协调成本会几何级数增长。
- 大多数“慢”，其实是对齐失败——人在做错误的事情，或用彼此不兼容的方式做正确的事情。
- 资深工程师花更多时间澄清方向、接口和优先级，而不是“更快地写代码”，因为真正的瓶颈就在这里。
- 面对不确定性时，把问题拆解成小块，并识别你当下能采取的具体行动。
- 即便技术栈越叠越高，资深工程师仍会持续学习“更底层”的东西；不是出于怀旧，而是尊重这样一个时刻：抽象失效、凌晨 3 点你独自面对系统。用好你的技术栈。
- 如果你觉得自己理解了某件事，试着把它讲得很简单；你卡住的地方，正是理解浅薄之处。
- 教学，就是在调试你自己的心智模型。
- 陷阱在于把它当作“热心帮助”，而不是当作有边界、可见、可衡量的影响来做。
- “无价且不可见”，对你的职业生涯是一个危险组合。
- 真正的对齐需要更长时间：你得真正理解他人的视角、吸收反馈，甚至在公开场合改变自己的想法。
- 资深的做法是：对每一个指标请求，都给一对指标——一个衡量速度，一个衡量质量或风险；然后坚持解读趋势，而不是崇拜阈值。目标是洞察，而非监控。
- 当领导者承认不确定性时，会向全场传递一个信号：这里是安全的，你们也可以承认不确定。
- 那些在公司内外持续投资关系的人，几十年后仍在收获回报。
- 你的工作不会永远，但你的人脉会。以好奇与慷慨去对待它，而不是交易式的忙乱。
- 当该离开的时候，往往是关系为你打开下一扇门。
- 删除不必要的工作，几乎总是比把必要工作做得更快更有影响力；最快的代码，是从不运行的代码。
- 在你开始优化之前，先质疑：这项工作是否本该存在？
- 如果人们花在“记录工作”上的时间超过“做工作”，那一定是哪里出了大问题。
- 答案不是“不努力工作”，而是清楚你在交换什么，并有意识地做出选择。
- 但这里有个希望：当学习能创造新选择而不只是新琐碎知识时，它会产生复利。写作——不是为了互动，而是为了清晰；构建可复用的原语；把伤疤沉淀成行动手册。
- 二十一条经验听起来很多，但其实都指向几个核心：保持好奇，保持谦逊，并记住——工作始终关乎人：你为之构建的用户，以及与你并肩构建的同事。
如果你喜欢的话，不妨直接订阅这份电子报 ⬇️
