主要观点：

• 回忆第一份工作，在 cubicle 的金属架上有个蓝色大活页夹，当时写驱动和 Linux 内核模块需参考活页夹中的文档。
• 如今“手动文化”已消亡，不再依赖阅读大蓝色文档活页夹来学习，而是追求让事物尽可能简单以吸引用户。
• 构建好的 API 应遵循最小惊讶原则，包括合理命名、避免无操作和未实现的方法、避免非明显的前提条件、避免“诡异行为”以及获取反馈。

关键信息：

• 2005 年用定制 Linux 内核写机器控制代码，参考“标志性的 Linux 手册页”打印后放入蓝色活页夹，花费大量时间研究。
• 十年间软件界面和学习方式发生变化，不再强调阅读大文档活页夹。
• 最小惊讶原则要求操作结果应基于操作名和其他线索而明显、一致和可预测，否则会让用户惊讶。
• 构建好的 API 要注重命名，确保方法和变量名能清晰传达意图，可让他人检查。
• 写供用户使用的方法时不要有无操作或抛出“未实现”异常的情况，以免浪费用户时间和引起惊讶。
• 注意预条件，避免有非明显的预条件导致 API 使用者困惑。
• 避免让用户经历“诡异行为”，如调用方法时出现意想不到的结果。
• 要始终获取反馈，以避免代码让他人困惑，可从同事和用户处获取意见。

重要细节：

• 提到RTM（Read the Manual）文化的消亡。
• 举例说明违背最小惊讶原则的情况，如数据库驱动的 CloseConnection()方法打开第二个连接。
• 强调遵循最小惊讶原则是构建可发现和受欢迎的 API 的核心组件。
• 提及Liskov Substitution Principle。
• 引用 Einstein 的“spooky action at a distance”并将其应用于软件避免全局状态的使用。