带着这样的疑问，关注了硅谷大厂程序员的一些博客，同时也阅读了一些软件开发的经典之作，例如《人月神话》、《大教堂与旧集市》、《程序员修炼之道》等。这些内容都是很好的基础，为我软件开发的职业道路，树立了基本的职业价值观。不过今天，要推荐另外一本书《the effective engineer》。本书目前还没有中文版本，作者经历过硅谷的大小厂，Google、Quip、Quora等，从他的角度，总结了一些很有道理的内容。
该书的核心，聚焦在一个杠杆二字。所有活动的目的，都是最大化杠杆的效果。这点和的之前讲的财富38条法则不谋而合。在上次的法则中，同样强调了杠杆的效用。而软件开发领域，本身就是一个高杠杆活动。你开发的软件，可以只供团队内数十人使用，也可以供数以亿计的用户使用。
该系列整体分为三条，咱们逐一拆解。
作者认为，软件开发的核心：不是用了多么炫酷时髦的技术，不是你懂的技术别人不懂（技术垄断），而是解决业务问题。只是恰巧，工程师的角色定位，让我们能够借助软件程序解决问题。
在这个过程中，去聚焦高杠杆活动，充分发挥软件程序的优势。用杠杆率去衡量自身的产出，有计划地增加杠杆的效率。
例如：有没有方法更快完成项目？有没有方法让项目的作用更大？如果不做这个项目，有没有其他杠杆率更高的项目？
优化学习这里的核心观点在于，学习是存在复利效应的。无论外界如何变化，一定要掌握自己的学习节奏。寻找能够提供成长的环境，结合工作中的其他人的能力，提升自己的能力。除了工作内容，工作外的技能也应有所精进。
更迭优先级我们都知道，事情可以根据四象限法则，分为重要紧急、重要不紧急、不重要紧急、不重要不紧急。最后一个能不做就不做，倒数第二个能晚做就晚做。前面两个优先做，重点做。
在这一环节，聚焦能够直接产生价值的地方。如果担心被打扰，则可以设置一个番茄闹钟，以减少场景切换的可能。为了减缓拖延，可通过自我目标设定，自我陈述的方式：”如果，就“来有序安排工作。
在执行上下功夫投资迭代在软件开发领域，有一个著名的MVP理论，即最小可行性原型。该方法除了快速验证假设外，也起到快速迭代的作用。迭代越快，我们能学到的就越多。熟练掌握工作，多在迭代上下功夫。
测量指标没有测量，就没有改进。这是著名管理学理论。在软件开发领域也是如此。当然，衡量程序员的产出，不是靠代码行数或者bug数，而是其实际的产出价值。这也要求我们谨慎地选择衡量指标。理解数字，诚实看待数字。
尽早验证想法一如前面的MVP原则，我们尽早验证想法，通过迭代减少浪费。如果有必要，我们还可以通过A/B测试，来检验实际效果。
项目评估技巧大部分时间，我们也会面临项目周期评估的问题。作者建议，在排期中设立回旋余地。拆分项目，设置合理的里程碑。优先处理高风险的事项，能一定程度保证项目如期交付。如果延期不可避免，则也应该对延期时间有个合理的评估。
构建长期价值实用与质量的平衡多快好省赶紧上，这种思想也会出现在软件开发领域。这本身与快速迭代并不矛盾，但要注意平衡好开发周期与质量的矛盾。CodeReview、自动化测试，能够一定程度减少出错概率。项目发展过程中的技术债，要得到有效管理。不可一味堆叠需求而忽视技术基建。
减少维护成本在项目上线的维护过程中，也需要留意维护的成本。开发代码过程中，将错误有效暴露。同时进行链路上的故障演习，合理安排兜底策略，将有效减少维护成本。
投资团队成长从长远来看，每个人都不可能单兵作战取得巨大的成功，我们需要团队。投资团队成长方面，首先是帮助其他人成功。这可以通过分享自己的经验，写下高质量的文档实现。也可通过CodeReview实现。另一方面，招聘是团队内每个人的责任。招聘高质量的同事，在入职培训和指导方面下功夫，也将获得极大的回报。
小结
以上，是该书的基本框架。总体读下来，对于我还是收益颇多。后续一周，我们将展开讲讲每个环节，结合我自身的工作经历，给读者朋友提供更核心、易懂的理念。
