本文由 AI 分析生成
建立時間： 2026-03-27 來源： https://addyosmani.com/blog/21-lessons/
Summary
Addy Osmani (Chrome/Google, 14 years) distills 21 lessons about what actually matters in large-org engineering — none about specific technologies, all about patterns that appear across projects: solving user problems backward from need, getting to alignment (not just being right), shipping over perfection, clarity over cleverness, and making impact legible to others. Written on departure.
Addy Osmani（Chrome/Google，14 年）提煉 21 條在大型組織工程中真正重要的事——沒有技術細節，全是跨項目反覆出現的模式：從用戶問題反向推導、達成一致（不只是正確）、出貨優先於完美、清晰優先於聰明、讓影響力對他人可見。
Key Points
- #1 User obsession beats solution love: start from problem → solution, not technology → justification. “The engineer who starts with a solution tends to build complexity in search of justification”
- #4 Clarity is seniority: code is a “strategy memo to strangers who maintain it at 2am.” Optimize for their comprehension. Cleverness is overhead
- #5 Innovation tokens: each org has a small “innovation token” budget. Spend one each time you adopt something non-standard. “The best tool for the job is often the least-worst tool across many jobs”
- #6 Code doesn’t advocate for you; people do: in large orgs, impact is invisible unless someone can articulate it when you’re not in the room. This isn’t self-promotion — it’s making the value chain legible
- #7 The best code is code you never had to write: celebrate deletion. “What would happen if we just… didn’t?” is often the right question
- #11 Abstractions move complexity to on-call: every abstraction bets you won’t need to know what’s underneath — something always leaks. Keep a working model of underlying failure modes
- #13 Glue work is priceless and invisible: documentation, coordination, onboarding — vital but career-stalling if done unconsciously. Timebox it, turn it into artifacts, make it legible as impact
- #15 Goodhart’s Law: “When a measure becomes a target, it stops measuring.” Pair every metric with a quality/risk counter-metric
- #19 Process reduces uncertainty, doesn’t create paper trails: best process makes coordination easier and failures cheaper. Worst process assigns blame
Insights
The most surprising lesson for engineers from technical backgrounds is #6 — that code doesn’t advocate for itself. In small teams, good work is visible. In 10,000-person organizations, decisions are made in meetings you’re not in, using summaries you didn’t write, by people with 5 minutes. Visibility is not optional; it’s the actual mechanism by which impact propagates.
Lesson #5 (innovation tokens) is probably the most actionable architectural guidance: it provides a decision heuristic that isn’t “is this technology better?” but “is this where I’m uniquely paid to innovate?” The answer is usually no.
Connections
Raw Excerpt
The engineers who thrive aren’t necessarily the best programmers — they’re the ones who’ve figured out how to navigate everything around the code: the people, the politics, the alignment, the ambiguity.