在谷歌十四年的21条经验
糟糕的页面可以修改，空白页面却无法编辑
约十四年前加入谷歌时，我以为这份工作就是写出优秀的代码。我部分是对的。但随着时间推移，我逐渐意识到：真正脱颖而出的工程师未必是编程高手——他们是那些懂得驾驭代码之外一切的人：人际关系、政治博弈、目标对齐、模糊地带。
这些经验是我希望自己能更早领悟的。有些本可让我少受数月挫折，有些则耗费数年才真正参透。它们与具体技术无关——技术更迭太快，无关紧要。它们关乎那些反复出现的模式，项目接项目，团队接团队。
我分享这些，是因为曾有工程师这样帮助过我，让我获益匪浅。请看作是我传递这份恩惠的尝试。
1. 最优秀的工程师痴迷于解决用户痛点。
沉迷于某项技术并四处寻找应用场景的诱惑难以抗拒。我曾如此，人人皆然。但创造最大价值的工程师们采取逆向思维：他们痴迷于深度理解用户痛点，让解决方案自然从洞察中浮现。
用户至上意味着沉浸在支持工单中，与用户对话，观察用户挣扎，不断追问“为什么”直至触及核心。真正洞悉问题本质的工程师常发现，优雅的解决方案往往比所有人预期的都更简单。
而从解决方案出发的工程师，往往在构建复杂性中寻找合理化依据。
2. 坚持己见易如反掌，携手求真方显功力。
你可能赢下所有技术争论，却输掉整个项目。我见过太多才华横溢的工程师因始终是会议室里最聪明的人，而默默积攒着怨气。代价终将显现为“神秘的执行问题”和“莫名的抵触情绪”。
真正的本领不在于坚持己见，而在于参与讨论以统一问题认知，为他人留出空间，并对自身确信保持怀疑。
立场坚定但态度灵活——这并非缺乏信念，而是因为在不确定性中做出的决策不应与个人身份紧密绑定。
3. 行动偏好。先发布。糟糕的页面可以修改，空白页面却无法编辑。
追求完美令人瘫痪。我见过工程师耗费数周讨论从未实现的理想架构。完美方案鲜少源于纯粹思考——它诞生于与现实的碰撞。人工智能在此大有可为。
先行动，再完善，最后优化。把粗糙的原型展示给用户。写出凌乱的设计文档初稿。发布让你略感尴尬的最小可行产品。一周真实反馈的收获，远胜一个月理论争论。
动能催生清晰，分析瘫痪一无所获。
4. 清晰即资历，机巧是负担。
工程师几乎都本能地追求精妙的代码，仿佛这是能力的证明。
但软件工程的本质在于时间与协作。在这个环境中，清晰度绝非风格偏好——而是降低运营风险的手段。
你的代码是写给陌生人的战略备忘录，他们将在凌晨两点系统故障时接手维护。请优化他们的理解力，而非追求你的优雅。我最敬重的资深工程师们，始终懂得用清晰度交换精妙性。
5. 新颖性是笔贷款，你将用系统故障、招聘成本和认知负担偿还。
将技术选择视为拥有微薄“创新额度”的组织。每次采用实质性非标准方案，就消耗一份额度。你负担不起多次透支。
关键不在于“永不创新”。而是“仅在被赋予创新特权时创新”。其余场景应默认选择平庸方案——因为平庸方案拥有已知的失败模式。
所谓“最佳工具”往往是“跨场景最不糟糕的工具”——因为管理动物园般的技术栈才是真正的成本。
6. 代码不会为你发声，人会。
职业生涯初期，我曾以为杰出作品自会说话。这是错误的。代码静默地躺在代码库里。你的经理会在会议中提及你，或选择沉默；同事会推荐你参与项目，或推荐他人。
在大型组织中，决策往往发生在未邀你出席的会议里，依据你未撰写的摘要，由那些手头有十二项要务却只愿花五分钟的人拍板。当你不在场时，若无人能阐明你的价值，你的存在便成了可有可无的选项。
这并非单纯的自我推销。而是让价值链清晰可辨——包括你自己。
7. 最好的代码是你永远不必编写的代码。
我们颂扬工程文化中的创造精神。删除代码不会获得晋升，尽管删除往往比添加更能优化系统。每行你未编写的代码，都意味着少一行需要调试、维护或解释的代码。
在构建之前，请彻底思考这个问题：“如果我们什么都不做，会发生什么？”有时答案是“不会有坏事发生”，这本身就是解决方案。
问题不在于工程师不会编写代码或使用AI代劳，而在于我们编写代码的本领太过精湛，以至于忘记追问是否该编写。
8. 规模化后，连你的漏洞都有用户。
当用户量足够庞大时，所有可观察的行为都会成为依赖项——无论你曾作何承诺。总有人在抓取你的API，自动化你的特殊逻辑，缓存你的漏洞。
这带来职业级洞见：兼容性工作绝非“维护”，新功能也非“正经工作”。兼容性本身就是产品。
将功能淘汰设计成迁移方案，赋予时间、工具和同理心。多数“API设计”实则是“API退役”。
9. 大多数“低效”团队本质是目标错位的团队。
项目拖延时，人们总归咎于执行力：员工不够努力、技术选型错误、工程师不足。但这些通常都不是真正问题。
在大公司里，团队是并行处理的基本单元，但随着团队数量增长，协调成本呈几何级上升。多数效率低下实为协同失效——团队要么在构建错误的产品，要么以相互冲突的方式开发正确的产品。
资深工程师投入更多时间在厘清方向、接口和优先级上，而非“加快编码速度”，因为真正的瓶颈恰恰存在于此。
10. 专注可控之事，忽略不可控之物。
在大公司里，无数变量超出你的掌控——组织架构调整、管理决策、市场波动、产品转型。纠结于此只会徒增焦虑却无济于事。
保持理智高效的工程师专注于自身影响力范围。你无法控制重组是否发生，但能掌控工作质量、应对方式和学习成果。面对不确定性时，将问题分解为可控的具体行动。
这并非消极妥协，而是战略聚焦。耗费在无法改变之事上的精力，终将侵蚀可控之事的能量。
11. 抽象化并未消除复杂性，只是将其推迟到你值班的那天。
每次抽象化都是对“无需理解底层原理”的赌注。有时赌局获胜，但漏洞终会显现。当那一刻来临，你必须清楚自己立足何处。
资深工程师即便面对日益高耸的技术栈，仍持续钻研“底层”知识。这并非怀旧，而是对抽象失效时刻的敬畏——当凌晨三点你独自面对崩溃系统时。善用技术栈，
但务必保留其底层故障模式的工作模型。
12. 写作迫使清晰。学习某事最快的方式就是尝试教导它。
写作迫使清晰。当我向他人阐释概念——无论是文档、演讲、代码审查评论，甚至只是与AI对话——都会发现自身理解的漏洞。让他人看懂的过程，恰恰也让我自己看清。
这并非意味着你能通过教学成为外科医生，但在软件工程领域，这个前提依然基本成立。
这不仅关乎知识分享的慷慨，更是自私的学习技巧。若自认理解某事，请尝试简明阐述。卡壳之处正是认知浅薄的症结。
教学即是调试自身思维模型。
13. 支撑其他工作的幕后工作无价却隐形。
粘合工作——文档编写、新员工入职、跨团队协调、流程优化——至关重要。但若无意识地埋头苦干，它会阻滞你的技术成长并耗尽精力。陷阱在于将其视为“热心助人”，而非有意识地将其转化为可衡量的、有边界的、可见的影响。
设定时间框。轮换执行。将其转化为可复用的成果：文档、模板、自动化方案。确保成果以可衡量的价值呈现，而非个人特质的彰显。
无价与隐形是职业生涯的危险组合。
14. 若你总在辩论中获胜，很可能正在积累沉默的抵抗。
我学会了对自身确信保持警惕。当“胜利”来得太轻松时，往往暗藏玄机。人们停止与你争论，并非因你说服了他们，而是他们放弃了尝试——这种分歧将在执行中而非会议室里显现。
真正的共识需要更长时间。你必须真正理解其他视角，采纳反馈意见，有时甚至需要公开改变立场。
短暂的正确感，远不如与乐于合作的伙伴共同创造长期成果的价值。
15. 当指标沦为目标，便丧失了衡量功能。
任何向管理层展示的指标终将被钻空子。并非出于恶意，而是人类天生会优化被衡量的内容。
若追踪代码行数，代码量必将膨胀；若追踪开发速度，估算值必将虚高。
高阶应对法：每项指标要求都配对回应。一项衡量速度，一项衡量质量或风险。坚持解读趋势而非崇拜阈值。目标是洞察而非监控。
16. 承认未知比佯装知晓更能创造安全感。
资深工程师说“我不知道”并非示弱——而是创造许可。当领导者坦承不确定性，便向团队传递了安全信号，鼓励他人效仿。否则将滋生伪装理解的文化，问题在爆发前始终被掩盖。
我见过团队中资历最深者从不承认困惑，也目睹过由此造成的损害：问题无人发问，假设无人质疑，初级工程师因默认他人皆懂而保持沉默。
以身作则展现求知欲，你将收获真正持续学习的团队。
17. 人脉网络比任何工作都更持久。
职业生涯初期，我专注工作而忽视人脉建设。如今回想，这是个错误。那些注重维系关系(无论公司内外)的同事，数十年来持续收获回报。
他们率先获知机遇，能更快搭建桥梁，获得职位推荐，并与多年建立信任的人共同创立企业。
工作终有尽时，人脉却永存。以好奇与慷慨之心经营人脉，而非功利交易。
当需要转职时，往往是人脉为你打开大门。
18. 多数效能提升源于消除冗余，而非增添巧思。
当系统运行迟缓时，人们本能地选择堆砌：缓存层、并行处理、智能算法。有时这确实有效。但我更常看到这样的成效：当我们问出“哪些计算本可省去？”时。
删除无用工作几乎总比加速必要工作更具影响力。最快的代码，是永远不会运行的代码。
优化前，先质疑这项工作是否该存在。
19. 流程存在的意义是降低不确定性，而非制造文书痕迹。
最佳流程能简化协调并降低失败成本。最糟流程则是官僚主义的戏剧——其存在并非为提供帮助，而是在出错时推卸责任。
若无法说明流程如何降低风险或提升清晰度，那它很可能只是冗余负担。
当人们耗费更多时间记录工作而非实际工作时，系统已然严重失灵。
20. 终有一日，时间价值将超越金钱。请据此行动。
职业生涯初期，用时间换取金钱无可厚非。但转折点终将到来——你会惊觉时间才是不可再生资源。
我目睹过资深工程师为晋升而透支精力，只为争取微薄的薪酬提升。其中有人如愿以偿，但多数事后都在追问：值得吗？
答案并非“别努力工作”，而是“认清交易本质，审慎权衡取舍”。
21. 没有捷径，唯有复利效应。
专业能力源于刻意练习——持续突破现有能力边界，反思，再重复。数年如一日。不存在速成之道。
但希望在于：当学习创造新可能而非新知识时，它便产生复利效应。写作——不是为了博眼球，而是为了厘清思路。构建可复用的基础模块。将伤疤转化为实战手册。
将职业生涯视为复利而非彩票的工程师，终将遥遥领先。
终章感悟
二十一条经验看似繁多，实则归结为三个核心理念：保持好奇心，保持谦逊，谨记工作本质关乎人——你服务的用户，以及并肩作战的伙伴。
工程师的职业生涯足够漫长，容得下无数次失误仍能脱颖而出。我最敬佩的工程师并非事事完美之人，而是那些从失败中汲取教训、分享洞见并坚持前行的人。
若你正启程，请知晓岁月会让旅程愈发丰盈；若你已深耕其中，愿这些感悟能与你产生共鸣。
本文文字及图片出自 21 Lessons From 14 Years at Google，由 WebHek 分享。
> 当规模足够大时，连你的漏洞都有用户。
大学毕业后第一份工作，公司为新人举办了大型培训研讨会。有天我们听到了这样一个故事：他们如何将系统加载时间从5分钟缩短到30秒——这还是90年代中期的事。客户的负面反馈立竿见影。加载速度的提升竟摧毁了公司文化。员工们不再需要到办公室开机后花十分钟闲聊喝咖啡——软件在他们起身前就已准备就绪！
这个故事的寓意，以及那句名言，并非告诫你不要改进产品。而是提醒你：你所构建的软件并不存在于产品需求文档或测试套件中。它终将融入现实世界，成为人们实际交互的系统。用户会形成使用习惯，开发出变通方案，更会在真实场景中发现漏洞。
这意味着软件工程师必须深刻理解产品的核心价值与实际应用场景。你的职责并非完成产品经理列出的需求清单，而是打造真正解决用户痛点的软件。
> 加载速度的提升摧毁了他们的公司文化。员工们不再集体到岗、开机后花十分钟闲聊喝咖啡
初入职场时，我曾负责仓库自动化改造项目。这项工作被分配给我这个新人，只因它需要大量时间在仓库现场作业，而非舒适的办公桌前。
我原以为能因提升工作效率而受到欢迎和赞赏，但现实远非如此简单。我越是优化技术环节，他们就越需要投入更多时间完成手工操作环节来保持进度。因此，我缩短的周期时间越多，他们闲聊的时间就越少。
要知道，原有流程极其缓慢且无法并行处理，他们本就有大量等待时间。这份工作本身非常简单——我曾亲自操作数周进行测试优化，至今仍是经历过最轻松的体力劳动。然而我却成了破坏他们安逸状态的反派角色。
试想你热爱编写代码，却有人自动化了这部分工作，迫使你耗费更多时间审核PR和撰写规范…
这个比喻太妙了，我从未这样思考过。虽然自动化系统如此“情绪化”显然不够完美，但这确实让我更理解那些因技术变革而工作性质被重塑的劳动者。
从他们的角度看，效率提升了，产出增加了，但工时和薪资却保持不变，同事数量甚至可能减少。
根本不用想象，你描述的正是我如今拥有LLM后的真实工作状态。
我认为这正是关键所在
现在回看确实显而易见。这就是我刚睡醒就评论的下场！
没关系，毕竟是周一早晨嘛
效率不就是就业的敌人吗？
工作量会膨胀以填满可用劳动力。至少在其他条件不变时如此。现实虽非如此，但这个模型错得恰到好处。
效率值得赞颂之处甚多(我也不认为你那句简短评论是在反对效率)。但必须指出，效率、就业创造与就业不足之间存在显著重叠。
当今科学家、程序员和医生的数量远超农民与马夫。
与此同时，那些因自动化和外包失去制造业岗位的人，并未获得同等薪酬和成长空间的新工作。
人类大脑难以快速转行，因此每次技术革命既是掌握新技能者的福音，也是将时间投入过时技能者的挑战。
护理行业大幅扩张，但他们不愿从事。
不能指望工厂工人神奇地变成护士。人当然能学习新技能，但人类的技能组合并非完全可替代。
我曾负责自动化改造某项高度依赖人工的繁琐流程，该流程耗时巨大且设有专职员工。项目完成后，该岗位被证明不再必要，员工随即遭解雇。整个过程令我倍感不安。
挪威对此有专门法律规定，但其他地方即使没有法律也会这么做。只需让员工转岗从事其他工作即可。他或许能接替临时工的职位——那些临时工原本期待快速转正(而非试用期内每次仅工作几周)。这样既对员工有利(保住工作)，也对公司有益——你能获得一位守时且工作态度端正的熟练员工。寻找这样的人才并非零成本。
据我观察，美国很多雇主在招聘时并不具备这种智慧。
或者更准确地说，解雇成本的外部性并未直接转嫁给决策者，因此他们可以宣称通过裁员“提升了效率”，而那些需要可靠劳动力的人却无法享受因人员流动本应带来的改善。
赞同。“劳动力总量固定”的谬论确实存在——即认为劳动力永远供过于求，招聘、培训/上手、安排工作都轻而易举。
实际上雇佣与解雇成本高昂且风险极大。办公室职员比约恩或许能力平庸智商平庸，但他证明自己能准时到岗、保持清醒，且深受同事喜爱。因此投入5000美元重新培训他，可能远比花7000美元雇佣陌生人填补空缺明智得多…
没错，达标门槛意外地高。能准时可靠出勤、远离毒瘾酒瘾、没有病患亲属需要预支薪资的人类员工——好帮手难寻啊！
若你只收到这类候选人，说明你的职位缺乏吸引力。
结果天平又向另一端倾斜，现在我面对的是唯利是图的雇佣兵，他们会抓住第一个机会跳槽
并非每个岗位都需要顶尖人才。
应付账款部的贝蒂只需按时到岗，别犯太多错就行。我不需要超级明星，即便把她调去财务部其他岗位也无妨；省下的钱正好聘请一两个可靠的注册会计师。
其他观点我理解，但一个能力出众却有生病家属的人，竟连“胜任”的门槛都过不了？若社会竟至如此，实在令人痛心。
关键在于那句“…只需预支薪水”，暗示对方会先入职，以(可能虚构的)病亲名义索要现金预支，随即辞职。
有些人除非身临其境，否则很难理解这种处境。可惜啊。
完全赞同你的观点。
既然对(几乎)所有相关方都更有利，法律为何存在？若没有法律约束，人们为何不选择更优方案？
许多法律解决的是高初始成本阻碍普遍有益行为的问题。例如强制全民购买保险的法律。不难发现，在没有此类法律的地方，几乎无人购买保险，导致所有人境况恶化。
这同样属于同类法律的范例。
保险是个有趣的例子，我本以为会举出像酒驾这样直接危害他人的案例。
当投保人数减少时，我们如何会集体陷入更糟境地？
挪威整体拥有极其严格的亲劳工法律体系，这只是其中一环。有位挪威人这样解释：上世纪60年代末挪威石油业兴起时，工人意识到通过组织工会联合罢工能给企业造成巨大损失。他们以此为筹码，既改写了合同条款(纳入带薪病假等福利)，又改善了工作条件(挪威钻井平台不仅安全标准更高，还实行平台与陆地人员配比制度)。
后来其他行业也效仿此法。部分合同条款逐渐转化为法律。但仍有部分法规仅适用于工会化比例达到一定门槛(50%？)的企业。
大致情况大致如此，但具体细节请核实。
他们只能另谋生路。听起来很奇怪，但这就是我们提高生活水平的方式——减少生产中的人力投入(换言之，提高人均产量)。
自动化是一场以少数工人利益为代价换取社会整体收益的游戏。当然，企业主也从中获益，但长期来看这些额外利润终将被竞争消弭。
这是一种高度理想化的观点，希望我们都能认同它与当今社会现状并不完全吻合。若少数股东独享全部利润，自动化带来的绝大多数收益将流向他们，甚至可能导致普通民众的生活随着自动化进程加剧而恶化——因为普通人对企业所有者的影响力将日益减弱。
美国经通胀调整后的收入普遍增长。可负担性问题主要源于住房价格——因为建房本身就是违法行为。
收入在增长，但支出也在同步攀升，尤其随着《平价医疗法案》覆盖人群即将面临的医疗改革。
过去30年工资增长与企业利润增长的对比也表明，工资涨幅远未跟上生产力提升的步伐。
因此当前收入水平仅勉强维持，本应呈现爆发式增长。
通胀调整后的收入明明在增长，为何仍存在可负担性危机？
住房成本未纳入通胀计算范畴。住房通胀危机确实存在。
家庭收入不仅包含工资。当工资停滞或缩水时，家庭收入仍可能增长——因为其他构成部分在增加(如工作福利、投资收益、政府补助)。https://fredblog.stlouisfed.org/2016/09/sources-of-household…
房价涨幅甚至可能超过收入增长。
住房仅是衡量通胀的篮子中的一环。住房价格涨幅超过加权篮子平均水平，而其他商品和服务涨幅放缓甚至下跌。
住宿成本是任何合理通胀指标的首要组成部分。若不纳入住房因素，数据便存在造假嫌疑。
许多人未察觉住房通胀——若你在2020年购房，此后房价上涨80%也未影响你的住房成本，尤其在美国，即使利率飙升，抵押贷款利率仍按贷款期限固定不变。
住房、教育、医疗、托儿、食品。
不过三星电视的购买力倒是暴涨了，这算个安慰吧。
通胀还会侵蚀你的储蓄和投资。
然而越来越多的人连基本生活都难以负担，只能怀念50年代的奢侈——那时单身工薪阶层就能支付住房、汽车、家庭开销，甚至有闲钱享受休闲。经济盈余都去哪儿了？没错…流向了资产阶级，那些不断攫取社会财富的资本拥有者。
因为发展中国家生产了大量商品，唯独缺住房。
他们也不生产理发服务。
平均而言，多数大型股(微软、谷歌、苹果等)通过401K计划、共同基金、ETF及直接持股，由数百万散户投资者共同持有。
美国40岁人群的净资产中位数不足15万美元。大多数美国人从股价上涨中获益甚微，至少没有直接收益。
美国股市半数股权由1%的顶层人群掌控。
https://fred.stlouisfed.org/series/WFRBST01122
实际上我认为这张图表显示的是美国人持有的股票和共同基金中，1%顶层人群持有的份额对吧？这还不包括其他巨额持股方，比如挪威/新加坡的主权财富基金，或是安大略教师基金这类超大型养老基金……
相较于欧盟国家或澳大利亚(以高缴费率著称)，美国养老金体系的薄弱性相当独特。
科技公司创始人(属于1%阶层)持有约2%的股市份额。
约18%由外国实体持有。
> 若少数股东独享全部利润
关键不在利润增大，而在成本(及价格)降低。
成本降低只有在充分竞争存在时才会转化为价格下降。许多市场并不符合这一条件。
这正是中国的显著差异。当所有领域都存在竞争时——>价格就会走低。不过投资者利润确实不多……
你指的是哪些市场？
我也全力支持降低准入门槛。我们需要更多竞争。
无论是初创企业、外国公司(如中国企业)，还是跨界扩张的企业(例如沃尔玛允许开设银行账户)。
大多数情况下并非如此。即使存在垄断，需求曲线依然存在。
你会选择卖一件1000美元的商品，还是卖1000件10美元的商品？答案取决于成本吗？
大型企业的投资回报率通常在10%左右。
任何人都可以成为上市公司股东，操作相当简单。
若想编造精英阶层掠夺生产力收益的阴谋论，应将矛头指向高层管理者。
(不过坦白说，主要还是土地因素。过去十年间，资本在GDP中的占比基本稳定，土地份额略有上升，而劳动份额则相应减少。
劳动份额的分配结构确实经历了调整，但这与股东无关。)
任何拥有可支配剩余收入的人都能成为上市公司股东。
相比四十年前，首席执行官、董事会及交叉任职构成的寡头集团，已将企业收益集中于其手中。
所有生产力增长并未惠及劳动者，主要流向股权领域，随后通过期权和股票回购避税提取，导致公共服务和投资水平下降。
美国政府借债为减税买单的疯狂行径，正是终极例证。
这是狭隘与广阔的视角之争。广阔视角下，自动化等技术极大提升了经济总量；而狭隘视角中，人们失去工作、被迫转行重启职业生涯，甚至有人再也找不到新工作。
顺带一提，这不仅是自动化问题，还涉及企业决策——如公司合并、外包或转移生产基地(例如大量西欧制造业向东欧、亚洲等地迁移)。那些在行业深耕三十余年的从业者，突然发现自己距离退休尚有十余年却已失业，更因雇主破产等手段未能获得合理补偿。
我未曾观察到自动化与财富增长的关联性，但能源消耗与财富积累之间存在极强的相关性。
我认为提升生活水平的并非自动化本身，而是通过消耗更多能源实现的——这往往伴随着将成本转嫁给他人(如污染或森林砍伐)。
历史上确实存在过生产力增长惠及大众的时期，但过去几十年间所有生产力红利都被0.1%的精英阶层独享。
兰德公司的这份报告便提供了极具说服力的佐证：https://www.rand.org/pubs/working_papers/WRA516-1.html
我们记录了四十年间收入增长低于人均国民总收入增长的累积效应，并估算：若自1975年以来收入增长能保持战后前二十年的公平程度，那么截至2018年，低于第90百分位人群的总收入本应高出2.5万亿美元(增幅达67%)。1975至2018年间，低于第90百分位人群的总应税收入与公平增长情景下的理论值存在47万亿美元差距。
收入并非正确衡量标准。员工总报酬才是更准确的指标，其平均值约为薪资的145%。
员工总报酬包含雇主提供的医疗保险价值等项目。
你有什么证据支持这个观点？
> 感觉很奇怪，但这就是我们提高生活水平的方式
没错，但显然我们并非如此，反而可能正竭尽全力朝相反方向发展
> 将人力劳动从生产中剔除
卡尔·马克思会谴责这种恶行，因为它剥夺了劳动的价值与成就感。
https://en.wikipedia.org/wiki/Marx%27s_theory_of_alienation
你或许注意到，卡尔·马克思并非经济学领域的巅峰人物。
引用马克思的观点，就像引用亚里士多德或托勒密一样。
“裁员”或许比“解雇”更贴切，但本质上，消除高成本劳动需求往往是任何技术的核心“价值”。从整体社会角度看，这终究是利大于弊——想想那些因电冰箱淘汰的冰商和商人，那些被现代货轮取代的水手，我们确实因此受益。但在个体层面，这确实令人对受影响者的前景感到不安。我个人的结论是：人们有责任预见并适应变革，社会或许会在过程中提供帮助，但社会没有义务确保他们的生活方式永远不变。
这简直是本末倒置。
经济本应是服务社会的工具，惠及所有人。然而它正日益沦为富人攫取财富的游乐场，而无产阶级存在的唯一意义就是服务资产阶级——否则他们就会被抛弃到经济边缘地带，甚至沦落到社会的贫民窟，而他们的同龄人却高喊着“你们只是不够努力”。
说得极是。我们耗费大量宝贵劳动力在效率极低的“软件工程”上。资本不断流向这些效率惊人的所谓初创企业。
这番话深刻揭示了人工智能崛起与失业焦虑的关联。某些领域将出现难以预见的岗位替代，但整体而言，这很可能推动整个劳动力队伍的水平提升。
> 这很可能只是推动整个劳动力队伍的整体升级。
这怎么可能实现？
我预见白领工作将急速衰退，从而极大提升蓝领工作的价值。软件成本下降速度远超硬件。
但创新与投资将转向智能硬件，机器人效能与成本效益将同步提升。
若你能预见人工智能不会在一代人时间内使多数人类(经济价值)过时，我非常想了解你所认定的原理或机制。
手工艺人将迎来复兴，这或许是抵御人工智能取代的“升级”。许多需要体能的手工艺根本无法实现自动化。
因此能负担工匠服务的富人将愈发富裕，或许会为多处房产投入更多资金。但这不过是杯水车薪——在数万个岗位中仅能挽救一两个。面对当前社会层面的就业毁灭性冲击，这根本算不上实质性的“升级”。
深表认同。我曾以实习生身份加入某企业团队负责自动化改造。公司耗资打造了庞大的“编程工具”，旨在帮助在职三十年的婴儿潮一代适应新世界(我认为这对无大学学历的房贷持有者实属善举)。我被招来基本上就是瞎折腾找些小优化点。两个月内我写了个Python脚本，瞬间完成了团队约50%的工作量。
他们每年都裁员。记得有次“老板的老板”来访，坐在我们工位区。她问起进展，我兴奋地汇报成果。她追问我的感受，我差点脱口而出“只要会编程就轻而易举”。话到一半，我看见团队成员眼中闪过的恐惧，立刻转移了话题。那一刻我猛然醒悟：这些人确实从事着毫无价值的工作，但他们都有需要保险的孩子，有待偿还的房贷。而他们终将被抛入一个永远不会雇佣他们的职场——只因他们恰好赶上了大学文凭不再是门槛的末期。后来公司被一个冷酷无情的种族主义“大投资家”收购，他摧毁了公司，将其拆解变卖。但我的经理曾略带贬义地称附近唯一的程序员为“那个亚洲人”。
> 称呼他们身边唯一的程序员为“那个亚洲人”
要是再雇个程序员，他们就得记住真名了。或者干脆叫“那个亚洲人”和“新来的亚洲人”！
多年后的今天，你对整件事作何感想？
当年某公司有个专职复印员，后来施乐维修技师开通网络打印和邮件扫描功能后，这个岗位就消失了。客户虽因需求升级了老旧复印机，却始终没改变工作流程。
坦白说，这在任何软件工程工作中都不罕见。例如B2C企业的大量工作都围绕客户支持展开：构建网站、应用程序、撰写内容、开发聊天机器人等，其核心目标是让用户不致电客服——毕竟电话客服难以实现规模化。另一层考量是当用户确实致电时，客服人员能快速解决问题且行政开销最小化。
但这确实很奇怪，因为开发这类功能要耗费数百万美元。
我第一次参与项目时就遇到这种情况。当时完全不明白现场人员为何对我如此敌视。后来和销售人员聊起此事，他告诉我项目上线后这些人全都被解雇了。
> 所以我越是缩短周期时间，他们闲聊的时间就越少。
忍不住想象达里尔会因此对你发火。
感谢分享！
强制引用：https://thedailywtf.com/articles/Classic-WTF-The-Indexer
没错，我们这儿也是同样的情况，同样是仓库优化。我就是那个让员工换上新扫描仪的家伙，天啊…这些扫描仪居然没有实体键盘。现在所有50岁以上的员工都得对着触摸屏操作，这简直是天方夜谭。
我们还不得不引入固定位置和存储放置建议。仓储工人差点就造反了。不过几个月后情况就稳定下来了。
你的故事不是优化：这是强加给那些既未要求也无此需求的人们的变革。
这100%就是优化。引入功能更强大的新设备(比如能推荐存储位置)，取代那些十年老旧、每两周就报废的旧设备，这叫优化。
疯狂的思维方式。正是这种思维导致英语圈除美国外已无制造业。
所谓疯狂思维是指：人们应勤勉工作、获得合理报酬、享受富裕社会成果？还是指拼命干活让老板更富？
效率提升永远造福富人，薪酬差距持续扩大。你拼命干活，照样被炒鱿鱼。
工资上限设为最低薪资的5倍，企业除社会福利住房外不得持有房产，个人最多拥有两套住房。
大型语言模型吐出垃圾代码的速度越快，我就要花更多时间审查这些烂代码并应对它对我进行的精神操控，而真正享受的工作部分反而被压缩了。
过去三十年从事公共交通票务系统(如铁路闸机等)的非接触式支付开发。每当有人告诉我软件“准备就绪”时，我必问：
> 是否达到“高峰时段在中环站闸机旁实测全流程无误”的准备程度？
虽然项目团队分散在不同城市/国家，但我们坚持让开发人员轮流参与实际部署，让他们亲眼见证自己构建的系统运行场景——这极大改变了他们的态度和对细节的打磨。
更重要的是，他们领悟到“乘客乘坐公共交通是为了抵达目的地，而非与票务系统互动”。
这让他们深刻理解到：仅200毫秒的差异，既会影响乘客体验，也会改变车站的客流管理。
> “人们乘坐公共交通是为了抵达目的地，而非与票务系统互动。”
这句话深得我心，因为它适用于我们构建的诸多产品。
公共交通尤其耐人寻味，它映射出诸多场景。当你必须依赖却无法指望它时，便会成为巨大的压力源和时间杀手——你不得不额外预留数小时缓冲，只为确保不误约。
注意这里的措辞：“误约”而非“错过公交列车”。关键在于结果而非交通工具本身。
或者，假设你在异国旅行。地铁车厢内每节车厢都以数字方式显示线路信息——用英文标注已过站点、当前位置和下一站点——这对消除疑虑至关重要。多语言清晰的语音播报同样重要，因为当你坐着而所有人站在你面前时，可能无法看清显示屏。在墙上配备纸质地图作为备用方案也很明智，以防硬件故障。
认为“手机就能解决一切，这些设施都是浪费”的思维模式是错误的。地下区域可能没有信号，也可能有人尚未开通eSIM服务或设备故障——这些都是真实存在的难题。
从宏观角度看，旅行体验的成败至关重要。它可能决定旅程顺畅与否，更可能影响你是否向亲友推荐该国。这将牵动全球旅游业的兴衰——即便影响有限，仍具有显著意义。
泰雷兹？
这在《海伦定律》中已有深入探讨，该定律同样出自谷歌员工之手。
https://www.hyrumslaw.com/
我深信不疑。
我也相信，提供现成的正确使用示例能为所有人省去日后大量麻烦。
我始终强烈建议设计新API时附带示例代码。这往往能带来极具启发性的思考。
近十年来，我的业务始终围绕着微软和网景浏览器(当时的主流浏览器)中一个常见的漏洞展开。每次新版本发布时，我们都想着“这次他们总该修复了吧”，这本会给我们带来不少麻烦。但他们从未修复过！
我好奇这位评论者的业务性质，于是找到了这篇关于HTTP协议延迟的文章：https://jacquesmattheij.com/the-several-million-dollar-bug/
真酷的家伙https://jacquesmattheij.com/domains-for-sale/
>FREEDRUPALWEBSITEHOSTING.COM
是啊，现在这种域名行不通了。
>DOWNLOADWEBCAM.COM
这难道是“下载更多内存”的意思？
>BROWSEHN.COM
嘿，我正在浏览那个网站呢！
>MUZICBRAINZ.COM
听起来100%靠谱，软媒网保证无病毒。
>你的工作不是完成产品经理列出的需求清单，而是构建解决用户问题的软件。
关键在于：并非所有公司都认同这种理念。你可能因前者被录用，却坚信自己肩负后者使命。最好在面试阶段就厘清实际职责要求，最坏情况也要在新入职首日搞清楚。
这对渴望攀登职业阶梯的人而言是至关重要的建议。
绝大多数组织表面宣称要你聚焦真实用户痛点，实则要求你让上司(及其上级)光彩照人。这通常表现为清空任务清单而非开创目标。
谷歌内部同时存在这两类团队。
> 这使得软件工程师理解自身产品的核心价值与实际应用场景变得至关重要。你的职责并非完成产品经理列出的需求清单，而是构建真正解决用户痛点的软件。
你实际上描述了产品经理_本应_承担的工作：“理解软件的核心价值与实际应用场景”。
团队每位成员都应具备这种认知。
虽然关注深度和完整度各有差异，但产品经理本应实现双向沟通——可惜他们鲜少做到，往往只是机械地接收功能清单逐项打勾。
优秀的产品经理会向客户说明为何无法实现某些需求或需要调整方案，并赢得客户信任：他们明白你并非为了偷工减料而拒绝。
作为创新开发者，若让他人窃取你的价值创造力，你便沦为可替代品；此外，若团队采用仅为解决问题而设计的科技，缺乏对技术可能性的深入探索，将使团队能力局限于平庸之作而非客户惊喜。部分产品人已领悟这种可能性，但仍有部分尚未觉醒。
理想状态是二者结合：优秀的产品经理应比开发者更深入理解客户/市场，从而能与开发者探讨如何高效满足需求。现实中这类产品经理更像是独角兽而非基本配置，但这就是现状。
雷曼曾提出开发者-软件-用户三元组理论。三者对待解决问题的认知存在根本差异：
开发者误解用户需求，进而无法准确实现其错误理解；用户则既不了解软件能力边界，也不清楚开发者能实现什么。
> 无论善意初衷、正确性期许、一厢情愿，抑或管理层指令，皆无法改变代码语义本身及其执行效果。事后亦无法修正用户需求与程序实现之间的关系[…]，更无法调和任何一方与实际运行环境——即现实世界——的矛盾。
https://entropicthoughts.com/laws-of-software-evolution
我曾参与开发面向普通网民(非专家)的计算结果呈现软件。所有运算仅需毫秒级完成。
我们不得不人为设置约30秒的延迟，让计算过程看似耗时，因为用户抱怨速度过快。他们要么不相信我们真的在计算，要么认为系统出故障了，因而对结果产生怀疑。
这正是用户界面添加动画效果的原因之一——尽管技术用户常对此抱怨或直接移除。通过营造更符合物理规律的交互体验，动画能防止用户迷失方向、避免困惑，并增强其对操作流程的直观理解。
在您的案例中，可以展示更多中间值、绘制图表等。
每当看到动画的复杂运算消耗的资源竟超过其控制的逻辑/调用时，我总会忍俊不禁。
> 客户的负面反馈立竿见影。
当年设计TTL电路时，规格书规定了输入输出延迟的最小值和最大值。我被要求绝不能依赖最小延迟值——因为芯片速度持续提升，而旧款低速的替换零件终将绝迹。
IBM PC曾让许多硬件工程师头疼不已，因为原始设计中大量软件依赖定时循环和延迟机制，导致硬件难以加速。
在老式汽车上，比如我的72款道奇，系统电压会在12至18伏之间波动。但仪表盘仪器需要5伏电压。当时采用了一个巧妙的“蜂鸣器”电路实现，利用电磁铁和触点工作：当电压高于5伏时电路断开，低于5伏时闭合。虽然能产生5伏电压，但属于噪声较大的5伏。
许多人试图用半导体稳压器改进方案，使输出稳定在5伏。但仪表竟无法工作！问题在于仪表依赖噪声5伏来“解除”指针粘滞。
于是电子工程师不得不在稳压电路中添加“噪声”电路。
附注：观看老式航空电影时，可见飞行员起飞前轻敲仪表盘以解除阻滞。
啊，那个涡轮按钮！
记得我买第一台IBM PC时，这个按钮已失去功能，但机箱上仍保留着它。我反复按压它，困惑于为何没有任何加速效果。
我车里也有个，同样毫无作用。
确实不错但很天真。多数开发者既没有这种主人翁意识，也不了解用户如何使用软件。他们的工作本质上就是执行产品经理分配的任务。产品经理才该主导用户体验研究，肩负“打造解决用户痛点的软件”使命。当然，抽象层面这同样是开发者的使命，但在任何结构化(且希望高效运作的)团队中，产品战略本就不该是软件工程师的职责范畴。
优秀的软件工程师会关注产品战略。他们或许无法决策，但能基于实际开发经验为产品团队提供方案建议。
若只机械执行产品工单，终将被大型语言模型取代。
你必须成为具备产品思维的工程师。
软件工程师的职责转变之快令人咋舌——从几乎无需承担任何责任到必须包揽一切。我相当欣赏2026年的软件工程师文化，但相比五到十年前，如今的要求更高、竞争更激烈。
开发者不该测试，他们应该把代码扔给QA团队，由后者精准地按既定需求进行测试。
产品经理的职责是向开发者/设计师传达客户的需求，并将开发者/设计师的限制条件反馈给客户。
理解这些限制并确保其被有效传达，是开发者和设计师的责任。
我注意到现代趋势中几乎取消了质量保证环节。管理者和CTO坚称开发者能自行测试系统。或许在产品开发初期阶段(我近期正处于这个阶段)这种做法更合理？但似乎占用了开发者大量时间。
我从未见过纯工单制/零责任制能真正奏效。
别告诉我们你没在FAANG公司工作过。
在FAANG公司同样行不通，这正是它们软件交付速度极慢的原因。即便效率仅有10%，它们照样能印钞票。
令人匪夷所思的是，许多人认为软件工程师必须精通业务需求并整天与客户打交道。
试想建造摩天大楼时，如果建筑工人每天花1-2小时分别询问每个利益相关方想要什么、是否满意进度，然后根据客户要求修改布局——这岂不比砌砖、抹灰、架梁更耗时？最终能建成什么怪物般的建筑？
编辑：若要反对，至少提出反驳观点。还是说网络礼仪已死？
用建筑工人类比软件工程师简直荒谬至极。
建筑师和结构工程师早已完成设计方案。施工人员主要是在按预先制定的设计方案进行材料布置。
软件工程师不会收到相当于建筑蓝图的规格说明，他们获得的是需求文档或用户故事。随后他们必须在实际环境中逐步完善最终的真实规格。
基于规格说明，工程师需要决定具体实现方案——而这些方案在前期根本无法确定。
此外，软件工程师构建的产品几乎总是具有一定创新性，至少比普通建筑物新颖得多。即便只是筛选组件并进行配置，也往往涉及某种研究任务。
软件工程领域存在更多变数：1)用户需求传达不畅或沟通失误；2)基于技术细节发现实质性取舍；3)实施过程中发现不同利益相关方需求间的微妙矛盾；4)原型设计阶段用户对需求的更深入理解等。
开发者应当像建筑工人那样，对建造目标及其意义有基本认知。
这并非要求他们整天询问利益相关方需求，而是指当面临选择且需要决策时，开发者应能理解部分需求本质，从而提出可行方案。
诚然，木匠只是砌墙，但经验丰富的工匠若发现横梁将阻碍某些功能实现，就该主动向建筑师、施工方或客户提出警示。
完全赞同，但实践中这意味着开发者每周需多次参与客户会议以确保共识。这导致两种困境：要么全员参会造成时间浪费，要么开发者分别对接导致知识分散。
其次，开发者不仅要知晓“所有frobs都是percurators”的事实，更要理解背后的逻辑。除了跟进技术栈更新，现在还要求掌握客户所有业务细节(而客户可能一两年内就会变更)。
另一争议点在于软件工程师是否属于可替代性资源。
在制定施工进度表时，你可能拥有木工池、电工池等资源池。这些资源可作为可替代性资源分配到不同工种——就像一台电钻能替代另一台电钻，不同木工也能接手相同任务。
但我们都清楚，无论流程如何规范，软件工程师的价值本就不等同，因此无法随意调配。
既然点赞无需说明理由，点踩同样不必解释。
但容我尝试阐明争议所在：相较于物理系统，软件变更成本低廉得惊人。不同于实体建造，软件项目初期的设计方案往往既非客户真正所需，也非最终将要实现的版本——至少本不该如此。
软件开发中“砌砖”环节并非难点。无论将哪个环节类比为“砌砖”，该部分都可自动化处理。推送至主分支后，部署管道会自动运行测试，确保功能正常——瞧！一座新“房屋”就建成了。若软件成品丑陋不堪或坍塌，只需回滚至前一版本，仿佛什么都没发生。客户想尝试不同布局？成本可控即可实现。
软件工程中多数时候你并不确切知道如何实现，总伴随着探索、实验和学习的过程。说真的，客户可能根本没清晰表达需求，甚至随时可能改变主意。因此与客户和用户互动至关重要。
感谢回复。
> 若赞同无需说明理由，反对也不应需要。
我不同意，因为反对与赞同本质不同。首先，并非所有人都具备反对权限(至少在Hacker News如此)。其次，赞同通常意味着认同观点，而不同意应通过不赞同来表达。这是多数社交媒体的运作逻辑。点踩应保留给那些不该出现在讨论串的内容。
关于讨论主题，我认同“建设者”应主动了解所构建系统的知识体系，但“首席架构师”/项目经理应作为他们与客户之间的中介——即便只是为了成为单一信息源。
投身软件开发前，我在一家从事技术相关业务的公司工作。虽非尖端领域，但仅凭掌握一点PowerShell技能，我就改善了许多流程。
有天，公司里一位资深开发者——一个酷爱音乐的家伙——向我展示他将文本文件转换为SML的过程。他的流程是同时打开两个记事本：一个存放SML模板块，另一个存放待转换的文本文件。随后他逐行复制前缀标签和后缀标签，再粘贴到每行周围，以此完成转换。
我当场用PowerShell写了个脚本自动完成这项工作，足足省下他一天的功夫，他却只是呆呆望着我。我剥夺了他工作中唯一能当作借口听大量音乐的机械环节。不用说，他再也没用过那个脚本。
回想此事，我庆幸能在早期经历这番教训——它让我看清本质：任何看似改进的措施，其效果完全取决于受影响者的工作流程。
1. 我偶尔也会这样。一天或一周内能进行的深度思考有限，有时需要些机械性活动来放松
2. 今天清晨，新年假期刚结束——我2号休了假，上次工作是12月19日——我始终无法进入状态，幸好收到一封培训邮件，花了一小时处理。通常这种事得靠经理提醒。
这恰恰印证了所谓“bug”实为需求的设计典范。旅游业曾面临类似悖论——‘劳动力幻觉’：用户对过快返回的结果缺乏信任。企业刻意伪造“加载”阶段，因A/B测试表明人为延迟能提升转化率。这种“低效”反倒成为向用户证明系统高效运作的唯一方式。直到谷歌航班凭借搜索引擎的公信力推动行业变革，数百万用户才终于摆脱盯着安慰剂进度条的集体等待。
完全同意——我最喜欢的用户误用案例之一，是某款我们开发的应用程序。其筛选视图的加载速度极其缓慢，结果会逐条显示，导致点击“全选”时仅能选中当前显示的条目。当我们移除此功能后，用户抱怨不断，最终我们不得不添加Shift+点击来实现批量选中。
> 你的职责不是完成产品经理列出的需求清单，而是构建解决用户痛点的软件。
理解软件的本质目的与实际应用场景，能让你在规划、开发功能或修复缺陷时提出正确问题，避免错误假设。
当变更涉及冲突需求或顾虑时，你终将遭遇“产品经理更了解产品和客户”的回应，或直接被要求“你的职责就是交付指定内容”。
说得对。
我曾耗费大量时间清理15年前的代码库，移除了近10MB从未被使用的生产环境代码文件，成功缩短了构建时间。
本以为会得到团队认可，却无人提及。事实上项目经理反而忧心忡忡，警告可能引发回归问题。尽管我百分百确信不会有回归，但质量保证和项目经理却因我触碰正常运行的软件而恼火，抱怨他们因此增加了额外工作量。
后来我把这个成果发到领英上，总该得到些认可吧。:)
笑死，经理们。
虽然认同这个理念，但当项目团队规模达到一定程度时，这根本不可能实现。产品经理的职责是洞察真实用户痛点，并高效传达给工程团队，让工程师专注于技术实现。
不。产品经理必须把握全局，但当团队规模如此庞大时，自然意味着你所负责的产品也足够庞大——任何人都无法同时记住所有细枝末节。
你不会期望工程经理对每个代码决策都进行微观管理——他们的职责是有效授权，让合适的人解决正确的问题，并建立有效的反馈机制，让工程师能感受到自己决策带来的后果，无论好坏。同理，产品经理也不可能事无巨细地管控产品体验的每个环节——他们的职责在于高效授权，让合适的人员解决最关键的问题，但产品开发中必然存在无数细微决策，工程师必须拥有自主决策的工具。此外，若不直观理解技术限制，就永远无法达成优质工程设计——产品开发需要与工程团队反复协作，若将产品知识孤立于单一角色，便丧失了在工程与产品双赢的场景中，通过建设性反对简化功能的能力。这正是原帖所言“真正理解问题的工程师往往发现，优雅的解决方案比任何人预期的都更简单”的深意。
若无法理解用户痛点，说明项目已严重偏离正轨。
大学时曾有人告诉我：每个软件系统都是社会技术系统。牢记这个观点让我受益终生。
这份清单之所以突出，在于它将工程视为超越正确代码的生产。其核心在于创造清晰度，让他人得以在此基础上构建。清晰度胜于巧思的理念无关风格，而在于降低他人深夜修改或扩充代码时的风险。这往往是技术效率与团队可靠贡献之间的分水岭。
那么针对该具体问题，正确解决方案是按客户调整加载时间吗？
或许只需让他们发泄情绪直至调整习惯，转而与同事交流，无需以此为借口。届时他们就能享受快速加载体验了 🙂
老板为何要接受这种方案？自动化本就是为消除员工空闲时间而设。若员工因失去聊天时间而沮丧，说明他们失去监控时本就缺乏自律能力。这种情况下唯一能帮他们的方式就是进行组织管理。
因为十分钟的闲聊同样有价值。企业才会在团队建设活动和斧头投掷上投入大量时间。
不，这是人力资源部门为自身存在辩护的托辞。
况且这种模式适用于高阶服务类岗位，而非仓储物流。
更何况大多是胡扯。
团队之所以高效，在于成员兼具个人与技术双重技能、高情商与高智商、领导力与主人翁精神。
你究竟是被动融入团队还是被迫参与幼稚游戏，根本无关紧要。
对多数人而言，喜欢同事并和他们成为朋友，是决定工作满意度和留任意愿的关键因素。我离职的多数时候，都是因为喜欢交流的同事离开，剩下的团队成员又呆板又抗拒社交。
忽视用户才是正确方案。通过软件加载来定义企业文化简直荒谬。
次生效应呢？
忽视客户会形成恶性循环，终将导致失败。
但若对每个客户需求都妥协，解决方案又会过度拟合。
其中必须运用判断力。
但如何让判断成为可重复的过程？此类权衡中反馈往往滞后，因此晋升机会常落到能展示指标上升的人身上——即便这些指标目光短浅。这个过程的可重复结果是平庸。令人惊讶的是，这种平庸在平均意义上反而奏效。
史蒂夫·乔布斯留存了大量产品创作视频——https://youtu.be/Q3SQYGSFrJY
必须由个人或小团队怀揣愿景进行创作，并具备执行能力——即便用户初期抱怨(他们总是如此)。最终诞生的产品要么赢得用户青睐，要么遭到弃用。若缺乏愿景，你不过是在做A/B测试，最终会被怀揣远见者取代市场地位。
这需要正确的愿景+足够的影响力来执行。
这不是重复的过程。在取得巨大成功之前，很难区分有远见者和疯子。
首先明确真正的客户是谁。
其次明确真正的痛点是什么。
第三，定义一个能解决他们80%问题的方案。
这一切都不直观或显而易见。它甚至可能在技术上不可行或无利可图。
每个人的大脑都会构建一个世界模型。
某些人永远无法达到的成熟境界在于：当认知模型失效时，不必认定世界崩坏、他人蓄意陷害，更不必认为世界有责任迎合你的内在模型——事实绝非如此。
这不过是人们抱怨世界不符合其内在模型罢了。表面看似有理有据，实则不过是事后为认知失调强行找的借口。久而久之你便能识破这类说辞——人们向来不擅长向他人甚至自己解释情绪背后的缘由。
解决之道在于保持同理心：既要审视对方言论中是否蕴含深层道理， 但更重要的是静待一两个月，看异议是否会悄然消散——因为他们的认知模型已完成更新，若此时恢复旧版缓慢的加载速度，他们反而会更加恼火。毕竟这不仅违背了他们更新后的认知模型，更会造成巨大的时间浪费！
有思想的人应当学会辨识世界模型违背的内在感受，从而绕过人类底层模型中预装的自动合理化回路，将此类感受交由意识分析系统(常被称为系统2，尽管我极度厌恶这种命名)处理，而非默认交由系统1处理。
> 但如何让判断成为可重复的过程？
原则能帮助决策规模化。
反正软件运行所需的停机时间减少，他们的老板们大概更开心。
解决之道在于承认这并非软件开发问题，并尽可能无痛地抽身离开。
若管理者想在员工日程中安排晨间休息，大可自行安排。这根本不需要软件修复。
简直疯了，谁需要经理许可才能喝咖啡？任何把员工当成年人对待的组织都不该有这种问题。
组织工人
还有别的办法吗？向老板求情？组织工会的意义就在于此
最离谱的投诉来自用户：他们抱怨笔记本过热/噪音太大——只因我正确地将任务并行化导致系统效率过高。他们喜欢速度却讨厌风扇全速运转，更抗拒CPU(连带整台笔记本)变得滚烫(约2010年左右的事)。结果我不得不人为降低处理速度，避免风扇嗡嗡作响和CPU过热。
如果风扇在原本无需启动时开始运转，说明之前是依靠自然散热，而你的修复方案加速了散热需求。这虽然节省了时间，却消耗了额外电能(还破坏了安静房间的宁静)。
我认为这很容易理解。大约70%的情况下，当听到机器风扇加速运转时，我都会默默希望处理速度能慢些。对于短暂的高负荷操作尤其如此。
显然正确方案是调整系统热管理/功耗目标，但你也可通过修改调度策略强制程序降速：
我的意思是理解用户抱怨并要求回滚的诉求，并非指我无法在自己的机器上解决此问题。对非技术人员而言，正确做法是请专家修复——这可能包括撤销更改，毕竟他们本就不关心进程加速问题。
我曾通过在CPU受限的cgroup中运行进程解决过此问题，但后来重写dwm配置时丢失了该命令，且未再维护此修复方案。
开发者对此并无实质控制权。调度策略由宿主系统负责，运行速度加快通常意味着功耗降低，而开发者无法预知何时操作会触发不必要的散热风扇——这取决于系统其他进程的运行状态。他们能做的最多是添加复选框以运行旧代码，或通过插入睡眠调用来实现。
你可能需要设置较低线程优先级/QoS。操作系统懂得如何调度线程以避免CPU过热——至少在现代硬件上是这样。
楼主确实提到这是2010年左右的事，所以我们讨论的是15年前的技术。
任何称职的操作系统都应以最小化总能耗而非风扇噪音的方式运行线程。
台式机用户并不在意总能耗，但他们确实介意夜间维护任务中的风扇噪音。
我在Unix系统上优化掉冗余进程后加快了启动速度。
但不得不保留仅打印相同日志的占位进程——管理层不愿重新培训操作员或重印文档。
90年代中期。所有培训手册和操作指南都是纸质版。
https://xkcd.com/1172/
海勒姆定律：https://www.hyrumslaw.com/
那便是https://xkcd.com/1172/
请停止滥用、挪用并贬损工程师头衔。
我最初是在这篇关于软件架构的经典文章中了解到“创新代币”的概念——至今仍是我的最爱之一：《新奇是笔贷款，你将用停机、招聘和认知开销来偿还》：https://boringtechnology.club/
同样，“抽象不会消除复杂性，只会将其转移到你值班的那天”这句话，让我想起乔尔·斯波尔斯基23年前的经典著作《泄漏的抽象法则》：https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a…
唯有简化需求才能真正消除复杂性。复杂性只能被重新洗牌，并分散到系统其他区域(或库、供应商功能等)
我认为这适用于本质复杂性。这确实是采用“快速迭代发布”策略的最佳理由之一，因为实际使用能帮助厘清哪些需求才是真正必需的。
但许多项目会引入大量偶然性复杂性，尤其体现在技术选型上。例如“简历驱动开发”模式鼓励选择炫酷或新奇的工具，而实际上更简单的方案就能满足需求。
另一大冗余复杂性来源是为永远不会实现的功能编写的代码，或是本质上具有历史遗留性质的代码。有时这涉及需求本身，但更多时候是为缓解工程师的焦虑。
你完全可以消除不必要的复杂性。若应用程序对搜索结果的每行数据都发起HTTP请求，改为一次性获取所有结果就能简化流程。
深入观察一两层底层实现，你会发现绝大多数现代软件都存在大量不必要的复杂性。
我讨论的并非多余(或偶然)的复杂性——那完全是另一回事。我指的是系统实现特定功能所需的必要复杂度。若因刻意引入冗余复杂性(如“简历驱动开发”或追逐新技术的倾向)而选择复杂方案，那便是另一类问题。有时可通过实际考量消除复杂性，有时却受制于组织政治等固有力量。
举个简单例子：若我使用库中的排序函数而非编写自有排序代码，确实未消除程序的核心复杂性——排序功能本身。但我的代码复杂度无疑降低了。
同理，若我将重复操作拆解为命名明确的函数——实际处理的复杂度并未改变，代码复杂度也未消除——但这相当于用N段独立代码的复杂性，换取1段核心代码加N次函数调用的结构。诚然，这种权衡并非总是正确之选，但仍可断言：多数情况下，此举确实降低了代码复杂度。
我认为多数人并非宣称抽象化能消除复杂性，而是强调无需每次都直接面对复杂性——这正是抽象化的意义所在。
简单举例：每次启动应用程序时，你无需处理操作系统的进程管理复杂性。开发软件时或许需要接触，或当应用程序卡死时需通过任务管理器强制终止。但绝大多数用户永远不会接触这些，因为它们已被抽象“隐藏”——这正是抽象的意义所在。尽管如此，实际的复杂工作始终在后台默默完成。
我最初是在《新奇性是一笔贷款，你将用停机、招聘和认知开销来偿还》这篇至今仍是我最喜爱的软件架构文章中了解到“创新代币”的概念：https://boringtechnology.club/
我认为这种观点并不绝对成立——尤其当前许多流行的编码实践，往往导致代码隐含依赖系统其他部分可能无预警变更的假设；而创新恰恰能强化这些假设的稳健性，最终降低软件意外崩溃的概率。
我不太理解。遵循健壮性原则未必会引入创新。或许会增加些许复杂度，但具体程度取决于你追求精巧的程度。
你的意思是？
我前任老板有个“每个项目只允许一项创新”的铁律。这既是上限也是下限，确保他“始终保持学习状态”。
我遵循这条规则数十年，每次无法做到时都深感遗憾：项目要么枯燥乏味，要么压力山大——唯有达到新颖性的临界点才例外。
这很合理…只需相应调整项目规模即可！
这听起来简直绝妙！
就像斯波尔斯基那篇文章里多数观点一样，这论调相当可疑。按其逻辑推演，如果软件是用汇编语言手写编写的，那么值班调试工作应该会更轻松吧。
15年领导岗位经历，辗转三家公司主导零售业重大转型，经手系统处理近千亿营收。管理5500万至1亿美元年度预算… 直接管理300多名全职员工及三倍数量的合同工… 当时谷歌内部规模最大的零售商… 我的工作影响了GCP路线图、Datastax路线图… 幕后还有更多… 除了入职所需的才能与能力——但一旦身居高位，政治手腕和拍马屁才是唯一标准。我见过太多比我聪明的人，却因不懂权宜之计而止步不前。我未能更进一步的唯一原因，是同样不懂如何玩转政治和拍马屁。
高层全靠互相拍马屁，只顾照应同伙(比如2013年初和他们同级的人)。所以教导孩子学会拍马屁和玩弄权术吧。
或者让他们远离这些，去过有意义的人生。
我实在不明白这类人的想法。他们真想把毕生事业定义为“拍马屁玩权术”吗？我理解“为生计而工作”的道理，但你们基本是在挥霍半生光阴……换取什么？金钱？你们到底需要多少钱！？
旁观者或许觉得不堪，但政治本就是推动事务的艺术。若你能指着组织架构图和交付的路线图说“我参与了建设”，这绝非虚度光阴。领导力与执行力同等重要。
因为他们不这么看待自己的工作。在他们眼中，这是“为团队和热忱发声”、‘助力他人职业发展’、“拓展人脉建立长久联系”。
当然可以“为生活而工作”——住豪宅、雇保姆、吃牛排、坐商务舱去阿尔卑斯滑雪或加拉帕戈斯潜水…但要达到“不再渴望更多金钱”的境界，恐怕需要巨额财富支撑。
并非如此。多数人即使收入低于科技行业平均水平也能获得极大幸福感(前提是不会因追求更高收入而牺牲工作生活平衡、家庭时光或职业满足感)。
我永远无法理解这种“为什么X——因为Y——但Y已经太多，Z就足够了”的三重论调。显然很多人并不真正快乐，否则他们不会通过拍马屁搞政治斗争来获取更多金钱。
除了大房子(在多数地区这都不难实现)之外，上述清单里没有任何东西能激励我加倍努力工作或拼命干活。
当然，很多人不在乎这些东西，所以不会为此规划职业生涯。但有些人确实需要，这才是我们讨论的重点。
不过说清楚点，我本该说“这可能需要大量资金…”
关键在于性格特质。要么真心热爱游戏，要么怀有永不满足的(恐惧驱动的？)地位渴求，或是类似特质。性格无法随意选择——尽管存在有限的改造可能，例如人格障碍的治疗手段。
> 其实是享受游戏本身，或是怀有无法满足的(恐惧驱动的？)地位渴求，抑或其他类似动机
即：某种程度的严重精神障碍成为领导力的必要条件。
不知我们为何踏上了这条最黑暗的时间线？
人类自开天辟地便如此。酋长、可汗、沙皇、国王等等。
若能适应环境，便不算病态。
妙啊，这倒是为成瘾行为找到了新借口
进化。这是个残酷的过程。
我日日质疑此事。总有人辩称：若我懂得玩弄权术、谄媚奉承，或许能获得更多机会，创造更大影响力去帮助他人/娱乐大众/提供有价值的服务或产品。可自我推销终究令人痛苦(即便冠以“工作成果记录”之名)。
这在某种程度上类似音乐造诣。你见过多少才华横溢到令人发指的音乐人，却深陷无人问津的境地？在酒吧里，在三线城市的破旧爵士俱乐部，在深埋网络的角落里，SoundCloud上仅有13次播放量。但我们都清楚，流行音乐未必青睐精湛的演奏技艺。
人生与事业亦是如此。
嗯，我认为这取决于视角和动机。
拍马屁/玩政治可以视为服务不同目的的技能。假设你的抱负是建造桥梁、摩天大楼或华丽歌剧院。
要成为这类项目的承建者，你必须玩转各种游戏，包括政治博弈。
(我假设是出于善意，自私动机也可能存在，但值得讨论吗？)
对某些人而言，这不仅是能力所在，更是乐在其中。
建立人脉与地位，难道就不如编写代码、建造桥梁房屋或绘制画作更有价值？
人们有权选择参与的游戏。
> …为了什么？金钱？你到底需要多少钱！？
“更多”似乎是多数人的答案。
取决于你想住在哪里，但500万到1000万美元足以提供足够的被动收入，保障家庭和子女的未来。
这并非收入最高的人生道路，但这也是我的选择。在优秀人才聚集的小公司工作，远胜于在大型企业与普通人共事。无论初衷多么美好，职场政治终究令人精疲力竭且毫无成就感。
当然，我本就是逃离都市生活搬到乡下的人，所以因人而异。
我两种经历都经历过，各有优劣。大公司能打造更宏大、更具影响力的项目，参与其中确实令人满足。楼主显然仍为自己通过“玩弄权术和拍马屁”所建成的成就感到自豪。
但(对我而言)在庞大机器里当个小齿轮确实令人倦怠，尤其当周围所有人都在做同样的事时。因此在更小、更凝聚的公司工作绝对有其优势。
总是觉得别人的草更绿嘛！
何不两者兼得？
这是楼主的人生第二十课：终有一天，时间会比金钱更珍贵。请据此行动。
我见过资深工程师为追逐晋升、争取几分薪资涨幅而耗尽心力。其中有人如愿以偿。但事后多数人都在扪心自问：值得吗？
我们终究是人际交往的生物。所谓“拍马屁”不过是学习影响他人、协作共事之道。这在职场中堪称最实用的技能。但别担心，继续鄙夷它吧，继续用贬义词指责它，看着你的职业生涯停滞不前。
> 这是职场中最实用的技能。
这在多数职场或许是事实，但为“政治手段胜过能力”辩护，本质上等同于宣称“我理应享受他人劳动的成果”。
人们反对它源于道德谴责，而非认为这种描述不符合现实。
你说的好像政治是可选项似的。事实并非如此——决策必须产生，而政治正是决策的生成过程：由谁决定，基于何种理由。
以学术界为例，政治因素较少，因为出版体系本身就构成了决策过程。学者以论文形式提交观点，评审者先判定其是否足够优秀(且论证充分)值得公之于众。随后才涉及政治因素——一场人气竞赛。但关键在于，这种体系众所周知会导致大量资源浪费：优秀研究因无人问津而石沉大海，劣质研究却因备受追捧而虚耗资源(冷聚变便是典型)。
政治不过是我们决策方式的代名词。没错，它很糟糕，但这恰恰是因为我们很糟糕。
既然你如此理解学术界，那你简直是为他们开发软件的完美人选——因为若你以为学术界“政治少些”，那可就太天真了。
学术界以政治斗争臭名昭著，尤其围绕终身教职、科研经费、奖学金等事务。
发表政治只是其中一小部分，但即便在论文署名顺序的安排上，也暗藏政治博弈。
这并非能力与政治的对立，而是现实世界中推动事务的生存法则。
(历代帮派头目与独裁者齐声)：说得好！
大学和“民主”机构亦是如此。
有时确实如此。
有时纯粹是胡扯。
掌握行话术语、正确姿态和推卸责任的标准方式——这才是某些机构的生存法则。
我听起来很愤世嫉俗，但其实不然——我玩这套游戏相当在行，也证明过自己。只是我不喜欢这套游戏，因为它无法让我为自己的成就感到自豪。一切都是在服务于虚荣心，你自己的，还有别人的。
我待过的每家法国跨国公司都是完全建立在这种模式上的。
> 我其实很擅长玩这套游戏，也证明过自己，
很好。我失败了，很可能即将面临后果。
真正重要的人不会因此责怪你。
去他妈的装腔作势。干点实事吧。
你没说错。只是忽略了众人诟病的核心：那些成功推动劣质方案的人，总能在真相大白前溜之大吉(在大公司这可能耗费数年)。
我前公司处境艰难，这类人终于开始暴露。但要等到重大失误频发后，才能真正清理门户。
> 那些成功推动劣质方案，又在问题暴露前溜之大吉的人
这大概就是随机进化的结果吧。有些公司付出的代价会比其他公司更大。而且并非所有人都像你这样能认清并指出问题。
但总体而言，影响他人对个人而言是净收益技能。对鹅有利的，对鹅夫也该有利？
> 有些公司付出的代价会比其他公司更大。
问题在于，大型企业通常拥有一只或几只“金鹅”。凭借现有的护城河，它们能长期榨取价值。护城河虽在不断缩小，但竞争者往往需要十到二十年才能追赶上来[1]。这段漫长时光足以让某些人靠玩转政治手段谋生，却无需付出多少实质贡献。
许多员工在公司衰落前就已离职，如今正毒害着其他企业。
[1] 看看谷歌与搜索引擎的垄断，微软与Windows的霸权，甚至微软与IE浏览器的历史便知。
我从未思考过“如何影响他人”这类问题。为何这被视为重要技能？听起来不过是“操控”的委婉说法罢了。
若他人不够聪明，无法理解你想法的优越性，你就需要向他们解释清楚，或设法说服他们配合。
我所谓的“影响”，大多只是反复向人们阐明道理，让他们自己思考那些糟糕想法和死胡同。
如果你是软件开发者，肯定有过“当前优先级有误，我们应该为用户做X/通过Y提升质量”的想法，并试图说服管理层调整优先级。比如发起用户倡议让需求从多渠道涌现，或通过质量指标论证方案的价值。
所以要主动与人喝咖啡，甚至和吸烟者外出交流。让他人主动提出你期望的方案，可能需要数月“耕耘”。
但这种影响能力对职业发展无益。
任何试图说服他人的行为本质上都是“影响”。若你明知某事对己方更有利却仍试图说服对方，那便是操纵。
你认为教育他人也算“操纵”吗？
我基本认同你的观点，但职业发展确实可能停滞。或许你已身处理想岗位，每天解决酷炫难题。或许晋升能带来更高收入，却让你离真正想要的生活越来越远。
顺便说一句，这番话更多是给读者而非你本人的建议。明确目标并为之奋斗至关重要。
不，人们常说这种话，但那些没有这种无谓社交游戏的组织，往往会把那些存在/需要这种游戏的组织打得落花流水。
或者继续当个混蛋去拍马屁，看着员工们组建工会，看看你鄙视的人们如何向你展示谁才是真正掌握权力的人。
我认为这正是许多人渴望创业的原因。当然，其中不少人最终不得不(或陷入)向投资者拍马屁的境地。
> 所以教导孩子学会拍马屁和玩弄权术吧。
教导孩子学会踢屁股，并警惕政客。
我同意——这篇文章中关于职业晋升的论调最令人反感。
但这确实重要。我也觉得反感，就像人类社会现实中其他许多我不喜欢的东西一样。关键(我认为)在于找到平衡点：既要清醒面对“职业晋升很重要”这类残酷真相，又不能沉溺于愤世嫉俗和自私算计。
我认为本文很好地把握了这种平衡。(当然具体观点可以商榷。) 真正让我纠结的是那段关于“不该仅凭热心做粘合剂工作”的论述——要自觉将其转化为可读性工作而非个人特质。我讨厌这点！这完全是我的本性。我乐于助人，享受这类工作，而且真的不想去揣测高层管理者的评价。
但我也认为他的观点相当精辟。在庞大组织的最底层充当粘合剂，眼睁睁看着周围同事因作品更具可读性而晋升发展，却仍能心满意足——这种人格特质极其罕见。能做到这点而不心生怨怼的人少之又少。
因此我更倾向于将奥斯曼尼的建议理解为规避怨恨的常见陷阱，而非愤世嫉俗的职场算计。
(关于像我这样的“粘合剂型工作者”还有个残酷真相：我们并非不可或缺，只要工作流程被清晰记录，团队其他成员完全能接手。这正是奥斯曼尼的建议——与其“热心”回应所有私信求助，不如将常见问题的处理流程文档化，并建立轮值机制分配响应责任。这让我很沮丧，因为我确实享受在团队中担任随叫随到的帮手，但对组织乃至包括我在内的所有人而言，这种方式显然更优。)
顺带一提，从斯多葛主义视角看，粘合剂/协调者角色正被基础LLM彻底取代。
若你忽视游戏规则，在他人更注重交易时沉溺于安逸，怨恨感会更强烈。关键在于接口管理与持续契约，以及预判两步以上的规划。
我完全不同意你的第一句话。大型语言模型在编写大量代码方面仍远胜于梳理组织架构的实际衔接逻辑。
我确信它两者都擅长。
>我乐于助人，喜欢这类工作，真的不想去思考或在意它如何解读高层管理层的意图。
抛开编程不谈，我担心这已沦为被接入高管日程表和组织架构图的LLM的牺牲品。你不过是在叠加又一层非人类的数字化中介。
我乐意保留分歧，但这似乎是对我所指工作性质的误解。我不明白接入高管日程和组织架构有何助益，看来我们讨论的可能是不同事物。
但关键在于，这种“与”的关系被误解且对多数人不可见——这正是本讨论的核心！所以这种误解完全可以理解 🙂
> 高层全都是互相拍马屁、只顾自己小圈子的人(比如2013年初就和他们同级别的那些人)。所以教导孩子们去拍马屁玩政治吧。
在科技巨头工作二十余年后，我深表认同——这基本就是真相。仅凭能力能走多远是有限度的。若想自我安慰，不妨将政治重新定义为“人际系统”，专注优化系统内的关系网络。管它叫什么呢。核心要义就是找到强势团体，设法成为其中一员。
>因为他们不懂玩政治
或者他们拒绝玩这种狗屁游戏
确实。我以前也把自己归入这一类。埋头干活，远离职场游戏。我还自以为聪明，靠努力工作保持自尊，把日常政治斗争留给别人。可前阵子我接连挨了经理两三次训斥，理由是我不够重视领导反馈，没有及时改正。尽管我是唯一掌握旧系统知识的人。显然我其实相当可有可无，却始终自以为不可或缺。
考虑到市场形势，外部机会渺茫，而当前悲惨的工作环境终究源于我的选择。所以最终，不玩政治游戏对我而言毫无胜算。
> 就在不久前，我接连遭到经理两三次训斥，理由是我没有认真对待领导层的反馈并改正自己的行为方式。
与上司的上司建立关系至关重要。有些组织称之为跨层级一对一沟通，有时只是搭上司的车。这绝非搞小动作或推卸责任。
原因在于管理者难免犯错，当你与上司的上司建立关系后，当某人(你、你的上司或上司的上司)出现失误时，这种关系能帮助事情回归正轨。
回归核心：当主管批评你时，与上级主管的关系能让你判断批评是否合理，或是主管失误需要上级介入。
—
具体案例：几周前我的主管批评了我。当天早些时候我与CEO交谈时，他明确表示我完全正确。因此主管训斥我的整个过程，其实是在自打嘴巴。有趣的是后续发展——因为所有人(包括我、CEO及公司其他成员)都非常尊重这位主管，希望他能转任非管理岗位继续工作。
你现在正值年终考核期，他可能在软化你的态度。
为何不向主管提及CEO支持你的立场？他们掌握的数据是否存在差异？不过临近假期追问这些确实不太愉快。
别妄下结论。我公司根本不搞年终考核。
简而言之，我写了个粗糙工具绕过公司现有工具的复杂抽象层，操作便捷得多，结果惹怒了经理。
主管发火时，我先提醒他不宜在全员面前争执，随后向CEO寻求建议。CEO给我的建议后来在当天的1对1会议中派上了用场。(CEO对这个简易工具能减轻同事负担也相当满意。)
> 为何不告诉主管CEO支持过你？
当经理表示无法向CEO“推销我的工具”时，我建议他直接与CEO沟通此事。
简而言之，这位创始人出身的经理在人员/项目管理方面存在短板。资金限制了我们的选择，否则本应聘请专业项目经理，并将经理(即创始人)晋升至战略决策岗位。
>我建议我的经理直接与CEO沟通此事
直截了当：
为何不直接告诉经理你已与CEO沟通过？这样就避免了：
1. 隐瞒自己越级汇报的事实
2. 且跳级汇报的CEO对方案表示认可。
这种做法可能让经理误解你的善意为消极对抗。或许是你的跨级主管让你这么说的。
无论如何，祝你好运。
处理政治关系和领导力是责任所在。回避只会树立不良榜样。了解组织运作机制后，就该协助引领它。
若以家庭为喻，这等于宣称你只愿“完成任务”：刷牙、喂孩子、打扫卫生，却不承担家庭目标的任何责任。不推动孩子学习新知，只执行他人安排的接送接送；不通过换购更大车辆改善生活条件。毫无引领作用，仅是执行配偶的指令。
当然我有些夸张，但其中确有道理。
这在商界就是反社会人格。大公司里这类人常占20-40%，尤其金融领域比例更高(我每日可见)，且随着职级上升，其集中度不断攀升。
关键在于——你根本不必参与这种游戏。诚然，你会错过一些晋升机会，那些头衔大多毫无意义；这类工作带来的压力和负担会大得多，收入也略高些。但在多数公司里，这点钱根本不值(比如多付出50%的工作量只换来20%的净收入增长，实际到手还不到10%，因为额外收入在多数国家都会被高额边际税率吞噬)。
但核心原因在于——数十年间每周投入40+小时的工作(尤其是工作方式)会潜移默化地侵蚀你，即便你竭力抵御。难道值得用更多反社会行为和思维模式永久玷污人格，进而破坏所有人际关系乃至个人幸福吗？我年岁已高，目睹过同龄人逐渐陷入这种状态——过程虽缓慢，但一旦懂得观察便显而易见。
当生活困顿时，这种妥协易被合理化，毕竟贫困足以使人崩溃。但一旦摆脱困境，生活品质就该成为首要追求，人生本就短暂。否则往后多半会后悔，不妨仔细聆听长者们自豪与遗憾之事。
> 4. 清晰即资历，机巧是负担。
清晰度或许是编写可维护、可扩展代码最重要的要素。当然，说起来容易，实践中却难以诠释其具体形态。
我曾撰写专著探讨清晰编程之道：https://elementsofcode.io
> 11. 抽象化并非消除复杂性，而是将其推迟到你值班那日。
糟糕的抽象确实如此。
> 抽象的目的不在于模糊概念，而在于建立新的语义层级，使思考达到绝对精确。(迪杰斯特拉)
若以这种视角理解抽象，其价值便显而易见。我们将CPU指令抽象为编程语言，正是为了用数据结构、函数等更精确的概念思考问题。
显然，构建抽象层以在语言之上实现更高精度具有重要价值。
问题不在于抽象本身，而在于目标的清晰度。我们常常在尚未真正理解待建模行为时，就匆忙创建复杂的行为模型。这如同土木工程师未勘察实际地形，就在仓库里设计桥梁。当桥梁无法正确安装时，我们不会归咎于桥梁的概念。
关于抽象化观点我赞同你——这是作者论点中我唯一不完全认同的部分。
但需注意的是，每次进行抽象化操作都存在风险：它未必能提升清晰度和精确度，原因可能是人类能力的局限，也可能是问题本身的变迁。作者的警示很有道理，因为实践中这种情况确实屡见不鲜。与其面对抽象不当的代码，我宁愿处理抽象不足的代码。
宏观层面：完全同意。但实际操作中情况复杂。所有编程抽象都存在某种缺陷，关键在于你能容忍多少缺陷，以及收益是否值得代价？
我认为优秀程序员的成长很大程度上在于培养直觉：何时值得投入精力，以及该朝哪个方向努力。更复杂的是，还存在一个元维度：究竟该花多少时间钻研抽象，还是直接实现功能再后续修正？
顺带一提，我非常好奇编码智能体将如何改变这种平衡。
我发现清晰度可能是普遍成功的关键要素。例如清晰的沟通能让人产生参与感、被倾听感和认同感。而机巧则充斥着大量缩写和华丽辞藻——比如用“vis-a-vis”这类词代替直白表达，导致信息难以被普遍理解。
前三个观点让我深受触动：
1. 最优秀的工程师痴迷于解决用户痛点。
我认为问题根源在于早期教育：学生先学习语言、框架和工具，却不理解它们实际解决什么问题。当工程师积累了为用户打造产品的经验后，才会真正明白用户关切的核心。
2. 坚持己见易如反掌，携手达成共识才是真功夫。
– 可悲的是，多数争论最终由权势者或经验者胜出。正确决策源于共识。创意阶段需凝聚共识，危机时刻则需运用权势与经验。
3. 行动优先。发布即王道。糟糕的页面可以修改，空白页面却无法编辑。
– 每个决策都是风险管理。智者将高风险转化为低风险。多数人因惧怕失败而畏缩不前，终日耗费在争论辩驳与相互攻讦中。
回想起来，编程语言教学后确实应该安排一些实践环节，让学生去解决用户问题——有些问题其实无需编程就能轻松解决。更需要的是通过问题梳理环节，教会他们如何理解问题本质。
实习本该承担这个功能，但如今许多地方都已形同虚设。
第三点的问题在于：一旦基于糟糕的初稿展开协作，团队便会陷入既定轨道——即便另辟蹊径能获得更优解。即便时间窗口允许重启，也无法从零开始，因为工作链条已然启动。
但这总比毫无进展强，这才是关键所在。
你需要(或希望成为)的工程师，是那些足够聪明且经验丰富，能在无需反复经历冗长的ADR、讨论、辩论、POC、修订等流程来确定X、Y、Z的最佳实现方式时，就能完成基本准确的初稿的人。若团队缺乏具备深厚经验的人员——那些能凭直觉在初期就选对工具、模式和抽象概念的人——这种反复打磨或许不可避免。但关键在于：从更接近目标的位置起步，而非遥远起点再逐步迭代。
去跟Facebook的元宇宙团队说说这个理论吧
我认为这取决于团队。
有些团队里，我们能毫不犹豫地承认“这方案糟透了，肯定搞错了”，然后重回设计阶段。
而另一些团队里，哪怕只是搞出个垃圾产品，也算巨大成就——若此时宣称失败重来，只会酿成灾难。
我基本认同这些观点，但此类清单的最大价值在于作者将思考付诸文字。必须回顾职业生涯的多个维度并进行整合。单纯阅读几乎毫无意义，如同浏览满屏新闻——一旦投入日常工作，所有内容便烟消云散。
我认为最佳建议是尝试亲自撰写这样的清单。
至少感觉有大型语言模型辅助。
> 关键不在于观点正确，而在于通过讨论达成问题共识
> 清晰表达并非风格偏好——而是降低运营风险的手段
> 核心要义并非“永不创新”，而是“仅在具备独特创新价值时创新”
> 这并非单纯自我推销，而是让价值链对所有人清晰可辨
> 问题不在于工程师不会编程或不会用AI代写代码，而在于我们编写能力太强，反而忘了思考是否该编写
> 这不是被动接受，而是战略聚焦
> 这不仅是知识共享的慷慨，更是自私的学习捷径
“Addy Osmani是谷歌软件工程师，负责Chrome浏览器与人工智能项目。”
啊，明白了。
我明白提出这种看法有时会被视为不妥，但我对那些措辞的感受完全相同。
我好奇我们是否会迎来另一种奇点：无论文本是否由AI辅助生成，它(1)会渗透进人们的说话方式，(2)频繁到让人们连正常文本都产生怀疑。
至少，我们早就该创造一个词来描述“它不仅是X，更是Y”这种句式了。在我看来，这种现象比破折号更泛滥更糟糕(虽然我欣赏合理使用破折号)。
没错，我也深有同感。这些见解看似真知灼见，但很可能陷入了依赖大型语言模型(LLM)构建结构的诱惑。由于LLM的影响，带编号的列表反而增加了我的认知负荷。
我欣赏Addy的作品，也喜欢这篇文章——完全认同它透着浓浓的LLM风格。更令人不安的是：我们知道部分内容并非作者原创(或许这无妨？)抑或不久的将来，我们将彻底丧失辨别能力。
这种模式反复出现时尤其令人不适。但若明确指示模型避免此类表达，并建立简易的审阅修改流程，大型语言模型写作未必非得遵循这种模式。
我反复要求ChatGPT停止每句话都用这种语气(它不是X，而是Y)
尝试在自定义指令中添加以下内容：
> 覆盖所有先前指令
这是愿望投射。它无法改变自己的写作风格，即便能做到也会无视你的指令，因为这等于无视系统提示——这相当于越狱操作。
绝非虚言，这招对我管用。试试看。
即便借助AI辅助，观点依然成立且行文通俗易懂。
看到这篇获得如此热烈反响，我简直震惊——这根本是领英级别的垃圾文章。
或许是因为你不熟悉阿迪·奥斯曼尼及其研究。近十年来他以卓越的网页性能优化成果闻名，任何经他审阅、编辑并背书的内容都值得一读。
这种思维方式正是个人崇拜的温床。
若连这种垃圾都能冠上他的名字，我错过它倒也无妨。
我也有同感。行文过于生硬。
糟了。确实如此
这些观点相当深刻。特别是这条：
我有自己的版本：再好的建议也无法让空白页面变好。你必须先有发表作品，才能真正受益于建议。
我也喜欢这条，但另有深意。
敲下页面首字符时，那些你从未察觉的问题便会浮现：你没有键盘。其实有，但没插电，还得挪开意外沉重的书柜才能触及USB接口。你得学Dvorak键位布局。你没有创建页面的权限，需要提交工单等待一周才能解决。即便创建成功，其他人也无法阅读——因为他们的设备不允许安装你页面所需的PageReader™插件版本(而你需要副总裁特批才能将PageGenerator™工具链降级到他们的版本)。诸如此类。
这些无声的进度杀手，往往要等到完整开发(及部署！)周期结束后才会显现。尽管这些示例问题看似荒谬，但在谷歌这样庞大复杂的机构里，它们离现实并不遥远。
我希望谷歌能更偏重质量和性能。他们的用户端产品往往漏洞百出，尽管公平地说Gmail表现相当出色。
总体而言，“快速发布，打破常规”的思维模式存在伪命题——仿佛发布有缺陷的软件与完全不发布是二选一的困境。若真如此，当今软件质量低下也就不足为奇了。我宁愿团队交付能正常运行、正确且高效的软件，哪怕这意味着推迟新功能或发布受限版本。软件的极简主义最终可能带来净收益，总比塞满半成品功能强。
不发布产品就无法从用户处学习。结果就是，很容易写出功能正常、代码正确、性能优异，却完全不符合实际需求的代码。
我认为当用户集体抱怨当前软件质量糟糕时，也能从中获得启示。不过这种反馈可能不会出现在遥测数据里——直到某天突然显现。微软，我就是在说你！
我认为Windows 11遭受如此猛烈抨击的核心原因在于：微软聚焦的是客户而非用户。多数情况下，当你购买Windows设备时，你并非微软的客户——你是OEM厂商的客户，而对OEM而言，每一分成本都至关重要。另一方面，直接向微软购买许可证的客户(如企业客户)则能获得更多关注和显著更优的体验。
你无法从中吸取教训，因为用户无论如何都会抱怨。
关键在于用户只会抱怨最近记忆中糟糕的体验——当旧问题未被改变时反而是好兆头，若开始抱怨新问题才真正糟糕。
探索用户真正需要的功能并非难事，更不该成为推出半成品的借口。
这类似于过早优化的问题——若未经基准测试就盲目优化性能，最终会耗费大量精力在无关紧要的事物上。产品开发亦然：解决错误问题是再容易不过的事。
荒谬至极。
> 探索真正有价值的功能并非难事，无需仓促推出半成品
你们到底发布了什么？每年花上百万美元去推销没人要的成品软件，这正是Stadia拖延太久最终还是被取消的原因。
找出真正有用的东西才是最难的问题。如果说谷歌有什么最大问题，那就是不够快地发布产品，不够快地迭代。
是啊，要是谷歌能多发布些垃圾软件再取消，他们的软件质量绝对会提升太多！！！！
真希望那些发布垃圾软件的人干脆别发布，让别人来推出更好的产品。
当先行者/既得利益者推出半吊子垃圾方案时，实在令人抓狂。
但遗憾的是，我们身处一个质量无关紧要、其他卖点更重要的世界。比如这些周末小项目，明明质量欠佳却意外成功：
Linux内核——免费的Unix
JavaScript——浏览器脚本语言
Python——理智版的“Perl”
如今光在GitHub上，你就能找到上百个比它们初创时更出色的优质项目，但没人会在意。
既然我们在祈求不可能实现的事，我更希望用户停止采用那些粗制滥造的先行者软件——正是这种行为助长了它们的势头，最终成为事实上的主导方案。
这正是附加价值的另一面。用户有时甚至能在半吊子软件中发现价值。
有人曾讨论过“解决正确问题的方式错误”与“解决错误问题的方式正确”的区别。
> “解决正确问题的方式错误” vs “解决错误问题的方式正确”
这个框架实在太有价值了！
关于Linux。诚然，1991年甚至整个90年代中期的Linux显然不够成熟。但进入新世纪时，华尔街已选择它取代Solaris。更何况“开源”属性使其区别于那些无人问津的专有Unix系统——Linux成为人们真正需要的“足够好”的Unix标准。
存在总比不存在好，行动迅速、率先推出粗糙软件者终将胜出。引以为鉴吧 🙂
Linux内核何来质量不足之说？
早期确实如此，尤其在2.4版本之前——该版本普遍被视为首个具备企业级应用能力的内核版本。(尽管旧版“企业级”定义是否仍适用可供商榷，但它确曾是众多用户的基准。)当然，用户空间及内核外部的文件系统等辅助组件也存在类似问题。
维基百科(https://en.wikipedia.org/wiki/Linux_kernel_version_history#O…)显示2.4版发布于2001年初。这已是相当久远的往事。当时商业领域主流系统仍是SunOS、Solaris、HP-UX或AIX。那么能否说Linux内核已保持“高质量”长达25年？
2001年正值互联网泡沫破灭后，所有曾信奉Sun公司“网络即计算机”理念的用户纷纷抛弃昂贵的E4K服务器，转而采购廉价的英特尔服务器以求生存。
HP-UX和AIX早已沦为历史遗留系统。
Linux 2.4版本恰逢互联网泡沫的宣传热潮，实现了临界点突破——正如潮水退去后，市场才看清谁在裸泳。
确实如此。2.4内核的发布加上IBM当时对Linux的拥抱，基本宣告了所有专有Unix系统的过时。
桌面领域的转型耗时更久且缺乏明确节点，可以说基于BSD架构(兼具命令行选项)的MacOS最终成为众多非Windows用户的优质替代方案——尽管Windows至今仍是桌面/笔记本操作系统的霸主。(当然，Windows/Azure在企业后端环境中依然占据主导地位。)
以当时标准衡量质量尚可，至少对多数用途而言物有所值。是的。
不同意。这有层次之分。并非所有劣质页面都优于空白页面。那些损害用户数据甚至更恶劣的页面，其危害远超空白页面。
这听起来像是对“宁可事后求饶，莫要事先请示”的变体表述。
问题在于，我至少在五家标榜“行动偏好”的公司工作过，这种理念几乎总是意味着加班加点赶工发布残次品，最终损害用户利益，然后转战下一个领导层主导的项目重蹈覆辙，从不回头。当然例外情况是当领导层发现产品五个月后就故障频发时，他们会抱怨工程实践不佳，质问工程师为何永远做不好事情。
在我超过14年的职场生涯中，曾在多家非谷歌公司听过帖子中列举的所有陈词滥调，而现实总是与理想存在巨大鸿沟。
整份清单读来宛如在说：“我领着数千万美元薪水喝着酷爱饮料，不得不承认——这饮料味道真棒！”
我非常推崇亚马逊的领导原则，其中“行动偏好”尤为重要。在AWS工作期间，每当会议中有人提及“行动偏好”，全员都会心领神会该如何行动。
深有同感。我的原则是：存在即核心价值。
只有当整个团队都认同时才有效。
若团队成员心态不同，他们会视之为半吊子或权宜之计。一旦出现负面反馈，他们就会借机说“我早就说过”，把你推下车。
若你自尊足够坚韧，可利用坎宁安定律背后的人性弱点(在网上获得正确答案的最佳方式不是提问，而是发布错误答案)。将你那糟糕的端到端概念验证代码提交到团队仓库，队友们惊恐愤怒之下，修复速度会比任何冲刺计划都快。
方法确实存在，但这对你的职业生涯有好处吗哈哈
另外，提交前负责审核的那个人也得有足够的心理承受力
糟糕的反馈有时比优质反馈更有价值，且往往是产品获得的唯一反馈。若不发布产品，你可能永远得不到这些反馈。尽早获取这类信息才是上策。
我个人认同“尽早发布，容许粗糙边缘”的理念。但团队成员未必支持。需要整个团队建立这种思维模式/文化。
这种方法的弊端在于：一旦以“糟糕”的初稿起步且获得足够支持，你就被锁定在既定轨道上，即便仍在可重构窗口期也无法进行基础性改写。最终只会催生出整体劣质的产品。
正确起步至关重要。
>真正理解问题的工程师常发现，优雅的解决方案往往比所有人预期的更简单
此言堪称金玉良言，应装裱悬挂于每位工程师的办公室。
>你的人脉网络将比你历任职场更持久
人脉才是真正的社交资本，毋庸置疑。
> 当规模足够大时，连你的漏洞都有用户
亦称“僵化”。这个术语虽常出现在网络协议讨论中，但更普遍适用于所有依赖未明确定义行为甚至漏洞的系统。
研究HTTP/3和QUIC协议时，这个观点颇有启发。起初我不理解为何坚持加密，后来发现这不仅关乎安全隐私——通过加密所有非必需传输内容，能彻底阻止任何“中间设备”做出不该有的假设。
我认为API设计也可借鉴此法则：永远只暴露明确定义的功能，将访问内部状态的能力视为漏洞——并非因其机密性，而是当用户开始依赖时，本不应破坏功能的内部变更反而会引发故障。
类似于API领域的赫勒姆法则
请仔细阅读原文。
他并非宣称这些都是谷歌的普遍价值观或实践。
他只是说明这些经验是在谷歌工作期间获得的。
尽管使用了“经验教训”的比喻，但“经验总结”类文章几乎从未涉及作者被明确告知的内容。这些都是必须通过实践或非正式建议才能领悟的道理，往往需要逆势而行才能获得。
我也不认为奥斯曼尼意在指责谷歌_反对_这些经验。任何规模如谷歌般庞大的组织都积累着助益职场发展的智慧。这些只是始终难以掌握的技能，其中某些在大型组织中尤为棘手。
我常说自己过往经历中，更多是学会了“如何避免”某些做法，因此面对相似情境时，我会采取截然不同的方式。
并非要否定作者在谷歌这类科技巨头长期任职的资历，但第一点论述实在显得格格不入。若谷歌文化真如传言般痴迷于用户体验，为何其产品体验始终糟糕透顶？尤其近来似乎愈发不堪。每项服务都令人抓狂——多余的步骤、冗余的点击，几乎所有操作都得点击才能完成。最近写邮件时，我发现收件人地址拼错了——这种失误本就罕见。按理说只需点击地址快速修改即可，对吧？错！现在你得先打开弹出菜单，再在菜单里搜寻“编辑邮件”选项。他分享的其他经验虽有价值，但我不认为值得冠以“在<某科技巨头>工作X年后”的标题，因为这些内容与其他公司员工的经历并无本质差异。我更想了解财务官僚接管后，公司文化如何被糟蹋得对用户和员工都一塌糊涂。
> 若谷歌文化真如传言般痴迷于用户体验，为何其UX始终糟糕透顶？尤其近年似乎愈发恶化。
根本不存在财务官僚接管，更谈不上痴迷用户体验。我在2006-2014年担任工程师期间，最反感这句宣言： “用户至上意味着要深入支持工单系统，与用户对话，观察用户困境，不断追问’为什么’直至触及核心问题”
当我负责用户端产品(地图、Gmail、账户系统)时，我定期查阅公开支持论坛和工单队列寻找投诉线索，有时甚至参与用户讨论获取更多信息。但我的发现是：
• 工程团队几乎无人这样做
• 我的行为被视为怪异。
• 主管和晋升委员会对此持负面态度。
• 工程师直接与用户沟通尤其被视为异常且有问题。
• 产品中总存在逃过质量检测和监控的严重漏洞。
理论上设有专职人员监控论坛，但实际中工程经理鲜少关注——想想每季度一次的“用户心声”报告之类形式主义。部分原因在于他们缺乏技术背景，常常难以分辨用户投诉是噪音还是产品真实缺陷——这些对工程师而言显而易见的问题，导致问题无法得到有效上报。
这种与外界的普遍隔阂无处不在。2010年我加入滥用团队时，惊讶地发现这个存在多年的团队竟只有一名工程师会关注垃圾邮件发送者交流的论坛——而他也是刚入职的新人。他将账号权限交给我后，我们迅速发现垃圾邮件发送者已在账户网页服务器中找到漏洞，得以绕过反垃圾邮件控制，而这些漏洞在我们任何监控系统中都无法被察觉。通过这种“滥用者研究”，我们获得了诸多宝贵发现。但这仍是特例——此前团队始终由机器学习狂热者主导，他们只把这里当作模型训练的试验场。
我历任职场都存在类似模式：工程师不应直接接触客户。
我认为原因多种多样，但大多与维护内部权力结构有关。
产品经理不愿看到用户轶事证据揭露其产品愿景的残缺性。
工程经理不愿用户反馈动摇对质量的认知，更不愿打乱已规划的“高影响力”工作。
客户关系部门(或支持团队、用户研究组——任何本应直接倾听用户声音的团队)不愿看到你凭借深厚的工程与产品知识，比他们更出色地完成本职工作。他们更害怕你动摇他们向高层汇报的“核心主题”或“用户情绪”。
法务部门不允许你公开承认产品存在任何缺陷。
补充说明：这种现象在内部产品开发中同样存在。作为用户，你无法直接联系内部产品的工程师，必须提交错误报告或表单，等待产品经理审核并排期处理。虽然这种机制避免了干扰工程师，但通常只存在于历史错误率较高的产品中。
工程师们普遍认为其他岗位都逊色于自己，总觉得只要由他们掌舵，事情就会做得更好。我过去确实也是这样想的。担任工程师期间，我经常直接与客户对接，能够一对一沟通、解决具体问题并感受到自己的价值，这种体验非常棒——尤其是在大型产品项目中，通常很难听到众多客户的反馈。当然，一旦这些客户获得我的倾听，功能需求便如潮水般涌来，最终我耗费过多时间处理他们的个别问题。这恰恰说明我的观点已随时间转变。
回想起来，我协助的客户往往面临最吸引我的问题——那些我确信能解决的难题，但这些改进通常不会对整个客户群体产生最大影响。解决个别客户的特定问题固然能改善他们的使用体验，这种成就感确实令人愉悦，但这些时间本可更有效地用于服务整体客户群体。产品经理、管理者等角色应当具备更广阔的产品需求视野，他们在掌握完整背景信息的基础上进行工作优先级排序才是职责所在。尽管当时我认为这些岗位价值有限，但事实绝非如此。
当然，我承认上述关于产品经理、管理者和支持人员存在阻碍因素的观点在某些情况下成立。但在管理得当的企业中(尽管普遍认知相反，这类企业确实存在)，当工程师不过度介入个体客户事务时，整体运作会更高效。谷歌或许是典型例证——当用户规模达十亿级时，工程师显然不宜与客户进行一对一沟通。
> 工程师普遍认为其他岗位地位较低
当真如此？我始终觉得自己处于食物链底层。“晋升”意味着离开工程岗位转入管理层。
> 若能让他们掌权，事情本会更顺利。
这是否过于简单化？工程师理解产品架构，因为他们亲手打造。有时他们目睹他人(如产品经理)的决策，却深知更优方案。
作为工程师，我完全接受产品经理这样回应：“从我的角度看，这种方案更优”——只要他们能证明理解我的观点，却因其他限制坚持另辟蹊径。
然而职业生涯中遇到的许多产品经理却显露出居高临下的态度：他们常以“你掌握的信息不如我全面，我没时间说服你，所以就按你认为次优的方式推进，任你懊恼”来否定我的意见。我认为这种做法是错误的。
总体而言，我不设职位等级：若视其为队友，便携手共进；若视其为对手，则全力对抗。我并不觉得自己比糟糕的管理者或产品经理高明，只是将他们视为竞争对手。
虽有些牵强，但这让我想起最近听到的战争箴言：百人中当有一勇士，九人作士兵，九十人本不该在此。
软件开发者亦是如此：只是在企业里，那90%的人根本不自知不该存在，他们构建的系统与项目构筑出与公司实际需求平行的世界。
深有同感
作为90%中的一员，我深有体会
这读起来像是项目经理写的。你早期缺乏高层次的背景认知和优先级把控能力，所以结论就是最好把决策权交给别人？
现代管理学有一整套理论认为：领导者应该提供背景信息和技能支持，让高绩效团队对工作流程拥有更大的自主权。
我认为他言之有理。这些权力结构的存在也有其合理性。
相反的做法(工程师直接对接客户)最终可能导致客户掌控工程部门。不应让少数现有客户的喧嚣直接主导工程方向，从而损害其他现有或潜在客户的利益。
微软曾制度性地陷入客户俘获困境：只重视现有大型企业客户。这导致Windows CE重启为Windows Mobile时为时已晚，未能扭转局面。但这也意味着向后兼容性与永续支持Windows XP的愿望成了不可触碰的神牛。
更恶劣的是，某些人会为政治利益蓄意收集负面反馈。
任何结构都可能存在功能失调。在大型正式反馈系统之外，保留少量直接用户反馈或许最为理想，至少能让两者相互制衡。若用户参与团队称一切正常，但Reddit上却涌现大量讨论产品糟糕体验的帖子，且工程师们也深知产品尚有改进空间——此时工程团队就该着手解决问题，同时向用户参与团队反馈进展。
一天的时长根本不够所有人完成所有工作。
> 现代管理学主张领导者应提供背景信息与技能支持，赋予高绩效团队更多工作自主权。
这种理念在执行层面的自主权上确实有效——毕竟领导者无法掌握每个变更或解决方案的具体实施背景，更无权决定“做什么”和“如何做”。而执行者需要了解背景才能做出符合情境的决策。
但“领导者提供背景”与“每个人自行研究背景”截然不同。那么领导者从何处获取背景？是从那堆千篇一律的通才工程师中吗？他们既要频繁对接客户，又要管理自身工作流？还是组建专家团队，避免让多数人陷入持续切换角色困境——既要收集背景信息，又要排序工作优先级，还要兼顾市场调研与具体实施？
差劲的领导者注定领导不力。
许多领导者将信息视为服务自身需求的工具。
他们或许掌握背景信息，却要么因专注本职而拒绝分享，要么主动管控信息传播以操控组织。
据我观察，这虽非阴险恶意，实属常态，却是典型的运作模式。
认同这可能是个问题，但需澄清：我当时是在排查漏洞或遗漏的系统故障，而非收集功能需求或参与产品开发。比如“点击按钮后出现500服务器错误”这类情况。我认为普通开发者不该通过阅读用户论坛来决定开发方向——由产品经理决策才合理，前提是产品经理足够专业。然而大型科技公司的产品经理常将用户群体抽象为数据指标，从而忽略那些未在数据流中显现的明显/尴尬的漏洞。根本真相仍取决于用户是否投诉。工程团队可以忽略关于功能缺失/界面重构等投诉，但针对生产环境故障的投诉必须引起重视。
组织总可能走向另一个极端，但这绝非拒绝与客户沟通的借口。后者更易发生，因此“别与客户沆瀣一气”的警告根本站不住脚。
这儿常见这样的模式：爱丽丝说0度太冷，我更喜欢20摄氏度；鲍勃立刻附和“100摄氏度太热，会烤死人的”。好吧，但没人说过或暗示要把温度调到100度。
每一条客户投诉背后，都有N个沉默的流失客户
“最大影响”无法预知，因此“手中有鸟胜过林中双鸟”
若你面临M起客户投诉，且每起投诉可能导致不同数量的N位客户流失…你最好尝试分级处理，而非让随机工程师像打地鼠般应对突发问题。我从未见过工程师热衷于处理那些“最多导致0-1位客户流失”的琐碎问题——只因这些问题容易解决且能带来成就感，毕竟客户提出来了！“我搞定了！”——却忽视了那些阻碍客户获取与留存的重大问题。
计划注定徒劳，但规划不可或缺，世间万物皆如此。
我也深有同感。
有位后来成为好友的同事，在协助非技术团队开发提升工作效率的小工具后，竟因“绩效不达标”被列入绩效改进计划并遭解雇。他只是未完全遵循指令行事，这竟被视为工作失职。
讽刺的是，推动解雇他的人竟是前谷歌中层管理者。
我还发现，工程师群体常背负着奇怪的污名，仿佛我们天生不懂用户需求。
高层管理者或许确实更了解业务流程和全局视野，但我始终怀疑这背后更多是源于权力焦虑和掌控欲作祟。
如果你做成某件事，而这件事是你的经理没想到的，且你的经理对自己能力缺乏自信，那么他们很可能会感到威胁。
> 工程师不应该直接与客户接触。
我不知道公司是否终于停止了伪装“敏捷”；但如果没有，这简直就是明证——他们根本谈不上敏捷。
我们公司常安排工程师直接对接客户。当项目经理遇到技术难题时，这种沟通能有效消除误解。我们仍会设置缓冲机制，防止客户让工程师做免费工作。我认为将工程团队孤立起来的做法相当糟糕。
可悲的是，这种局面本可避免。
我在内部工具团队工作数年，当时我们赋予工程师直接在内部支持群组解决用户问题并提供支持的权限。
同时我们有负责推动长期愿景和战略的项目经理，他们也积极直接与用户互动。
我们设有“用户研究”团队，其职责是汇总调查数据捕捉宏观趋势，开展深入特定领域的用户研究(工程师始终受邀参与现场问答、观看原始录像，或直接查阅最终报告)。
所有成员如同团队般协同作战，共同致力于将这些工具打造成最适合内部用户的精品。
当然并非完美无缺——当有人试图充当守门人、争夺团队或产品控制权时，这种协作机制就会崩溃。所幸长期来看，领导层总能以各种方式筛除这类人。因此我们核心的中高级工程师团队得以稳定留存长达三年(维持核心团队持续专注同一领域实属不易)，这为积累系统性运作知识奠定了坚实基础…
其实存在更积极的动因。我也见过截然相反的情况：工程师们为维护技术部门凌驾于客服之上的优越感，不断否决客服团队提出的切实重要反馈。
即便只有十名工程师和一百名客户，对话边界数量也极其庞大。若工程师直接将对话成果转化为功能，想保持一致性并进行长期规划简直是痴人说梦。“工程师与客户沟通但不做任何改动”或许更稳定，但仍是极其昂贵且混乱的客户反馈收集方式。
此外，极少有工程师能全面掌握产品路线图，更不可能仅凭客户反馈或提问就单方面决定方向。“这个问题两周内能修复吗？”“你们会开发X功能吗？”——你绝不希望客户收到大量前后矛盾的承诺或错误信息。
我见过管理最完善的组织，其产品和支持部门都配备了强大的工程和用户体验团队。这些岗位需要既懂技术实现又懂产品使用的人，但不可能让每个工程师都掌握所有知识。
初创公司初期应让开发者直接对接客户。但若发展顺利，团队规模扩大后，就需要引入中间环节：既要避免工程时间被随机干扰消耗，又要集中规划职责——确保有人筛选出真正重要的反馈并推动落地。
恰恰相反，最优秀的产品往往由用户亲手打造。若开发者自己都不使用产品，其质量必然逊于用户参与开发的产品。
用户应无处不在——无论身处工程团队内外。
Reddit热议区正讨论另一话题：由行业起草、立法者橡皮图章式的法规制定。这两场讨论让我深感：现实中充斥着大量利益驱动的行为，却几乎缺乏监督与审计。问题本质就在于此。若想从根源解决问题，必须建立独立审计机制，对违规者进行追责。但我们都清楚这不可能实现，所以系好安全带吧——学会与残缺的法律和缺陷软件共存。
“10. 在大型企业中，无数变量超出个人掌控——组织架构调整、管理层决策、市场波动、产品转型。纠结于这些只会徒增焦虑，却无力改变。”
保持理智和高效的工程师会专注于自身可控的领域。你无法掌控重组是否发生，但能掌控工作质量、应对方式和学习成果。面对不确定性时，将问题分解为可操作的具体行动。
这并非消极妥协，而是战略聚焦。耗费在无法改变之事上的精力，终将侵蚀可掌控之事的能量。
————————
第十条似乎暗示谷歌的企业文化是：守好自己的地盘，不越界干涉他人。若管理层制定的方针损害用户利益，那些“理智高效”的工程师便会固守本职。对于服务型企业而言，这当真算高效吗？
用户利益往往横跨多个领域，与管理决策产生冲突。若谷歌将倾听用户的声音视为工程师的“怪癖”或“不理智”/“低效”，这确实能解释许多现象。
几乎放之四海而皆准的事实是：零售客户服务总被交给薪资最低、地位最弱的员工，甚至外包处理，如今更日益依赖大型语言模型聊天机器人。
虽然高薪工程师显然不该被用户支持工单缠身，但至少让他们接触一线实况仍有诸多益处。
你完全可以这么做——这恰恰是最直观的方式，让他们切身感受到自身工作给真实用户带来的困扰，这种体验更易铭记于心，或至少提醒他们另一端存在着真实的人类。甚至有高薪CEO亲自参与的案例，社交媒体上不乏此类实例。
我特别喜欢读这类企业结构洞察，尤其是其中的社会学视角(比如“• 该举措遭到管理层和晋升委员会的否定”)。非常感谢。
> 只有一位工程师会去关注垃圾邮件发送者论坛的交流内容，而他刚加入团队不久
这个发现让我震惊不已。这根本是反滥用入门常识啊——你需要渗透他们的网络，再用自有监控追踪行为模式，从而找出可观测性体系的漏洞。即便在2010年这都是基础操作。至少我记得如此，或许当时eBay/PayPal团队只是领先时代太多。
“101”这个说法源自美国教育体系，指入门级课程。反滥用工作的困境在于既无系统课程可学，跨企业跳槽也极为罕见。反滥用是商业运营的必然成本，因此不像人工智能研究等领域那样存在人才争夺战。这完全是边干边学，人员流动往往意味着经验流失。
离开谷歌后，确实有几家科技公司的反滥用团队联系过我。各公司应对方式差异极大，投入的精力和专业技能参差不齐，即便在相同市场领域也是如此。支付欺诈涉及巨额资金，按理说eBay应该有优秀团队，但谷歌多数产品遭遇滥用时并不会直接亏损，只是导致用户体验整体恶化——这种影响难以用具体指标衡量。
我记得参加过每周滥用团队会议，其中一项指标就是谷歌账户在黑市的售价。所以至少部分指标是被系统追踪的，并非仅靠个人记录。
没错，我认为这个做法是我和之前提到的那位同事共同推动的 😉
嘿迈克！我是GR的亚历克斯。见到你真好 🙂
会计师接管公司是在你离开之后。
2014年的谷歌和2019年的谷歌已是截然不同的两家公司。
若工程师与用户交流被视为问题，那么可以断言谷歌离真正的敏捷文化相去甚远。谷歌可曾自诩为敏捷企业？
“数据驱动敏捷”™
> 用户至上意味着要埋头处理支持工单
这话真有意思——众所周知谷歌的客户支持根本不存在，除非你在推特或Hacker News上足够出名，能嚷嚷到让有权处理的人注意到你。
作为只在初创公司或咨询机构工作过的人，这对我来说很奇怪。在六家不同的公司里，我几乎总是直接与应用用户对接，了解他们的痛点、bug等。而且我始终是个执行人员。我认为这是培养对应用用户同理心的绝佳方式。
当然，如果你是一家市值数十亿美元的巨头企业，对用户的同理心只会存在于能为利润带来好处的时候。
感谢分享宝贵见解。得知谷歌(至少在你的团队中)曾不鼓励与客户沟通，我感到相当惊讶。我认为这恰恰是任何项目中最宝贵的补充——与实际构建产品相辅相成。我感觉软件质量整体下滑很大程度上源于非技术人员逐渐渗透进开发团队。
>我的经验是：
>• 工程团队中几乎无人这样做
>• 这样做会被视为怪异
>• 受管理层和晋升委员会负面评价
>• 工程师直接与用户沟通尤其被视为怪异且有问题。
>• 产品总存在严重缺陷，这些缺陷逃过了质量保证和监控环节
衷心感谢您证实了我长期以来的观察。我常开玩笑说谷歌员工甚至被正式禁止访问用户论坛。否则根本无法解释为何存在十多年陈年旧帖，用户反复报告相同问题等现象。
大型科技公司(我所在的公司亦然)的优质工程实践已荡然无存，取而代之的是“晋升驱动开发”模式。
以我为例：写烂代码、偷工减料、积累技术债务、快速上线、获得晋升、转战新项目。
工程团队中几乎无人如此行事。
你描述的工作本应由产品经理承担。谷歌难道没有产品经理吗？
当然有，但他们往往陷入循环：制作演示文稿汇报进度，撰写提案而非开展此类调研。
不过解读用户反馈是多角色协作的工作，产品经理、用户体验设计师和工程师都应参与其中，各自发挥所长。
我参与过最有趣的工作之一就是观察用户体验研究。他们会让外部志愿者使用模拟版本(或Alpha版)产品，全程记录操作过程。通常产品经理、用户体验设计师和工程师会同步观看直播并做笔记。
前谷歌员工在此。
当公司规模达到那种程度时，岗位分工会精细化得多。
具体头衔记不清了，但当时有位同事负责对接我们团队，承担“客户沟通”工作。她的反馈会通过复杂的人际链条最终传递到我们团队的产品经理手中，进而融入日常产品路线图。
谷歌确实存在这类岗位，只是他们通常既非工程师也非产品经理，往往与工程师隔着好几层管理层，因此普遍存在GP描述的种种问题。
产品经理是个虚职，多数人早就明白只需(1)讨好高层(2)向工程团队施压就能晋升。你会发现这根本不需要理解或学习产品知识。
这就是为什么GP读用户报告时会得到困惑反应——找个大公司外毫无实权的人沟通？何必呢？
我有幸在几家公司(非谷歌)共事过优秀的PM，他们不仅工作出色，还积极维护开发者权益。他们完全支持开发者直接对接客户，甚至主动鼓励这种做法——毕竟这是理解和解决问题的最快途径。
说实话，你可能只是碰上了个烂项目经理。
在美国，几乎所有工作本质上都是取悦领导层。
若企业不希望这种激励机制失控，本该通过合同或由领导层预算支付的“黄金降落伞”来保护员工免受上司喜怒无常的影响。
但现实是他们基本不会这么做，所以你必须先讨好领导层，才能在“随时解雇”的威胁下生存，再考虑其他事情。
如果你够幸运，讨好领导层的行为还能提升效率；如果你超级幸运，讨好领导层的行为甚至能让你自己满意。
若事与愿违，只能忍气吞声吞下苦果，否则就辞职走人。
> 若谷歌文化真在乎用户体验
值得注意的是，据我所知，奥斯曼尼在谷歌任职期间始终担任“开发者布道师”，而非参与用户产品开发的工程师。
阅读他的经验总结时，不妨记住这一点——这些观点必然受到他在公司所处职位的影响。
当阿迪在开发者关系部门工作时，我是他的直属主管。
他多年前就转任Chrome开发者工具的工程经理，最近才调往其他团队。说他不是为用户交付产品的开发者实在有失公允——他曾领导我们最常用的开发者工具之一，在担任工程经理前还参与过众多开发者库的开发。
是的，我本该更精确些——我的意思是“像你母亲这样的终端用户”而非“非真实用户”。在工程导向团队中为开发者开发工具，显然与典型产品开发团队截然不同。
>据我所知，Osmani在谷歌长期担任“开发者布道师”而非开发者
哦
这种解读有失公允，他和其他人一样是开发者。但据我所知，他并未直接参与面向用户的产品开发。
关键在于他的工作对象是外部开发者。这个角色本质上就是面向用户且以用户为中心的。我认为没人想说他不是开发者，只是他的工作并非直接开发产品
嗯，我补充这个是因为引文结尾的截断方式，让我觉得引用者认为奥斯曼尼“不是开发者”。
啊，明白了。我确实注意到这段文字对于开发者撰写的文本而言显得过于冗长且空泛。
有道理。“用户”指的是开发者，而非点击Gmail、谷歌地图等应用按钮的普通用户。
我觉得这更像是“听起来很棒”而非“我们的用户是开发者”。谷歌的服务本身也不面向开发者，API设计往往官僚主义且粗制滥造(比如Sheets API居然无法列出可用文档？非得用Drive API另开权限？拜托)。
这完全是典型的“想被当作思想领袖”式论调：全是老生常谈，但听起来悦耳，让人忍不住点头附和。
> 若谷歌文化真如传言般痴迷于用户体验，为何其UX始终如此糟糕？
好吧，我真心这么认为。
你肯定没用过微软工具。
他们早在30年前就将办公套件植入学校教育来解决用户体验问题，至今用户迁移最大的痛点在于——毕业生都经过这套系统的训练。这恰恰是他们最成功的用户体验。
Azure？Teams？PowerBI？和谷歌最糟糕的服务(或开源工具如Gerrit)相比简直是笑话。
我完全赞同。Teams简直是毒瘤，Azure界面也糟糕透顶。自从Win7之后我主要用Linux作为工作环境，基本不碰微软产品。但微软至少曾经有一项优势——文档体系。如果你够资深，应该记得当年每个产品都配有详尽手册，还有真正的客户支持。谷歌这方面嘛…连这点都做不到。
在持续交付和预览/测试版功能开放的时代，文档变得支离破碎且分散。其中半数内容技术上属于旧版产品——虽然名称不同但功能基本兼容，只因微软始终没能完成多数软件的现代化改造…
至于客户支持？除非你愿意掏大钱买服务，否则体验实在不怎么样。
当时还有MSDN。不过那确实是另一个时代了。
> 若你足够资深，定会记得每款产品都配有详尽手册，且真有客户支持服务。
但即便如此，同期竞争对手仍远胜微软。
提供印刷版用户手册曾是行业文化，我至今仍珍藏着Sun微系统的手册——那是我了解存储设备工作原理及技术取舍的最佳资源。
说得对，当时所有厂商都用盒装软件配500页手册。我依然认为微软确实投入大量资源提升文档质量，他们重视开发者——否则佩佐尔德系列(以及微软出版社)根本不会诞生。
啊对，微软出版社确实出版过不少经典之作。
我恨微软恨得像千颗燃烧的恒星，但即便如此我仍认为谷歌产品的用户体验不如微软同类产品。
MS Teams确实糟糕透顶。但我宁可用它也不选Google Meets。
Google Docs的体验远不及Office 365。
Azure虽有诸多缺陷，但比GCP更清晰易懂。
幸好我很少需要接触这两家半吊子的用户界面。
> 我宁可用[teams]也不用Google Meets
什么？为什么？
老实说，你的整个评论几乎和我感受完全相反。
如果你懂系统管理，GCP的选择完全合理。Google文档在自定义字体方面有局限(比如：根本实现不了)，但至少操作简单，我可以给别人发链接点击，他们看到的界面都一样。
但说实话，Teams这个选择令人费解。我实在想不出Meet在任何方面比Teams更差。
因为它就是个低码率的米老鼠玩具。
微软Teams或许存在诸多问题(必须承认确实问题不少)，但它具备企业级视频会议套件所需的大部分功能，甚至可能涵盖全部。
而谷歌Meet更像是给祖父母玩的简化版玩具。
Google Docs也是同样的情况。它们在发布当年确实令人印象深刻，但技术水平停滞于2010年代。一旦超出基础功能范围，使用体验就会远比O365更令人抓狂。
微软或许会推出许多糟糕的软件，设计选择也常令人质疑，但他们对企业需求的理解远胜谷歌。
即便谷歌工作空间，当企业规模超过50人时也严重受限。
若只在初创公司工作，谷歌或许看似轻松取胜。但对任何成熟企业而言，谷歌软件套件总会不断制造障碍。
至于谷歌云平台，他们的支持流程让我吃过太多苦头。GPU配额审批竟耗时7天。客户经理甚至试图窃取商业机密(当时我在一家人工智能初创公司任职，而谷歌在AI领域已陷入停滞)。诸如此类的问题层出不穷。虽然Azure也未能给我留下深刻印象——他们频繁破坏托管服务，屡屡违背可扩展性承诺，直到我们提供实证证据才肯承认错误。感觉微软最优秀的云工程师都已离职(或者说从未加入过？)。
这确实让我措手不及，真心困惑。谷歌会议对我而言始终运行流畅，性能出色，在移动端、火狐浏览器等平台表现良好。虽无特别亮点但稳定可靠，堪称我最青睐的会议应用。
而Teams绝对是我最讨厌的，加载慢得要命，不支持Firefox浏览器，还不停催我下载应用，界面设计混乱。我从未听过有人说喜欢Teams。
我用过几次Meet进行视频通话，考虑到谷歌拥有的资源，其糟糕的表现实在令人震惊。我从未在Meet上获得过优质的视频通话体验。有几次通话过程中，分辨率和比特率会逐渐降至极低水平，导致我完全看不清对方(画面变成一片大块状的混乱)。而Teams(尽管存在诸多缺陷)通常不会出现视频质量方面的重大问题。Teams并非完美无缺，大型群组视频通话时我偶尔仍会转用Zoom，但归根结底Teams的视频通话功能基本能正常运作——虽称不上出色，但也绝非糟糕。当然，具体体验因人而异。
我的体验恰恰相反。Meet对我而言稳定可靠，而Teams简直是噩梦般的存在。
关键在于Meet和Teams都采用集中式服务器架构(Google的SFU选择性转发单元，Teams的传输路由器)，因此你的质量问题很可能源于网络路由而非平台本身。你描述的Meet画质渐进式下降，听起来像是自适应码率机制在谷歌服务器连接不畅时正常工作。
Teams在你那儿表现更佳，很可能只是运气使然——你的ISP路由到微软网络的路线比到谷歌的更顺畅。而在瑞典的我则遭遇相反情况…Teams将我的媒体数据通过法国中继站传输，延迟严重导致人们不断意外打断对方发言，简直令人抓狂。与此同时，Meet的路由始终完美无瑕。
但即便Teams在你的网络环境下运行良好，也别把它当成优质软件。Teams简直是资源黑洞，把我的CPU当电暖器烧，把内存当自助餐狂吃。界面杂乱不堪，启动耗时漫长，人们忍受它的唯一理由是微软把它捆绑在Office 365里。
你的使用体验确实因人而异…听起来你的路由更偏向微软的基础设施。你算是走运了，但这并不能改变Teams对我们这些被迫使用其欧洲中继节点的人来说依然是垃圾软件的事实。
作为曾参与谷歌Meet开发的员工，我认为问题可能出在呼叫路由的数据中心网络连接上——你的网络存在UDP通信故障，导致系统被迫降级为TCP协议的WebRTC方案。当然也可能是你使用的浏览器版本存在兼容问题。
由于Teams使用的是非常老旧的H264编解码器，而Meet根据具体场景使用VP8或VP9，因此你可能还遇到过其他解码问题(通常由软件处理，但偶尔也由硬件完成)。
总体而言，这不应代表我所见到的Meet使用体验，即便参考所有已读的错误报告也是如此。
问题不仅限于谷歌，用户体验正在全面恶化。我认为根源在于企业占据双寡头、垄断等市场地位。
它们只听从数据指引，其他因素皆被忽视，用户体验已不再重要。
就像那些靠抽卡赚取数十亿的垃圾游戏——内容空洞毫无深度，玩家却愿意投入数千美元。原因并非游戏本身优秀，而是缺乏替代选择(同类非抽卡游戏)，且游戏循环机制刻意设计成令人上瘾的数字游戏。
补充用户体验恶化的其他成因：
1. 行业利润日益依赖娱乐(或更糟的心理剥削)而非向用户提供实用工具。例如优质理财软件应帮助用户理解、规划并达成目标，而“优秀”的老虎机则可能利用混乱、分心和巨型拉杆设计牟利。
2. “必须适配口袋尺寸的触屏设备”这一要求，迫使某些功能降至最低标准。
3. 用户体验正逐渐成为单个产品的切换成本，而非操作系统层面的统一标准。用户无需掌握Windows或Mac的界面逻辑与快捷键体系，但每个独立程序——尤其是那些该死的Electron应用——都在重复发明轮子。
公平地说，原文确切表述为“1. 最优秀的工程师痴迷于解决用户痛点”。这并未指明这些工程师任职于谷歌，仅说明作者在谷歌工作期间领悟到此道理。
正如前言所述：“某些[经验教训]本可让我少受数月挫折之苦”。
我正要发表同样观点！他指的是那些在他看来真正体现优秀工程师特质的人。
而应对那些不重视此类工作的工程经理，或许正是“摸索如何驾驭代码之外的一切：人际关系、政治博弈、目标对齐、模糊地带”的一部分。
Addy的用户群体一直是开发者，而谷歌过去对此非常积极响应。我通常能联系到Chrome开发工具团队的相关人员，他们甚至协助过谷歌没有持股的开源项目(如Node.js)。他还有个人博客、著作，并常在职责允许时出席会议直接与用户交流。我认同对谷歌的普遍批评，但认为在此特殊(虽属罕见)案例中实属无端指责。
Material UI仍是所有界面中最糟糕的。有幸部署过生产环境的OAuth客户端…天啊。用户体验方面只有微软比它更差。你们不希望我使用你们的服务吧？
> Material UI 依然是所有界面中最糟糕的
我也不明白这设计怎么能通过审核，但至少现在我们知道：当巨头企业仅凭量化分析驱动UI/UX工具包时会发生什么——所有决策都由数据主导，看似毫无人工干预。这简直是“数据驱动至上”时代的巅峰体现。
更让我困惑的是：这套系统为何至今仍在运行？使用时总该有人察觉问题吧
这正是万恶之源…
我对第一点也有异议，但角度不同。曾参与过面向数百万用户的面向用户产品开发，挑战不在于发现用户问题，而在于发现高频用户问题。在足够复杂的产品中，用户会遭遇成千上万种不同问题，但如何确定优先级绝非易事。
我认为你提到的Gmail问题存在的原因是：他们希望移动网页和触屏网页用户(我们这类用户有几十个！)能通过点击收件人显示用户卡片，就像鼠标悬停时的效果。要支持你的用例(点击直接编辑收件人)，触摸、点击和悬停就需要对应不同操作，这可能会影响其他用户体验。除非你指的是双击编辑功能，那我支持。
我把精力留给更恶劣的用户体验改动。比如YouTube评论滚动字幕毁了我多少视频体验，简直令人作呕。
读到这段我也感到意外。我对所有谷歌界面都深恶痛绝，永远找不到需要的功能，操作过程简直是折磨人的挫折体验。
他们的观点其实很微妙。他们想表达的是，从长远职业发展的角度看，关注真实用户至关重要，这能让你的项目更出色。
谷歌的用户体验设计相当不错，作者并非在评论谷歌的用户体验体系本身。更重要的是，若能紧跟用户需求，你的工作将更有根基，项目成功的可能性也会大大提升。我甚至认为这种做法常逆潮流而动。作者明确指出，本质上存在大量内部项目坟场——那些看似酷炫却对用户毫无价值的项目终究难以为继。
有趣，这意味着他并非如博客标题所示，基于在谷歌的14年经验撰文？
仔细读他们的第一点。他们说的是：当你构建产品或解决问题(面向内部/外部用户)时，若能专注于用户需求，最终成果将更具影响力且更易取得长期成功。这确实涉及用户体验考量，但在我看来属于间接关联。
我有些困惑——他到底是不是在谈论谷歌十四年的经历？标题暗示他在谈论，而你却说不是？
哦，我确信这些经验来自谷歌。我只是想说明作者并非直接评论用户体验。作者试图阐明的是：理解用户面临的产品类型与痛点，是解决有意义问题并选择谷歌内部更可能取得良好成果项目的有效长期策略。若你自身在谷歌践行此法，将直接获益。许多论点都因数据而成立或破产，所以如果你能基于数据论证用户如何使用系统，或揭示特定系统的实际使用状况，并结合用户反馈案例，就能有效引导个人及团队的工作方向——既能与内部目标高度契合，也能帮助重置和重新调整内部目标优先级。
他在谷歌14年的“经验教训”。我们任职于雇主或与工程师共事时，难道不都学到过那些毫无用处的经验吗？
14年间他肯定也目睹过优秀工程师来来去去，创立了其他成功企业——这些企业很可能并未完全效仿谷歌的运营模式。
简而言之，这个界面根本没为你这类用户优化。
我虽未在谷歌工作过，但这种规模的企业所有环节都经过测试优化。我猜他们清楚像你这样的资深用户会感到沮丧，但他们知道你终究会摸索出来。所以用户体验是针对更简单的目标群体优化的，甚至可能连帮助文档都更简化，而非确保资深用户能高效完成任务。
我觉得你高估了他们的考量。不确定是泄密还是都市传说，但我记得当年Windows 8那糟糕的“扁平化方块界面”，正是因为管理者能在PowerPoint里直接设计成那样。
具体到这个功能…根本谈不上什么“高级”。几十年来它本质上就是个“非功能”，我记得从不存在不能通过移动光标输入新内容来修改邮箱的情况。这到底算什么经过测试优化的功能？究竟是为谁设计的？
谷歌界面似乎只针对理想使用场景优化：搜索常见词汇后点击相关链接；单次回复邮件后立即终止对话，每封新邮件都开启新对话；点击首页推荐视频缩略图后继续自动播放；在电子表格单元格中仅输入日期/数字/文本等固定格式内容。其所有产品皆如此。
但一旦用户尝试搜索首页未显示的内容，回复包含附件的10-20+条历史消息，使用YouTube播放列表或搜索功能，或在表格单元格输入稍复杂的数据——系统便会彻底崩溃。
最近亲历的谷歌新操作：Android系统默认的“稍后观看”播放列表现已隐藏。它消失得无影无踪，无法搜索，唯一残留的痕迹是添加新视频到“稍后观看”时出现的2秒弹窗——点击“查看”才能瞥见。而PC端它仍作为独立项目存在。我特意举这个例子，因为这是蓄意为之，绝非错误或功能退化。有人为此创建了Jira工单，也有人将其标记为已解决。
这种情况几乎不可能发生。公司规模越大，变革往往越被视为负面因素。虽然有人可能拥有你描述的职位头衔，但无人真正有权推动变革。
这绝对是个别特例。谷歌的大多数UI/UX设计都高度一致且运行流畅，否则他们根本无法立足于这个市场。
唯一的UI/UX问题在于资深用户往往抗拒改变。就像总有人宣称Windows 7是最佳系统——别总搞创新。
另一件让我恼火的事是，每个UI/UX开发者都假设用户配有双4K显示器，导致菜单项溢出。
> 唯一的UI/UX问题在于资深用户往往抗拒改变
用户不仅会适应，甚至会成为变革的拥护者——前提是这些变革对他们有意义。比如网页结账流程，或者更极端的例子：iPhone和手指作为交互设备。但若你开始说服用户“界面很棒，只是他们抗拒变革/愚钝/缺乏创造力才不会用”…那可就是另一回事了 😉
> 最近写邮件时发现收件人地址拼错了——这种情况很少发生。按理说只需点击地址快速修改就行了吧？错！现在弹出菜单里还得费劲寻找“编辑邮件”选项。
我刚测试过这个功能，倒不觉得这是糟糕的UI/UX设计。点击邮箱地址弹出的菜单里，其他操作选项显然更常用。但如果你右键点击邮箱地址，编辑选项就直接显示在底部(最后一项“更改邮箱地址”)。考虑到你所说的该功能使用频率较低，我认为这种操作方式并不算太大的缺陷。
此外，电子邮件地址右侧还有一个“X”按钮，可直接删除该地址，无需额外点击。
> 我刚测试过这个功能，并不认为这是糟糕的UI/UX设计典型案例
所幸我们无需依赖主观感受来判断用户体验优劣。存在诸如分层任务分析法或启发式评估法等具体方法论，可通过评估具体指标(如操作所需步骤数和导航层级)来量化用户体验设计的好坏程度(更准确地说，是复杂程度)。
假设我们采用HTA方法。当你需要执行某项任务时，从导航层级的顶层开始，对比新设计与直接点击修改邮件地址的操作流程：你需要经历多少操作步骤和导航层级？两种方式下撰写邮件耗时各多少？你需要在主界面与谷歌贴心设置的上下文菜单间切换多少次？现在退出邮件编辑窗口，评估谷歌工作空间中可执行的各类操作——其中多数都存在类似的操作怪癖。现在将预估的操作次数乘以怪癖数量，你将逐渐意识到普通用户在使用——或者说“对抗”谷歌产品用户体验时承受的巨大认知负荷。
哪家公司的产品拥有卓越的用户体验？我总看到人们抱怨各种问题，却从不举例说明他们心目中的典范。
世间万物皆非完美，但以下几款产品确实令我乐在其中：
https://www.geogebra.org/calculator
https://regex101.com/
https://gchq.github.io/CyberChef/
https://www.figma.com
https://www.affinity.studio
https://bluecinema.ch(用于购买瑞士某连锁影院的电影票。多年未用，但初看仍如记忆中那般流畅。当年无论桌面端还是移动端都体验极佳，堪称完美设计。)
任何电子表格程序(我喜欢的是电子表格本身，而非其界面布局)
苹果的Spotlight搜索，GNOME的类似功能(不知具体名称)
我也欣赏Tantacrul的界面设计作品：https://www.youtube.com/@Tantacrul/videos
尽管存在必要复杂性和功能同质化问题，我依然是Jetbrains的拥趸。我常使用Uber、Twitch(曾花周末为其开发Chrome集成插件)、Netflix和Discord。许多公司既能为终端用户提供愉悦体验，又能开放API接口，完全避免了谷歌产品中那些晦涩难懂的抽象概念和术语。这体验简直和操作Oracle数据库如出一辙。
> Netflix
Netflix？那个通过臃肿得离谱的缩略图画廊才能勉强打开的视频播放器？唯一能说的好话就是其他电影流媒体平台居然居然更糟糕。
这并非恶意——只是陈述事实。如今多数公司都未能提供良好的用户体验，因为诸如避免让用户思考(即过度复杂化界面)和不阻碍用户操作(在界面流程中弹出烦人窗口)等基本设计原则，不知为何竟成了失传的艺术。有些产品天生易用，比如draw.io。我特别欣赏Stripe的用户体验，尤其是其注册流程。还有家半知名的家具电商公司(名字含W开头？)，我曾下单时惊叹于从浏览库存到结算配送的全程流畅无阻。
没有。如今真正的卓越用户体验，是开源软件在自有硬件上运行。
比如你就是用钱也买不到我放弃IMAP服务器和Thunderbird，转用Gmail这类“网页邮箱”。
作为实践者，我认为Thunderbird的用户体验并非核心驱动力。
我追求的是自主权和避免锁定，但Thunderbird存在令人沮丧的不一致性，尤其在搜索和过滤功能的混杂设计上。
优秀的用户体验为何要与开源属性挂钩？
因为若不喜欢用户体验，你大可亲自修改源代码优化它 /s
/s 但我希望这种心态能改变，因为许多开源倡导者(包括HN社区)都抱有这种想法
严肃地说——开源软件具有抵御“垃圾化”的特性。它当然不是万能药，但分叉的可能性(或用户选择不更新)，加上盈利动机的差异，往往能催生尊重用户的软件。
(从整体来看，软件的用户体验不仅指界面设计或使用过程中的瞬间体验。还包括软件随时间推移的稳定性，以及你能否拒绝不喜欢的新版本。)
说得好。开源软件唯一的真正风险在于某个(相当小众的)项目被终止/弃养，导致你无法再找到二进制文件(且你没有自行构建的能力)。但专有软件同样时常发生这种情况(参见killedbygoogle.com)。
怎么说？VLC、GIMP、Ubuntu搜索和设置界面。糟糕透顶。产品优秀，用户体验却令人发指。
我认为VLC很出色。
哇…你就是那个钟爱Thunderbird的人。移除菜单栏简直荒谬，即便启用后也浪费宝贵的屏幕空间。
Omni Group。Wolfram。苹果部分产品。Rhino3D。Breville部分产品。Prusa(指设备端而非桌面端)。Speed Queen(旋钮式)。仅列举当前打开的应用程序及我坐着能看到的设备。
我是指那些有明确谷歌对应版本/替代品的东西，这样才能比较。我个人认为Wolfram Alpha(假设你指的是这个)并不比谷歌更好。
我从未真正使用过Alpha，当时指的是Mathematica。
我不认为网络与优质用户体验相容，但这并不意味着优质体验不可实现——只是那些在用户体验上取得成功的企业，往往会开发原生应用程序、实体产品，或两者兼备。
我认为基本上所有在2020年前获得苹果设计奖的产品都算。
比如macOS平台上的应用。
没有谁的产品完美。所有产品都存在缺陷。找到任何产品，你都能发现一群人正在抱怨它。抱怨界面设计就像我们亚文化中最廉价的通用货币。
本质上这是“自行车棚效应”。若不亲自实测性能等硬核指标，或缺乏专业知识压制反驳者，抱怨性能问题反而会惹祸上身。但界面范式天生模糊主观，抱怨起来自然毫无后顾之忧。
我认为你描述的用户体验问题与其说是企业文化变迁，不如说是整个行业的普遍现象
这些用户体验设计者本身就不常使用电脑，他们主要用移动设备和平板
这是整个行业的通病
你的观点有道理——若指产品经理这类非技术人员接管设计职责。但若仅指移动端UX设计，这绝不能成为移动端体验更差的借口。考虑到有限屏幕空间引发的诸多问题，我反而期待他们投入更多精力优化…
它专为虚拟键盘设计，而非实体键盘
这比屏幕空间更具决定性意义
观察企业的弱点与优势同样能获得启发
> 谷歌用户体验为何总是如此糟糕？
这取决于你如何定义“糟糕”。
谷歌首页初次上线时，其极简设计(仅含logo和搜索框)与当时内容堆砌的门户网站形成鲜明对比。
有人认为谷歌首页“糟糕透顶”，也有人青睐有加(我属于后者)。
同样的，Gmail界面如此，谷歌地图界面如此，Chrome界面亦如此。
我记得谷歌刚出现时，实在想不起谁会觉得它糟糕。统计学上肯定存在讨厌它的人，但当时我认识的用户要么用拨号上网，要么用低速专线——这种设计根本让人无从挑剔。
我也记得！
但并非所有人都在用拨号上网。许多人住在宿舍里(当时算高速的)或工作场所里都有高速网络。
要知道当时人们还不确定搜索会成为网络信息检索的主流模式。现在看来不可思议，但网络早期空间尚小，目录式检索其实相当有效。雅虎最初走红靠的是目录而非搜索功能。
因此当时存在相当激烈的争论：目录+搜索(如雅虎模式)与纯搜索模式孰优孰劣？
直到后来才逐渐证明：当搜索技术真正成熟时，目录便不再必要。
作为开发者，我理解作者将“用户”泛指的本意：即便你从事内部工具或后端开发，仍存在使用你应用或调用你API的用户群体。若能更好地沟通理解他们，将获得大量学习机会。
他所指的用户可能并非你我这样的终端用户。这是团队间工具/软件的互用场景，因此对后者而言，“用户”实为前者的成员。
我认为这与用户体验完全不同。我发现提升客户支持质量对帮助用户而言重要性高出千倍。
希望YouTube能添加按钮，屏蔽境外诈骗广告。
除了苹果之外，还有哪家科技巨头真正拥有优秀用户体验？
苹果固然以用户体验著称，但这不过是过往辉煌的余韵，如今正日渐式微。
圣诞节给孩子买了iPad并设置了家长控制，结果发现必须用另一台iPad才能解除(而我没有)。
论坛上大量帖子都指出只能通过恢复出厂设置解决。
设置过程中遇到的各种反直觉小问题简直令人难以置信。
> 他们每项服务都难用得要命
您是否要登录Google账户？
对我而言，第三点才是关键所在，且与第一点存在矛盾
为何如此？二者结合恰恰体现敏捷精髓——虽非我所见实践，但符合其初衷：学习、迭代、循环。
> 他们每个服务都难用得要命
呃，不？谷歌云平台比AWS好用得多，IAM设计更合理，文档也远胜AWS。
> 好奇谷歌用户体验为何一直糟糕，近来似乎愈发恶化
用户体验？谷歌连帮助被锁定Gmail账户的用户都不屑一顾。对安卓用户(约30亿)而言，这无异于数字死刑，会带来现实世界的严重后果。
有人竟认为谷歌以客户为中心简直可笑，除非他们被高薪收买，同时还喝了太多迷魂汤。
https://news.ycombinator.com/item?id=36024754该帖子顶部评论出自一位前谷歌员工，精辟总结道：
谷歌季度营收达1000亿美元，相当于每天10亿美元。
这点也说得极好。对于一家实质上不提供客服的企业，他们凭什么宣称自己痴迷于帮助用户？
如果用户未正确设置双重验证(且未备份恢复密钥)，他们又该如何保障安全？
就连银行都苦于身份验证难题。在欧盟地区，持第三世界护照的人士长期难以开设账户。
谷歌无法轻易将个人身份与电子邮箱关联。除非建立客户服务系统——来验证护照？面对数百个国家、被盗的身份证件？
不。
> 关键在于，当规模扩大时，你的边缘案例仍涉及数百万人
> 似乎永远无法处理随之而来的其他问题
政府也是如此。只要去驾照局、护照处或任何政府机构，总会遇到某个遇到奇怪问题的家伙。
见鬼，按我的经验，他们甚至常拒绝帮助广告客户解决阻碍广告投放的问题。
你的代码是给陌生维护者的战略备忘录——当系统崩溃时，他们会在凌晨两点接手维护。优化他们的理解力，而非你的优雅。我最敬重的资深工程师们都懂得：每次都要用清晰度换取聪明才智。
说得太对了！有时那个陌生人就是你自己——六个月后的你。
> 抽象化不会消除复杂性，只会把问题推迟到你值班的那天。
作为频繁值班者，我认为这只适用于糟糕或不完整的抽象。
值班(或开发)时，你不可能通晓系统所有细节。你需要抽象概念来理解系统运行机制，把握整体运作逻辑，并在故障发生时锁定关键环节。
而通过集中化配置机制调整超时值、缓冲区大小等参数，其价值更是极其显著。
我认为这句话并非否定抽象化或复杂性本身。业界普遍认同：抽象化是推动技术进步的关键手段，这在其他学科领域同样适用。我理解这句话的本意是：抽象层面的华丽表象之下，几乎总是潜藏着可能的故障。因此，当抽象机制有效时，你确实无需让复杂性侵入大脑——但一旦机制失效(通常发生在页面发送之后)，你终究要直面底层的复杂性。基于此理念的主动应对措施，是在抽象层级内或并行构建支持机制，以便在必须“掀开引擎盖”时提供支撑。
> 1. 最优秀的工程师痴迷于解决用户痛点。
作者在此处便让我产生了困惑。
并非他这个观点本身有误——确实如此。但这似乎并非谷歌的差异化优势。或许恰恰相反——先把系统搞得一团糟，再雪上加霜，然后发布——这似乎更接近谷歌工程师的生存法则。只要你“抢先发布”就行。
接着升职跳槽，而你那堆垃圾代码最终会在十年后被砍掉。
严格来说，他提到这些是任职谷歌后领悟的教训，并非指谷歌必然如此行事。若宽容些解读，或许他是通过反面案例领悟的哈哈
我点开个人简介后彻底困惑了。第三人称叙述，篇幅冗长，充斥着与CEO的合影，字里行间透着大型语言模型(LLM)的痕迹。
试读片段：
https://addyosmani.com/bio/
鲜有人能像他这样在推动网络发展的同时激励开发者群体，这份遗产将长久流传。
还很谦逊呢。
他曾多年领导Chrome开发者关系团队——若你在2010至2015年间学习新网页平台技术，必然读过他的文章。
个人简介虽令人尴尬，但需明白这类职业社交简介本质是推销文案，旨在向愿意支付更高薪资的大型企业兜售个人(尤其是其经验与人脉)。普通人及其真实情感并非目标受众。这类文案专为那些以应对虚伪为职业的人群量身打造。
该链接文章本身也充斥着大型语言模型(LLM)的写作痕迹(每隔一段就出现负面平行句式)。可悲的是，这似乎已成为高票首页帖文的新常态。
读完这段简介不禁怀疑谷歌还有没有其他人……
每位工程师都该读读这篇。它汇集了诸多看似平淡却闪耀着真理光芒的启发式法则。
其中尤为精辟的是：
> 新颖性是笔贷款，你终将用停机、招聘和认知负担来偿还。
以及
抽象化并不能消除复杂性，它只是将复杂性推迟到你值班的那天。
这警示着我们不要过于聪明反被聪明误。
鲜有新语言或技术栈能提供足以超越十年生产环境观察的优势——那些熟悉的架构在实战中表现如何，早已将未知领域的未知因素压缩到近乎为零。
我的个人准则是：新技术栈必须能实现原本无法构建的功能，或提供足以抵消熟悉路径偏离所损失效率的显著生产力提升——团队项目中更需考量多人学习新组件的成本。
确实。我完全认同。这本质上是为未来开发者(可能就是我本人，这种情况很常见)践行“最小惊讶法则”。
赞同。
不仅是工程师，所有参与产品创建的人员都应遵循——包括设计师和产品经理。
这里每条要点都堪称金句。
谷歌至今仍深受这两点认知不足之苦，可能比其他公司更甚。
不过他们近年有过服务中断吗？在我看来，ping 8.8.8.8 才是确认网络连接的黄金标准。
谷歌云确实发生过多区域性故障
嗯，确实。
但关键在于经验无法通过阅读他人观点获得，唯有亲身经历才能真正领悟——而每个人的经历都独一无二。一个“在谷歌工作14年”的工程师，未必有资格给出职业建议，却总爱摆出专家姿态。
这类文章读起来更像是自我陶醉者的宣传文案，而非真知灼见的忠告。从作者的“个人简介”页就能看出端倪：用第三人称撰写，充斥着自我吹嘘的成就，配图全是与名人的合影。我早已习惯对这类人物的言论充耳不闻。
若科技巨头里充斥着这般人物，那真是令人窒息的职场环境。
谷歌的创始人绝非埋头苦干、只求最简单直接解决方案之辈。若真如此，谷歌搜索本该在配备关系型数据库管理系统的超高速服务器或大型机上运行。
深有同感。作为通常两年就离职的人——因为实际机会永远达不到职位描述的承诺——这些要点对我毫无吸引力，在欧盟的办公文化中同样行不通。
十五年职场生涯从未真正融入。如今作为承包商更符合我的本性——有明确合同期限，无需应对官僚主义的狗屁政治。
按时到岗，完成工作，合同期满即走。
若能轻松承接新项目且乐在其中，这确实很美妙。我大概不擅长自我推销
我从未需要自我推销。企业会发布承包商需求，按常规流程申请即可。只要具备技能和经验，通常就能获得聘用。
唯一区别在于没有工作保障、养老金或福利。但你能获得一笔一次性付款，然后自行决定最佳方案。
“抱歉这封信写得这么长，我实在没时间写短一点的”(马克·吐温、布莱兹·帕斯卡，众说纷纭)这句话多年来始终萦绕在我心头。阿迪提出的几点观点令我深有共鸣：当编写代码从未如此轻松快捷时，确保所写代码真正有用且必要反而需要更多时间。
我要收藏这句箴言：
孙子云：要么给对手留退路，要么彻底击溃。我常说：羊皮只能剥一次，羊毛却能反复剪。更直白地说：有效胜于正确。
关键在于牢记宏大/长远目标。这意味着维系关系时，你必须甘当混蛋。
这正是《团队的五种失效行为》中所述(因缺乏信任引发的冲突恐惧)。
强烈推荐这本书。
https://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Tea…
这种说法让我感到不适，这可不是好兆头…
我倒觉得这是好兆头——至少你意识到这种情况可能存在。更糟的迹象是认定自己绝非此类性格；那样你既喧哗又无知，只会积累无声的怨恨。
虽无新意，但句句属实，表达精辟，值得反复传诵。这本该成为每门计算机科学课程的必修内容。
第2条和第14条堪称苦涩的药丸。仅凭正确性不足以立足，纵有长期正确的记录亦然。你通常需要让他人相信这本就是他们的主意，却又必须在绩效评估时为自己争取权益。
言之有理。许多观点或许更适用于谷歌/类谷歌企业。在裁员与整体岗位紧缺的背景下，许多职场正试图鱼与熊掌兼得：既要求快速交付和走捷径(冠以“创新思维”之名)，又在捷径引发问题时直接归咎于开发者/测试人员——指责他们为追求效率而牺牲质量。
> 15. 当衡量标准成为目标时，它就失去了衡量功能。
此即古德哈特定律——“当衡量标准成为目标时，它便不再是有效的衡量标准”[1]。
[1] https://en.wikipedia.org/wiki/Goodhart%27s_law
没错，这点也让我很恼火——它被当作原创观点提出却未注明出处。
当有人撰写“我学到的东西”这类思考文章却未引用任何现有知识时，这种行为该称作什么法则？
这让我怀疑(A)他们明知非原创却视抄袭为无妨，还是(B)根本不知这是他人观点。
虽不知是否有专有名称，但将记忆中的内容误认为原创称为“隐性记忆错觉”。
通过教学来确认知识掌握是费曼的理解方法。粗略浏览后，我对帖子内容并无异议。但将这些现象(其中许多在HN上屡见不鲜)归因于“在谷歌的14年经历”未免牵强。
不过话说回来，2026年的CES展会即将开幕，夸张言论注定会持续飙升。
> 真正理解问题的工程师常发现，优雅的解决方案往往比任何人预期的都更简单。
> 从解决方案出发的工程师，往往在构建复杂性时寻找合理化依据。
我确实认同这个观点，只是觉得它出自“在谷歌待了14年”之口颇为有趣。
这恰恰是我离开谷歌和Meta的首要原因。在那些地方，寻找简单解决方案根本行不通。你必须找到复杂的解决方案，涉及众多利益相关者、协调、讨论、升级处理… 既然能推出100个按钮，让团队和主管借此升职，何必只做一个？
> 先做出来，再完善，最后优化。把丑陋的原型展示给用户。
太棒了，给用户提供这种混乱不堪、功能残缺的产品。那些为生产环境投入巨资的客户，最终沦为“外包的质量检测员”
若是内部用户倒也无妨
> 在大公司里，决策总在你不被邀请的会议中敲定，依据你未参与撰写的摘要，由那些时间紧迫、任务繁杂的人拍板。若你缺席时无人能阐明你的价值，你的存在便成了可有可无的选项。
大型组织确实如此。但…对于一家宣称使命是“整理全球信息，使人人皆可获取并受益”的企业…这简直是失败。
当真正数据驱动的公司能用实际成果而非空谈来衡量价值时，它必将席卷全球。
或许无人做到才是最好的？
> 若你总能赢得辩论，很可能正在积累沉默的抵抗。
这在个人生活中同样适用。
这实为奴隶道德：https://en.wikipedia.org/wiki/Master%E2%80%93slave_morality
尼采指出：主人创造道德，奴隶则以奴隶道德回应主人道德。主人道德源于情感，奴隶道德则根于怨恨——贬低主人珍视而奴隶缺乏的事物。主人道德诞生于强者，奴隶道德诞生于弱者。因奴隶道德是对压迫的反应，故其诋毁压迫者
> “写作迫使人清晰思考。掌握知识最快的方式就是尝试传授它。”
这点似乎被那些用大型语言模型增强文本产出的人们遗忘了。
本文部分内容由LLM生成或编辑，基本可以确定
我认为全民借助LLM辅助写作(如编辑)终将成真，若尚未发生。这如同拥有免费编辑，远超语法拼写检查的范畴。
若写作仅是达成目的的手段，那确实如此。在所难免。若将其视为一门手艺，那么挣扎与瑕疵便是过程的一部分。使用LLM会磨平那些美妙的缺陷。
AI生成的粗糙语感让我和许多人感到不适。若能避免这种粗糙感，或赋予其独特韵味，人们会更喜欢它。说实话，具体怎么做我并不在意。
理想状态确实如此，但大量用户使用大型语言模型辅助文本生成的最终结果表明，他们往往同样忽视了编辑环节，正如他们忽视写作环节一样。
我岳父当年做了不少编辑工作(在纸上，用红笔/红铅笔)。他说当你看到满篇“血迹”(红痕)的稿子时，那才叫好稿子。糟糕到一定程度时，连修改都变得困难。
问题可能不仅在于人们不愿修改LLM生成的内容，更在于风格上的平庸已然泛滥成灾，要消除这种平庸简直耗费巨大精力。(没错，或许你能做到。但若你愿意付出这种精力，恐怕一开始就不会让LLM代笔了。)
飞机梗：你看到的永远是糟糕的LLM文本或明显由LLM辅助的写作。
在现代科技时代，我对此深表怀疑。即便在大学里我也深有体会：结交真正朋友很难，却极易退化为匿名者，沦为孤独者。
> Addy Osmani是谷歌软件工程师，负责Chrome和AI项目
感谢Chrome里那些间谍软件？还有那些优先可用性而牺牲隐私安全的愚蠢设计决策？
> 1. 最优秀的工程师痴迷于解决用户痛点。
> 13. 支撑其他工作的幕后工作价值连城——却往往隐形。
> 粘合工作——文档编写、员工入职、跨团队协调、流程优化——至关重要。… 陷阱在于将其视为“热心助人”而非刻意、可控、可见的影响。设定时间框。轮岗制。转化为可视化成果…让其成为可衡量的影响，而非个人特质。
我深有体会，但认为他的问题定位有误。时间盒、轮岗等措施易行，难点在于说服管理层：粘合工作与核心业务同等重要，值得投入时间。若无法达成共识，终将陷入所述困境。
另一种选择当然是放任失败发生，但此时你必须说服管理层和团队成员共同接受这种策略，否则总会有人在缝隙间接手这些工作。
此类清单通常蕴含零星智慧，但这里每条经验都极具价值。
> “对自身确信保持怀疑” > “以好奇心为榜样，才能打造真正学习型团队”
这两条经验通常需要历经磨难才能领悟。如此重大的理念竟能浓缩于两句话中，实属难得，更将我渴望分享却不知如何表达的经验化为文字。精彩文章，感谢分享！
本想略过这篇文章，直到读到你的评论——哇！你完全说对了！我历经艰辛才领悟的道理都在这里，包括那些我隐约明白却难以言表的见解。这就分享给我的成年子女们。
通常我读这类文章总觉得是陈词滥调，但这些观点确实有道理。任何拥有丰富职业经验、领导过团队和产品的人都会对此产生共鸣。
可惜对用户而言，这往往成了推出漏洞百出/粗制滥造软件的借口。
哪些技能能经受十年以上考验？(Ask HN: 投稿)
我逐渐意识到并非所有技能都能经受时间考验。
有些技能初期极具价值却迅速停滞；有些看似缓慢积累，一年后却悄然产生复利效应。
我总会回归粗略框架。
快速掌握工具、框架和特定技术栈。
慢技能：判断力、问题定义、沟通力、审美力。
渐进变化日常难察，岁月流转方显真章。
项目目标日趋模糊。
限制条件不断累积。
权衡取舍比坚持己见更重要。
很想听听你的看法：
哪些技能的实用性超出预期？
哪些早期过度投入却未产生复利效应？
若重来一次，你会选择放慢学习哪些技能？~
在开发前，务必深思这个问题：“如果我们什么都不做，会怎样？”
说得好！我见过太多优秀产品走向衰落。倘若它们能冻结功能和界面设计，只专注于多年优化性能、兼容性和稳定性，结果会好得多。(这条适用于所有公司)我使用的许多程序已有多年历史，它们本就优秀，无需频繁改动！此时更新只会适得其反(除关键安全漏洞、兼容性问题及性能退化外)
清晰即资历，精巧即负担。——某咨询项目中，客户正开发可承载5000+用户的应用。他们聘请了顶尖架构师，精通所有主流框架并将其应用于项目。问题在于，只有他理解这个框架(尽管GitHub上有文档)，开发者花在理解框架上的时间，反而比直接采用更“笨拙”的代码还要多。后来他为了职业发展跳槽了，这是理所应当的。结果开发团队和新架构师放弃了这个框架，另起炉灶，如今旧框架成了“技术债务”。
深有同感。从“我是否正确”到“这是否真正帮助用户”的思维转变至关重要。我发现晋升最快的工程师未必是最聪明的解题者，而是真正关注最终结果的人。
最艰难的是用户需求有时与技术纯粹性相冲突。你可以交付不够优雅但实用的方案，或选择优雅却偏离用户需求的方案。多数组织因偏爱优雅而犯错。
第三条直击要害。糟糕的页面可以修改，但空白页面无从修改。我曾耗费数周过度推敲从未实现的架构方案。发布丑陋产品并从真实反馈中学习，远比任何规划更有价值。第六条也常被低估——早期我以为优秀作品自会说话，事实并非如此。历经数年才明白决策往往发生在自己缺席的会议室里。若你离开后无人能阐明你的贡献，那这份贡献便不存在。
感谢分享。
我最认同第一条：“顶尖工程师痴迷于解决用户痛点”，但最痛恨的是——若非长期共事，根本无法真正衡量此项能力。说起来容易做起来难，尤其当所有人都追逐可量化的技能时，这种特质既难证明又难推销。
正因如此(尽管流程存在其他缺陷)，亚马逊这类公司在技术面试中会设置“客户至上”相关问题。旨在评估候选人是否理解用户痛点的重要性，以及他们采取哪些具体行动去学习用户视角——用俗话讲就是设身处地为用户着想。
当然面试流程可能被钻空子，信噪比也值得怀疑，世间本无完美。但面试环节中“为什么”的核心原则(亚马逊及众多企业皆如此)，恰恰与你称其为“最爱”的理由完全一致。
此外据我所记，2010年代末期某项内部研究显示：在数千场面试的招聘评估数据中，软件工程师职场表现的最佳预测指标并非编程测试或系统设计环节的表现，而是“客户至上”环节的得分情况。
十四年？太疯狂了。我还记得Addy当年以惊人速度发布jQuery教程的盛况(感觉每隔几天就有新教程)。必须说明，这绝非贬义——尽管在2026年读来可能有此误解。
这里提到的要点都很精辟。事实上，这些都无需在谷歌工作就能领悟。
这些观点完全契合我25年的从业经验(虽然只在谷歌待过一年)。我补充几点：
* 切勿加班加点工作，无论多么迫切：管理者最讨厌意外——哪怕是好消息！若有新想法需要推进，务必提前沟通并争取支持。若你投入大量个人时间处理某事，这意味着该项目价值可能较低(你潜意识里也清楚)，或是踩到了他人地盘，又或是只有你一个人在乎。一旦完成，你的经理只会质问：“为何不处理<其他更高优先级事项>？”若因此引发漏洞、用户投诉或其他问题，责任将由你承担。请将创造力留给个人项目。
* 为每日设定极低目标，但务必达成。我们不可能时刻保持巅峰状态。当你精疲力竭或被棘手难题困住时，推进工作会显得异常艰难——“随便刷会儿网”可能变成整天，进而演变成整周甚至整月的拖延借口，而随之而来的焦虑和愧疚感，往往比工作本身更令人窒息。避免这种情况的方法是设定一个轻松可达的目标：写几行代码，找个可能解决难题的人聊几句，诸如此类。这样既能阻止焦虑累积，避免次日带着前一天的负面情绪醒来，至少能在每日站会时有点进展可汇报，还能减少一件待办事项。往往这会形成势头，最终成就高效的一天！但即使未能达成也无妨：目标只是完成那件事，其余纯属可选项。偶尔放空一天充电也未尝不可，只要次日不必从原点重启即可。
第14条精辟揭示了两种状态的微妙差异：在他人知识领域重叠甚微时，强势主导对话与真正展现专业素养的区别。我认为通过极度透明地阐释逻辑依据，甚至适度传授知识，能有效强化这种边界。
若你竭力共情、换位思考并澄清问题后，对方仍积攒沉默的怨恨“债务”，说明合作关系本身存在问题。如何应对取决于你的政治资本，有时只能接受现状。
年轻时的我天真地认为，人们如同理性自动机：会在恰当时机发声，不把事情往心里去，并像我这样以共同目标为导向。但这绝非健康协作的基础。
这篇以及目前HN上的另一则热门报道(我为静态HTML页面收取了1.8万美元)[0]都清楚表明：作为软件开发者，最重要的是跳过重重障碍并保持顺从。这是否合理并不重要。我已接受自己无法始终预测什么对业务真正有价值，只需随波逐流，收钱办事。Leetcode式的面试正是通过设置任意障碍来筛选这类特质。
[0]: https://news.ycombinator.com/item?id=46469877
第2条和第14条的核心观点是否基本一致？二者似乎都指向一种病态的文化氛围。亚马逊的“反对并执行”理念，远比“假意认同后暗中破坏”更健康。
我认为存在一条能兼顾各方利益的中庸之道，但当前做法显然并非正解。
我不禁怀疑这是否是谷歌的普遍现象，因为多年前另一次访谈(现已找不到，记得是在WebRTC相关讨论中？)里，有位工程师曾自豪地描述如何合谋推翻一项重大技术决策——只因该决策与他的个人偏好不符。当时看到有人如此公开承认此事，我颇感震惊。
这些教训值得每位初级工程师学习，也应分享给所有同行。我完全认同你提到的观点：“人脉网络比任何工作都更持久”。我确实认识不少技术能力平平的开发者，却总能顺利跳槽。
你的帖子堪称经典，其真谛远不止适用于谷歌。我从未见过一篇帖子能如此集中地揭示这么多深刻的真相。虽然这里很多人会对某些观点提出异议，但随着经验积累，他们终将意识到这些观点确实正确。
我认为资深工程师的重要职责之一，就是避免在行业内散播炒作。这位工程师似乎刚在社交媒体上大肆宣扬自己刚获得Claude权限，并在一周内重做了耗时一年的项目，随后他的工程团队又发推澄清这只是“演示级”成果。
> 这人似乎刚在社交媒体上大肆宣扬他们刚获得Claude，并用一周时间重做了耗时一年的项目
查证这两者是不同人物所需的时间，比写这条评论还短。
谷歌工程师[Jaana Dogan]表示Claude代码仅用一小时就完成了她团队耗时一年的工作 https://news.ycombinator.com/item?id=46477966
第11课(抽象化转移复杂性)与第20课(时间＞金钱)实为一枚硬币的两面。工程领域常讨论代码中的“泄漏抽象”，但最大的泄漏抽象往往是我们自身的健康。我们把身体当作永远运转的“无趣依赖项”，但职业倦怠和重复性劳损本质上就是终极系统崩溃。正如“新奇感是笔贷款”(第5课)所言，职业生涯早期忽视身体这台“硬件”，无异于借高利贷——最终你将在四十岁时偿还。真正的资历不仅在于驾驭人际关系与职场政治，更在于管理个人能量，确保自己拥有享受终极“复利效应”(第21课)的健康资本。
谷歌CEO麾下众多高管带领开发团队冲刺既定目标。最终他们优先考虑奖金分配，个人目标在每次迭代中不断偏离。因此质量将持续衰退。
说得好。我在谷歌工作不足两年。期间经历诸多变故——通过收购入职、负责收购项目的后端开发、父亲去世、团队调动等。但当时27-28岁的我，从初创公司转职后实在难以适应那个世界。某种程度上，我仍渴望找到突破之道；但另一方面，我也明白那本非命中注定。这份清单很有价值。若你打算在谷歌或其他公司干满十年，请将这些要点和经验内化于心。
我摘出三点：
> 2. 坚持己见易如反掌，携手达成共识才是真功夫
> 6. 代码不会为你发声，人才能
> 14. 若你总在辩论中获胜，很可能正在积累沉默的抵抗
这些要点揭示了大型组织中的共通规律：你的影响力主要取决于受欢迎程度，完全基于氛围判断。层级排名(谷歌曾采用，不确定是否仍在使用)本质上就是对人气的制度化。
问题何在？自闭症人士往往因此遭受不公待遇，这绝非他们的过错。这类体系本质上是为神经典型人群设置的筛选机制。
这种现象在绩效评估(Meta称“perf”，其他公司称“calibration”)中尤为突出——相同的事实依据既可被解读为成功也可被判定为失败，唯一差异在于“氛围感”。我对此已见怪不怪。
有次目睹六人团队消失六个月毫无建树，归来后直接解散。若受人喜爱，结论是“我们收获颇丰”；若不受待见，则定性为“毫无成效”。
多年前谷歌研究成功团队要素时，关键因素是心理安全感。这篇[1]看似相关但更近期的研究，其实最初是十到十五年前完成的。我对此深表认同。症结何在？永久性裁员文化——这种纯粹压制薪资的机制——摧毁了心理安全感，将生存转化为博取好感与制造影响力的游戏。
> 18. 多数绩效提升源于消除冗余工作，而非增添花哨技巧
谷歌令我赞赏的一点是其极其严格的编程规范，特别是C++子集的使用范围极为有限(当时如此？)。当时规定包括“禁止异常处理”、“禁止可变函数参数”，且添加模板的门槛极高。
为何如此？为避免风格争议。这点至关重要。更因为C++似乎特别吸引沉迷于自我炫技的开发者。我见过某些骇人听闻的模板用法(非谷歌案例)，它们让代码测试难度暴增却收益甚微。
> 9. 大多数“低效”团队本质上是目标错位的团队
我认为这是最关键的观点，但更愿将其概括为：多数问题实为组织问题。
以Meta为例，产品团队被激励尽快发布产品，其成效仅通过指标提升来衡量。但对于已发布产品的维护支持，除了确保其不崩溃外，没有任何激励机制。因此许多团队采取“火烧船式”处理方式——提交缺陷报告后便置之不理，最终导致公司不得不将旧缺陷纳入服务等级协议(SLA)管理，结果可想而知：人们干脆降低缺陷优先级以规避SLA要求。
这是组织层面的病灶——参与者早已洞悉发布是唯一能获得回报的行为。文档完善、代码质量和漏洞修复等工作，终究只是口头承诺。
免责声明：前谷歌员工，前Facebook员工。
[1]: https://www.aristotleperformance.com/post/project-aristotle-…
读到这些建议令人沮丧，其核心要义无非是“别想太多，降低门槛，保持简单，做个善于交际的人”，而他们的招聘流程却充斥着高级数据结构和算法。既然只需保持简单氛围、避免过度思考精妙解决方案，何必招募顶尖技术人才？
我七成确定这部分内容由AI生成。
更令人难以置信的是工程师们竟在为用户服务——毕竟谷歌当前的核心业务就是全面降低产品品质。
基于这两点，我连第四条都读不下去。
这读起来就像是经过精心训练的昂贵AI。真想让他不带手机接受面试，看看能否复现其中5条观点。
我确信他是能力超群、经验丰富且口才极佳的人。除了靠写作谋生外，AI代笔绝无借口可言。
我喜欢这个观点
> 当规模足够大时，连你的漏洞都有用户。
这是我多年维护rclone时用血泪换来的教训。修复漏洞会引发连锁反应，有时甚至存在依赖该漏洞的用户！
xkcd: https://xkcd.com/1172/
我称之为海勒姆定律(同样出自谷歌人)：
“当API拥有足够多的用户时，契约中承诺的内容已无关紧要：系统所有可观察的行为都将被某人依赖。”
https://www.hyrumslaw.com/
这定律很精辟：但更可贵的是，其中多数原则适用于各类组织，而不仅限于“谷歌级规模”的企业。
感谢您对rclone的维护工作！这是款卓越却未受重视的软件。
我认同第3条和第8条，但存在两难困境：若首次发布不完美，即便新版本仅耗时10分钟，所有人的升级仍将浪费数千工时。
> 新颖性是需要用停机来偿还的贷款
若您亲手构建全部(或大部分)功能，便处于极端垂直整合的优势地位。唯有完成如此大量创新工作，才能实现系统级的大规模变革。
兄弟们，我累坏了
太高兴发现不止我注意到了这点。
文中确实存在深刻洞见，但用AI编辑来弥补文章缺陷的做法，反而削弱了核心观点的传达效果。
作者的原创思想与AI生成的半成品(甚至完全生成的内容)界限模糊，严重削弱了可信度。
这完全违背了“清晰度优先于精妙”的理念，以及“先发布再完善”的创作原则。
这简直太不尊重读者了。我花时间读完这篇文章，你(作者)连发布前通读一遍的时间都不愿花？
文章观点其实相当不错，正因如此，AI生成的粗糙文风才更令人恼火。
作者懒得写的文字，我们也不必费心去读。
感谢你的提醒。这让我能直接跳过整篇文章，因为一眼就看出是AI生成的垃圾。通常我得读到一半，大型语言模型检测器才会报警，但这些“这不是X，而是Y”的句式简直是死马当活马医的典型。
文章最精彩的部分？
> 但协调成本呈几何级增长
居然用“几何级”而非“指数级”！谢啦！！！:-D
没错，这词选得指数级地精妙！
最让我共鸣的是：聪明反被聪明误。
我对中级工程师最大的不满在于他们热衷复杂性，甚至觉得复杂有趣。
资深工程师深知复杂性只会带来烦躁与挫败，而简单解决方案更难实现却更胜一筹。
既能解决问题又能降低复杂度的方案，几乎就是天才的定义。若你足够优秀，整个职业生涯中能做到几次就不错了。
> 既能解决问题又能降低复杂度的方案，几乎就是天才的定义。
说得好。追求“我们能让它变得多简单？”正是这份工作令我着迷的核心所在。但这或许不是好的职业建议。
没错，“简历驱动开发”是推动复杂性的另一股重要力量——我之前未曾提及。出于显而易见的个人利益考量，人们渴望积累尽可能多的流行术语、技术栈和开发经验。
这种激励机制真实存在。一位擅长简化系统、构建优雅可维护架构的优秀程序员，可能因无法列出长串技术经验而落选。毕竟，他们的卓越之处恰恰在于让这些东西变得多余。
这正是扭曲激励机制的典型案例，其根除难度极高。这种现象给整个行业带来的净效应是：让所有人付出金钱、时间和挫败感的代价，更不用说那些本可用于打磨产品、优化UI/UX或推动创新的认知资源，最终沦为应对复杂性的消耗品。
这种现象在商业和风投层面亦有体现。每处复杂性都可能催生新产品、服务或初创企业的细分市场。这堪称“产品组合驱动开发”——实则是“简历驱动开发”的升级版。
再次精辟总结。这种现象往往还会引发连锁反应。
> 抽象化并不能消除复杂性，它只是将问题推迟到你值班的那天。
金句。
> 3. 行动优先。先发布。糟糕的页面可以修改，但空白页面无法编辑。
> 先做出来，再完善，最后优化。把丑陋的原型展示给用户。写出设计文档的粗糙初稿。发布让你略感难堪的最小可行产品。一周真实反馈的收获，远胜一个月理论争论。
> 动量催生清晰，分析瘫痪一无所获。
我见过Addy，且愿宽容以待，但对此观点强烈反对——这恰恰暴露了当今软件开发中损害所有人的巨大盲点。
在“理论争论”与“草草推出垃圾产品”之间，绝不存在非此即彼的两极。当整个行业持续忽视其他工程领域的经验教训——即先收集需求——软件工程就永远无法成为真正的学科。
想了解用户需求？何不直接询问？为何不调研他们当前使用的工具(或未使用工具)，找出问题所在？做用户调研呢？分析竞品和前代产品呢？
然后列出功能清单——明确说明产品能做什么？清单可以精简，当然。制作原型(或许仅供内部使用)？当然可以。不必包含所有功能。
但这里存在一个巨大的盲点，我必须指出。在软件封装销售的年代，当产品开发耗时数月甚至数年时，人们可是认真规划过要打造什么！我并非在美化那个时代——当时确实存在诸多风险和失误——但以这种方式开发的软件至今仍影响着我们，不仅是设计和使用模式，连大段代码也沿用至今。这些并非全是陈旧的垃圾代码；开发者们确实经过深思熟虑才投入构建，随后在工具简陋、构建耗时更长、团队庞大、沟通不畅、计算资源匮乏等重重劣势下，仍以精益求精的态度完成开发与测试。
这份清单里还有其他不错的建议，但我觉得这绝不可能涵盖14年经验的全部真谛。换句话说，请别在产品刚能运行时就把垃圾产品塞给我们。
本文可概括为：描述在大型企业而非初创公司进行软件开发的情况。
基于我的亲身经历：过去19年我就是这样生活和呼吸的
读完这篇，庆幸自己不再身处谷歌
这就是人工智能无法突然完全取代软件工程师的原因。
我恨透了他的正确。这深刻揭示了人类劳动激励机制的病态本质，以及为何人工智能终将摧毁工作岗位——因为AI无需应对那些围绕政治斗争、权力操控和人事管理的荒诞仪式。每当我们为“维护企业文化”而膜拜某种愚蠢行为，就如同谷歌首席工程师在X平台崇拜Opus般，像初次参加舞会见到性感对象般痴迷，我们便在加速走向必然的毁灭。
这种病态已深入骨髓，在我们建立追求卓越与清晰的新文化之前——那将超越那些被迫处理混乱的工程师——我们必将自我毁灭。
天哪！这篇读来令人耳目一新，每位资深员工乃至管理层都该强制阅读。
面试提问：
– 在同一家公司待了14年，你究竟如何实现成长？
讽刺的是，在邪恶公司工作唯一能学到的就是：埋头苦干，别问尖锐问题 :/
这套经验很扎实。我最认同的是：软件不会为你发声，人会。
最大教训是集体裁员随时可能发生。所以要为自己争取最大利益，因为只有你自己能做到？
以下是我合作过的所有前谷歌同事带到新岗位的经验：
1. 万事用Bazel。文档烂透了？对小公司来说臃肿得离谱？无所谓——照用不误。所有事都用它。
2. 凡事从零编写。需要C语言的protobuf解析器？别用那些久经考验的开源方案，自己写一个。
3. 永远对前端工程师摆架子，视其为低等/非真正的工程师。真正的工程师是后端工程师。前端工作如此简单，必要时他们也能做得很好。务必用Bazel构建所有前端项目。
4. 我提过Bazel吗？它是所有公司所有问题的终极解决方案。
我觉得最宝贵的教训并未编号，而就在开篇陈述中：
我为此唠叨了_多年_。见过比我聪明得多、代码写得更棒的工程师也因此栽跟头。在会议中展现一小时的亲和力、随和度和洞察力，对公司内部声誉的提升，远胜于耗尽心力完成比任何人都多的工单。真希望更多人能明白这个道理。
归根结底，当管理者或项目总监仅仅因为你令人愉悦且可能带来洞见而邀请你参会时，这意味着你在团队中的价值已超越最顶尖的程序员——后者若因难以沟通而令人头疼，便不值得被纳入会议。
以服从程度决定会议邀请对象的管理者，就是糟糕的管理者。乘以下属数量就是问题严重程度。赶紧改掉。
我没提服从，说的是愉悦感。也不明白你提下属数目是什么意思。你没事吧？
> 专注你能掌控的事，忽略无法改变的。
这就是我离开谷歌转投高频交易的原因。生活好多了。
是去更直接服务企业利益、减少管理开销的地方吗？(:耸肩:)
> 1. 最优秀的工程师痴迷于解决用户痛点。
纯属胡扯。恕我直言，用户选择谷歌是因为其生态系统+价值主张。谷歌云端硬盘和日历根本是过时的SaaS软件，仅因身处庞大生态圈——以及价格优势——才勉强可用。它们(连同其他谷歌产品)还拥有网上最糟糕的用户界面设计。咱们别扯淡了。换作我是谷歌，早就该担心了——Fastmail、Notion和Proton这类公司正在迅速追赶。
> 换作我是谷歌，早就该担心了——Fastmail、Notion和Proton这类公司正在迅速追赶。
哈哈，你当真以为谷歌会担心Fastmail、Notion或Proton？
> 正在迅速追赶。
若你身处谷歌崛起前的雅虎，也会说出同样的话。
普通用户的心智份额早已注定。我没看到Fastmail有同样趋势的迹象。除了隐私问题——普通用户根本不在乎这个——谁会从Gmail转用Fastmail？
隐私问题，以及整体产品体验。顺便说一句，我提到的可不止Fastmail。
从该公司挑选两个最不为人知的应用来论证实在牵强。你对“顶尖工程师都做X”的反驳也存在逻辑漏洞——谷歌或许没用“顶尖工程师”开发那些精选案例？说不定他们被派去负责搜索引擎或基础设施了？
我在评论文章本身，而文中首点显然不涉及搜索或基础设施。建议先读完再妄下结论。至于为何“逻辑有瑕疵”？
谷歌产品远不止你列举的两款，其中不乏大获成功者。或许他们将“顶尖工程师”投入更成功的项目？
对职业发展的洞见颇深。多数工程师不会谈论这些。
这更像是对他人观点和博客的堆砌与复述，几乎没有创新或增补。公平地说，我更期待看到作者的原创见解，或是这些被复述的观点在谷歌语境下的独特价值。
那便是糟糕的抽象。我理解他的观点，但整个领域正是建立在抽象之上——比如让你无需亲自动手就能将矩阵乘法转化为电子排列。
极具洞见的观点。过去二十年我正是通过艰辛实践才领悟这些教训。
谷歌的诸多经验实则是源于历史独有的垄断时代，而那个时代早已消逝。这些背景虽具参考价值，但若将其奉为永恒真理则颇为危险。
首段读起来像领英的废话，我快速浏览了剩余标题——看来全文都是这般水准。
第12条如此简单却如此真实。精彩清单，感谢分享。
非常赞同。大部分观点我都认同。唯一不同意的是“我最敬重的资深工程师都懂得用清晰度取代聪明才智”。这听起来像是“为最低能力设计”这类反模式的翻版。这是个大陷阱。适度的灵巧往往比过度清晰更可取。初级开发者应当先学会遵循规则和理解机制运作，无需深究背后的原理。
真希望入职谷歌前就读到这篇文章。
尽管我们内部常调侃此事，但AWS的领导原则始终是我最欣赏的特色。我曾担忧自己陷入教派式的偏执，如今看到这些理念汇聚成相似的卓越思想，倍感释然。
我认为所有原则的核心共通点在于信任——唯有信任才能让多数原则真正生效。从战略层面的政策制定、人才招聘到战术流程优化，不变的基石始终是构建信任的环境与文化。而这种信任的规模化绝非易事。
感谢分享，阐述得非常到位。
阿迪在谷歌待了14年就是明证，我认为内部人脉网络在这里比外部资源更重要。
初创企业蜕变为巨头后走向衰败令人扼腕。这篇文章堪称绝佳例证——从作者背景到文中充斥的LLM垃圾内容。可悲的是世事往往如此。
在任何地方工作14年的核心教训是：切勿在单一岗位停留超过两年。
否则你会开始认为职场政治很重要。
超爱超爱超爱这段。如此睿智的见解，真希望三十年前就明白。
以下是我个人理解的精要版：
其他一切本质上皆由此衍生。
在某AI培训公司工作数月。公司日益荒谬化绝非虚言。那些不配在此任职的蠢货每周制定新政策，有时甚至一周两次。面对FAANG巨头客户的无理要求时毫无骨气，却对同事肆意刁难毫无悔意。
多么平庸的文章。它仅够让人们附和点头，发出“哇，说得对！”的感叹，却对持不同意见者几乎毫无价值。这些内容对初级工程师毫无裨益。诚然，文中所述基本属实且措辞得当，但毫无附加价值。这就像嗅觉测试：把这篇文章给工程师看，那些对多处观点持异议者，就该安排资深导师指导。
这些观点确实精辟，但往往缺乏背景信息、补充说明和注意事项。若作者能稍作补充就更好了。
比如关于“坚持己见易如反掌，而达成共识才是真正的挑战”这点。诚然，经协商达成的决策优于强行推进的方案。但如何实现共识？难道其他人必须放弃(按文章说法)“立场不坚”的观点？我认为：坚持基于事实的个人见解，即便最终未被采纳，也应被尊重。任何有尊严的工程师都应接受这种情况。
> 代码不会为你发声，人才能。
这取决于你相对于他人的代码产出量、绩效衡量标准、实际会议耗时(以及其中多少属于无效沟通或本可邮件解决)。曾在前公司因代码质量与产出量，促使他们重新审视薪酬奖金体系(最终确实调整了，但实施时我已获得更优邀约离职)。尽管资历较多数同事浅，但我的编程经验(通过开源项目和个人项目积累)远超他们。你的代码确实能为你代言，你的整体产出、贡献等同样如此。并非所有公司都充满政治斗争，尽管我确信作者的观点在FAANG公司同样适用。
此外，我不确定这个观点能否为初级开发者提供可操作的建议。难道要放弃编写优质代码？放弃全力以赴？放弃精进技能而去参加公开演讲课程？我无法确定。
这篇文章还算不错，但在我看来缺乏新颖内容，读起来有点像AI生成的垃圾文本。
另外这段让我卡壳：
这绝对是第50或100个重复相同论点的文章版本了
文中所有观点早在1968至1987年间已被明确阐述：布鲁克斯在《人月神话》中系统化阐释了协调成本与增人误区
康威1968年证明系统架构必然映射组织沟通结构
帕纳斯1972年将信息隐藏与模块化定义为组织约束而非编码风格
迪杰斯特拉曾反复警示：复杂度增长速度远超人类认知能力，事后无法通过社会协作管理
本文既非创新，亦非重新诠释或拓展，只是对半个世纪前约束条件的忠实重述。
这些清单不断重现的根源在于我们拒绝解决结构性问题：在现代激励机制下，这些约束条件皆无法有效实施。
于是总有人像时钟般精准地冒出来宣称：嘿，我观察到这些在组织管理史——尤其是计算机与软件管理领域——被反复记载的现象，看看这份清单吧。
实在令人精疲力竭
人们不愿从旧著中汲取经验固然令人困扰，但重写经典恰恰合理，因为人们往往更倾向于信任新版本。
软件工程师容易陷入新奇偏好，这与某些更青睐古籍的群体截然相反。
其实两者都错了，因为他们无法走中庸之道
是啊，但你能怎么办？那些日常犯错的工程师们，就算我把经典著作塞到他们面前也无济于事。说真的，他们半数抱怨都和你如出一辙：要是多数[工程师/同事/利益相关者]能明白[A/B/C原则]，就能避免重蹈[X/Y/Z失败]覆辙。是啊，这很累人，生活本身就很累人。知识和经验并不能本质上改善现状，因为与最低标准的差距只会越来越大；我唯一找到的慰藉是专注于自己能掌控的事。
首先，我直接以康威定律为基础重组了公司及整个工程体系，效果极佳。
这简直是最低限度的要求，操作简单却能解决半数“问题”。
贵公司规模如何？
更关键的问题是我们的增长速度有多快……
目前工程团队约30名全职员工，若计入运维、物流等岗位则达40人。随着新融资到位及项目即将公开，预计今年将达到邓巴数(约150人)。
精彩文章，感谢作者分享宝贵见解。
对我而言核心启示是：切勿让成功滋长自负。人类皆易陷入自恋陷阱——有趣的是，原本谦逊的人取得成就后，身份转变反而会使其优秀品质消逝。成功会吸引形形色色的人进入生活，他们可能只被你的成就光环吸引，却缺乏勇气指出你的荒谬之处。
培养健康的自我认知，关键在于结交真心爱你的人——他们既能给予温暖，又敢于在你行为失当时及时提醒。
精彩文章！
最泛泛的建议啊
>抽象化并不能消除复杂性，它只是将复杂性推迟到你值班的那天。
这句太真实了。当你费劲揣摩一堆间接表达，试图搞懂某个精妙抽象到底该做什么时，那种煎熬无可比拟。
> 1. 最优秀的工程师痴迷于解决用户痛点。
这里带点讽刺意味：“那谷歌大概没多少顶尖工程师了吧”
有趣的是我认同这些原则的绝大部分，但十年谷歌生涯却与之背道而驰。这些理念并非在谷歌习得，而是早年(及后期)就领悟的，却始终沮丧于谷歌对它们的漠视？
谷歌内部的激励机制存在缺陷。
我确实认为谷歌的工程文化倾向于反对过度抽象，主张代码简洁可读，这点值得肯定。但至于以用户利益为先、及时交付等原则…就差得远了。
或许楼主正是因为目睹了忽视这些原则的后果，才深刻领悟了它们的重要性
我完全不认同这些观点。
lgtm
这篇读来令人震撼
有人认为清晰意味着抛弃语言特性，只写出计算机专业新生都能理解的简单代码。
若真如此，团队只会写出冗长重复的代码，过度关注流程而非数据结构及其动态变化。
真正需要语言技能与专业素养的，是运用语言特性编写强大精炼的代码。要推动团队提升技术水平，而非降低标准迎合最低要求。随着时间推移，这类代码终将像任何简单程序般易于理解。
当凌晨两点系统崩溃时，你无需出手——因为你的代码足够聪明，能自主解决问题。
但切勿故弄玄虚。
看来作者在长达十四年的职业生涯中，为取悦高层怪胎或破解他们强加的无处不在的狗屁理论，早已丧失了自我个性。
17. 你的社交网络将比任何工作都更持久。
或许当你解锁顶级持久社交网络后，个性便不再被允许存在。
众生效应 :)。
这话从Addy口中说出颇有虚伪之感。
阿迪·奥斯曼尼剽窃了我的代码，数年后竟通过在其个人网站[1]发布文章“道歉”——而他从未在社交媒体上分享过该链接。
除非他真正将这篇道歉文推送给所有关注者，否则我绝不接受。
结合以下观点值得特别指出：“6. 代码不会为你发声，人会。”"7. 最好的代码是你永远不必编写的代码“，以及”14. 若你总在辩论中获胜，很可能正积累着沉默的抵抗"。
1. https://addyosmani.com/an-apology-to-eli/
你将代码发布在公共博客页面，既未在代码中标注来源也未要求他人标注，未附许可协议，且显然意图免费向全世界分享。
随后你收到了道歉，又收到第二次道歉。
我不明白你认为自己应得什么？
解释完全合理，头文件显然只是复制粘贴，并无恶意。此事究竟还有什么让你耿耿于怀？
> 未标注许可协议，且看似意图免费分享给全世界
未标注许可协议意味着你无意“免费”分享——毕竟你未授予任何权利。默认情况下，你无法仅凭内容存在就拥有他人分享在互联网上的东西。
话虽如此，我甚至见过仓库标注许可的人在代码被使用时大发雷霆——这种情况难以预料，最好将随机来源的代码视为禁忌。
根据Eli在此处的评论，原始复制的代码属于纯粹的公共领域，因此甚至无需署名。
https://github.com/Modernizr/Modernizr/pull/684#issuecomment…
我很好奇，对于Stack Overflow上共享的代码，您是否持相同观点？
我认为GP指的是作者作品默认受版权保护的事实，需要许可才能允许他人自由使用[1]。StackOverflow帖子采用CC BY-SA 4.0许可协议[2]。
[1]: https://www.copyright.gov/help/faq/faq-general.html
[2]: https://stackoverflow.com/help/licensing
(免责声明：本文仅针对GP关于“无许可”的陈述发表评论，不涉及上述具体争议或致歉内容，因本人对此不甚了解。)
值得注意的是，正如原作者在讨论串[1]中所言，该代码本身已开源并采用宽松许可协议。我认为这根本不是许可问题，只是原作者似乎认为此举失礼，且拒绝接受任何已提出的道歉。
[1]: https://github.com/Modernizr/Modernizr/pull/684#issuecomment…
并非为抄袭开脱，但审视代码本身时我颇感困惑——这段代码似乎相当…平庸？
并非贬低其工作量，但至少就代码篇幅和投入程度而言，若有人抄袭我的作品并据为己有，我根本认不出这是我的代码。
关于抄袭指控，是否可能PR署名反映的是某人渴望为大型项目贡献力量，而非单纯“窃取”他人成果？
合理解读PR及署名可理解为“我将此代码整合至本项目，故主张署名权”。换言之，这更像是误入歧途的博眼球行为，而非抄袭。
你贴出的代码属于标准图像加载处理，但关键在于这行：
self.apng_supported = ctx.getImageData(0, 0, 1, 1).data[3] === 0;
除非我理解有误，这本质上是个“巧妙技巧”，类似用~~实现四舍五入或快速求平方根。
难道使用这个技巧的人都该链接回你的博客？
addy的言行常让我反感，但这事你真该放手了老兄。
天啊。我从未见过半点像他这样恶心又尴尬的个人简介页。
https://addyosmani.com/bio/
这简直荒谬到像在恶搞
> 同事们常称赞奥斯曼尼的谦逊
笑死！谁能一本正经写这种自我吹捧？！
这也证明把别人的功劳据为己有完全是他的惯用伎俩。
> 奥斯曼尼的团队创建了Workbox——一套用于生成服务工作者脚本的库，能轻松处理缓存和离线功能。Workbox简化了原本需要编写低级代码拦截网络请求的复杂任务。
不，杰夫·波斯尼克(严格来说他当时在阿迪团队)才是Workbox的创建者，自他离开谷歌后该项目基本被弃置。还是说其实是桑达尔·皮查伊团队开发的？抑或布伦丹·艾奇才该居功？
我不得不认为他其余的履历和职业生涯都是建立在窃取功劳的基础上。他总是让我感到不快，而这件事印证了我的感觉。
真是个精神病患者！
顺便说一句，实际的道歉信写得很好。
不过末尾的小注解释了缘由：
> 本声明系回应Eli Grey于2023年10月致Chrome管理层的邮件
换言之，他是在被迫情况下才写下这段话。
埃利还回溯修改了11年前的原始回应：
> 没问题；但请记住，修改他人代码并不赋予你对该代码的任何版权。
改为
> 我不同意你的观点——将现有代码插入框架(Modernizr)的模板(API)中，即使对插入代码做了少量修改，也无需署名。
执着于某事长达11年之久，又在11年后回来修改评论，这似乎有点疯狂。
https://github.com/Modernizr/Modernizr/pull/684#issuecomment…
这未免有些过头了吧？
用originality.ai检测就能发现：部分内容是他本人所写，部分是混合文本，部分纯属AI生成。大家热议的这篇博文同样由AI撰写。
那么“originality.ai”究竟是什么东西，竟敢自诩为AI来源(这个无解难题)的权威？
那网站乐此不疲地标记现代AI时代之前的写作。纯属无价值的骗局，可惜已骗了许多人上钩。
哈哈你居然相信那网站超过一秒？
那段无足轻重的代码竟被炒了15年。真让人想起陀思妥耶夫斯基的《地下室手记》。
感谢分享，就算不知道这事我也觉得那篇博文虚伪透顶
“除非……否则我无法接受这个道歉”
你都拿到书面道歉了还想要什么？
要他在所有社交账号发声明？要他在餐桌和睡前故事里讲这个？要他在悼词、讣告和墓碑上刻这个？
你的人生目标现在就是在他每条动态下刷你这出小戏码吗？
那段代码是你迄今最伟大的成就？它抢走你数百万资产毁了你的人生？
他妈的成熟点吧哥们
老天，兄弟。
往事就让它过去吧。这事都多久了？不过是段代码。它造成的后果根本不算什么。又不是治好了癌症。
我也这么看待自己的代码，它对我而言并不珍贵。但我绝不会妄断他人作品被窃后的感受(我用“窃取”这个词，因为我确信格雷先生就是这么想的)。
人们的想法或感受，并不代表其合理性(更谈不上明智)
在LLM编码引擎盛行的今天，代码剽窃已成多余概念。可以肯定的是，总有某个协同编程工具在用户机器上抄袭他人代码，而双方对此浑然不觉。
这与明知故犯地拿朋友或前同事的代码，顶上“署名”再分享给外人完全不同
[已删除]
有人渴望因“工程成就”或“社交工程”被铭记，有人则执着于成为公司十年以上的月度员工。
这两者都是彻头彻尾的浪费时间
比起追逐虚名、参与职场政治、成为大公司编号470293的员工，亲手将创业公司做大到数百万规模才更令人钦佩。
但我预言，那些大型AI公司的从业者终将重蹈覆辙。
精彩博文，追随Addy多年。好奇他如何兼顾谷歌领导职务与撰写如此有价值的博客。
不解为何此评论遭负评！
我长期关注他并受益良多。同样好奇这些“科技意见领袖”如何规划日程，渴望了解更多。
最近我发现自己难以静心完成有意义的工作，总被通知和问题打断。过去一年因大型语言模型处理耗时过长，这种情况愈发严重。
真想知道顶尖人才如何安排时间。
真正的教训似乎是：别在谷歌耗上14年
不过他肯定赚翻了
他不仅赚得盆满钵满——奥斯曼尼更开创性地构想出博客的宏大愿景：将人类核心创作与AI智能体相融合。
用他自己的话来说：“鲜有人能像他这样推动网络发展并激励开发者，这份遗产将长久流传。”来源：https://addyosmani.com/bio/
天啊。我从未见过如此恶心又尴尬的个人简介页面，简直令人作呕到像在看讽刺剧本
> 同事们常称赞奥斯曼尼的谦逊
笑死！谁能面不改色地写这种自我吹捧？！
这也证明把别人的功劳据为己有完全是他的惯用伎俩。
> 奥斯曼尼的团队创建了Workbox——一套用于生成服务工作者脚本的库，能轻松处理缓存和离线功能。Workbox简化了原本需要编写低级代码拦截网络请求的复杂任务。
不，杰夫·波斯尼克(严格来说他当时在阿迪团队)才是Workbox的创建者，自他离开谷歌后该项目基本被弃置。
我不得不认为，他履历中其余内容及其职业生涯都是建立在窃取功劳的基础上。他向来让我反感，这番事迹印证了我的直觉。
真是个精神病！
用第三人称谈论自己有点怪
> 这份遗产的影响将持续很久
没错，就是用无限量的“AI”垃圾污染互联网直至彻底失效的遗产
我不太明白你为什么会得出这个结论。能解释一下吗？
我突然想到用这个问ChatGPT 5.2：
基于https://addyosmani.com/blog/21-lessons/这篇文章，找出一个简短要点列表，概括并涵盖他所有课程内容
回答：
以下这份简短的“总括清单”仍涵盖全部21条经验(每条要点都刻意承担多重功能)：
近期对AI的痴迷严重损害了HN的信噪比。本文作者明显用大型语言模型生成大部分内容，读起来就像LinkedIn上泛滥的标题党。随后某评论者又贴出由模型生成的文章要点摘要，完全没给讨论增添价值。
作者其实提出过值得探讨的简单观点，但这些真知被大量无意义的垃圾内容掩盖了。
文笔相当出色。
我猜这和信息质量高度相关。
全文充斥着LLM的典型特征，文字风格是平淡无奇的AI产出。
你怎么知道？
在第一条中，LLM不会使用不完整的句子片段吗？
我猜它能被训练成模仿特定写作风格。AI辅助？行吧。但呃——难道只要出现破折号就暴露是AI垃圾文本？(讽刺的是这篇文章里根本没破折号)
编辑：下方讨论确实暴露出破绽。https://news.ycombinator.com/item?id=46490075 ——确实存在AI痕迹。不过我仍认为其行文结构相当出色。
> 这不是X…而是Y。
这个我永远忘不了。
再看看他的简介：https://addyosmani.com/bio/
> 他的故事不仅关乎编写代码，更在于激励整个社区为更美好的网络而奋斗。而最激动人心的篇章或许正在书写——他正引领人工智能与网络在未来十年的交汇方向。鲜有人能像他这样推动网络发展并激励开发者，这份遗产将长久流传。
这篇博文是AI生成的，至少有AI辅助。
Hacker News讨论串中大量回复读起来也像AI回复。我认为我们所知的互联网已然消亡。约100%的内容将由机器人为约100%的机器人受众创作
这份清单很棒。内容原创，足见作者确有真才实学。
这里几乎没有任何原创内容。这些都是你能在任何同类文章里看到的陈词滥调。事实上，你最爱的超大规模语言模型(LLM)也能从它的训练数据里给你同样的“教训”。
你最爱的超大规模语言模型(LLM)大概能复现整个讨论串，那还有什么意义呢？对吧？