21 Lessons from 14 Years at Google by @addyosmani. 14 More lessons from 14 years at Google

  • 好的工程师要痴迷于(obsessed) 解决问题，解决用户的问题，解决核心根本的问题，而不是避免沉迷技术、为用技术而找场景
  • Getting to right together, not just right alone. 通过讨论一起对齐问题和方案，共同推进解决方案的实现。
  • First do it, then do it right, then do it better. 行动优先，拒绝完美主义
  • Clarity code, not clever code. 清晰的代码带来更好的可维护性
  • 避免过度追新，成熟技术栈带来更好的稳定性、可维护性和成本
  • 代码本身无法体现你的价值，主动让别人知道你的价值
  • best code is the code you never had to write, 在开始之前先思考不做会怎样，多思考必要性
  • Compatibility is product 兼容性是产品的一部分，从开始就要考虑到
  • 项目拖延大多数时候并非执行问题，而是协作失败，团队没有对齐导致高成本的做事情
  • Focus on what you can control, 专注于你能控制的事情
  • keep learning lower level things, 过度抽象偏离底层只是转移了问题
  • Learn something better is to try teaching it, 教别人是检验理解的最佳方式，包括和 AI 的对话，本质是梳理清楚自己的思路
  • 注意隐形工作的成本，文档、辅导、协调等
  • When I “win” too easily, something is usually wrong, 其他人可能是放弃和你争论导致你看起来“赢”罢了
  • measure becomes a target, it stops measuring, 量化指标变成目标的时候就失去了本身的意义，比如追求代码行数会导致更多冗余代码
  • 不敢承认 I don’t know 会导致团队更不敢提问、不敢尝试、隐藏问题，带来更大风险
  • 维护良好的长期人脉关系网络，会有更快的协作、更多的机会等
  • Deleting unnecessary work, 优化前先质疑存在的必要性
  • 流程的目的是为了降低不确定性，如果没有，那就说明流程不对，为了流程而做事
  • 权衡时间成本和收益，
  • 积累：持续突破现有技能、反思总结，无捷径可走
  • pick the right problems to solve，不要对所有事情都来者不拒而心力交瘁
  • 会议前明确目的，approve/choose/unblock/inform，并且有明确负责人
  • 有明确时间的才叫计划，它可以不完美，但只要足够具体就能指导行动
  • 快速决策！Slow decisions are the disease
  • 把可靠性像产品一样有清晰的路线图、指标、owner 等，才能真正做好可靠性
  • 沟通并不一定解决协作混乱，用权责界限、清晰的服务接口等来提高协作效率
  • 提出问题的时候，附带一个解决方案更好
  • 避免英雄主义，如果反复出现靠一个人拯救局面，说明团队已然出现问题
  • 让可观测性成为功能的一部分
  • small changes, small commit, small PR. 小型改变会迫使你循序渐进的思考和处理
  • Coordination cost grows faster than headcount. 最好的组织并非拥有最多员工的组织，而是每位员工能发挥最大影响力的组织
  • 系统迁移中技术部分是相对简单的，困难的是设计共存模式，需要考虑如何平滑过渡和减少对业务的影响
  • AI 让品味（what to build, what to delete, what to simplify, what not to ship, and what “good”）成为了稀缺资源，
  • 信任是团队的一种延迟优化手段，当人们信任你时，他们无需开五次会议来批准一项决定。他们会假定你有能力、有善意，并且会坚持到底

text