The Effective Engineer 是 Edmond Lau 写的一本，关于如何让工程师更加高效的书。从前我对这类书，是有点排斥的，总觉得有成功学的味道，内容会比较空洞。但是因为在很多地方都看到有人推荐，同时自己也觉得个人效率到了一个瓶颈，所以就决定给它一个机会。读完之后，感觉没白花我这几个小时。这里简单整理一下我觉得对自己最有启发的一些观点。

Leverage

整本书最核心的观点，就是永远以 Leverage 为导向。Leverage = 产出 / 耗时，也就是单位时间内的产出。提高 Leverage 自然就会让自己更加高效，而方法也很自然，有三种：

  1. 提高产出
  2. 减少耗时
  3. 换一个 Leverage 更高的任务来做

这三个方法从数学层面很容易理解，但是执行起来并不容易。这本书就是围绕了这三个方面来展开的。接下来讲几个比较细节的点。

优化学习

学习的效果，和复利（利滚利）很相似。它是一个指数函数。曲线前期的斜率很小，但是到了后期就会 “火箭发射，轰隆隆隆”。要注意的是，前期的一点点提高，对后期会有巨大的影响。作者也提到了他当时在 Google 花了大量时间阅读内部的代码和文档，看到这，我就痛心疾首，后悔自己在 Google 的时候怎么没有好好利用这么好的学习资源。

任务管理

作者使用 {“重要”，”不重要”} x {“紧急”，”不紧急”} 来区分所有的任务，并强调了重要但不紧急的任务。这种 classify 方式之前就听过很多次了，但是都没有深入了解，看了这本书才明白这么做的意义。我个人性格上的一个缺陷是没法忍受有任务没做完（用我爸的话来说，就是没有大将风度），而这些任务往往大部分都是紧急但不重要的。被这些任务占据了大量时间，导致自己推迟了很多重要但不紧急的，对个人成长有帮助的任务。而这些被推迟的任务实际上 Leverage 更高（见优化学习）。

尽早建立 Feedback Loop

建立 Feedback Loop 本质上也是为了提高 Leverage。通过获取同事，上级的 Feedback，及时修正自己对 Leverage 的判断。这样我们可以一直去选择 Leverage 更高的任务，提高效率。

而由这一点出发，我们可以发现，有更多的执行准则，例如：

  1. 尽早做原型，MVP，来获取 Feedback
  2. 开发时多做 instrument，多收集 Metric，多加测试
  3. 提高迭代速度，尽快上线，A/B 测试
  4. 先做风险最大的部分
  5. 警惕单人项目，多获取 Code Review（这是我个人的一大问题，开发太快，担心老让人 Review 会拖慢自己的开发进度，但是实际上磨刀不误砍柴工）

帮助周围的人成功

个人事业成功的秘诀是帮助周围的人成功。这一点是我之前没有意识到的，但是读了这本书之后深以为然。一个人的力量终归优先。让周围的人成长，将紧急但不重要的任务分发出去，让自己可以去做 Leverage 更高的事情。你可能觉得这么做是不是有点自私？其实，我们要意识到任务是否”紧急但是不重要”是一个主观标准。例如，对一个 senior 的工程师来说不重要的任务，对于 junior 的工程师也许是重要的，因为他们需要更多的训练来累积经验。

从这一点出发，我们也可以发现更多的原则：

  1. 做好新入职员工的 onboard。他们越早适应，就可以有越块的成长（回忆一下学习曲线）。今天自己花几个小时帮助新同事更快熟悉，换来他们日后几年的贡献，孰轻孰重一目了然。
  2. 重视 sharing code ownership。这一点虽然有点反直觉，毕竟成为团队内唯一熟悉某个服务的人，这种感觉好像很好。但是仔细想一想，就会发现不分享 ownership 会导致两个问题：
    1. 对公司来说，你是一个单点故障
    2. 对个人来说，因为你是唯一熟悉这个服务的人，所以大量紧急但不重要的 bug fix 需要你来做。你就没时间去做 leverage 更高的事情了。

重视工具和自动化

这也是老生常谈了。开发工具会暂时的花费时间，但是之后可以大大提供效率。我们在实操的时候要注意：

  1. 重视工具的推广，用的人多，impact 才越大。而提高使用率，则需要尽早建立 Feedback。
  2. 渐进式开发，最开始不要想着一步到位，而是一点一点的优化工作流。这样的好处也是为了尽早获得 Feedback，同时也平衡了和其他任务的冲突。