《The Effective Engineer》是一本由Dedmond Lau著作，The Effective Bookshelf, Palo Alto, CA.出版的图书，本书定价：247，页数：，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《The Effective Engineer》精选点评：

　　●很实用的一本书，里面有一些方法论可以直接使用，有一些是工作这几年别人告诉过我或者公司就在用的一些内容。如果早点看到这本书就更好了。希望自己可以有一些实践

　　●从「时间是最稀缺的资源」出发，建立了用 leverage（单位时间产出的价值/影响）来指导行动的方法论，然后从多个角度（思维模式、实际执行、长期战略等）论述了如何多进行 high leverage 的活动来最大化自身的 impact，并辅以丰富的真实例子。许多内容都可以推广到软件工程以外的领域。作为 SWE 必读的一本书。

　　●没有学到太多新的内容 所以我应该把读这本书的时间用在更高leverage的活动上

　　●贪心算法实例化。

　　●看到对这本书的评价良莠不齐，但是对于一个职场菜鸟就真的感觉很有收获啊！（是啊我还看得太少）

　　●刚刚读完的一本好书，推荐给每一位开发者！

　　●与我而言, 最有用的两点: 1. change your mindset. Focus on high leverage projects / tasks 2. Learn to prioritize. Prioritize frequently.

　　●【藏书阁打卡】作者首先从何为高效工作以及为什么要高效工作开始谈起，提出High-leverage的概念，即单位时间内产出的价值最大化。然后从迭代速度、目标衡量、A/B 测试、项目时间评估等几个方面探讨了提高工作效率的措施和方法。要是刚开始工作的时候，能够看到这本书的话，工作习惯和工作方法会比现在有很大的改善吧。此外，作者从团队的角度，谈了如何在代码质量和迭代速度之间作出权衡，以及如何进行自动化流程，如何不断提高团队的整体实力。作者的这些经验还是挺有参考价值的。

　　●对职场新人还是挺有用的。其中几个坑去年踩过。要是早学习这本书，就能省下时间

　　●良好且有条理的工作习惯不局限于工程师 而是通用于各个行业的职场 在项目初期尽早建立系统性的计划 验证可行性 工作进行中及时收集反馈 迅捷开展必要的更正 审慎靠谱的风格是一方面 不畏惧可能出现的错误 用开放平和的心态面对调整 更能够提升决策效率 牢记把时间花在刀刃上的简单道理!

　　《The Effective Engineer》读后感(一)：The Effective Engineer —— 如何有效开展技术面试和入职培训

　　本文是 The Effective Engineer 读书笔记系列中的一篇 想要了解更多内容请参考原书中的Invest in Your Team's Growth章节

　　作为一名雇员，你的事业成功很大程度上取决于公司和团队的成就。而公司和团队的成功，依赖的是所有人。因此，建立一个强大的团队非常重要，其中招聘和入职培训是必不可少的两个关键环节，且都具有很大的leverage(单位时间里的影响力)。

　　招聘是每个人的责任

　　招聘的重要性不言而喻，尤其是在小公司，你面试的人更有可能成为你的直接同事。但很多时候，我们意识不到这种重要性。

　　一些技术人员身上有一个误区——凡是非技术性的事情都与我无关。他们宁愿把时间用来写代码，也不愿意花在面试招聘上，甚至会对面试这件事产生厌烦。即使勉强去组织面试，他们的重点仍然是在如何让候选人证明比自己优秀。其实，如果能够招聘到一个合适的候选人，产生的影响力远远大于多写的那点代码。

　　一个好的面试有两个目标：首先是寻找适合的候选人；其次是让候选人对团队使命和文化感到兴奋。理想情况下，即使候选人最终没有拿到offer，但因为公司留下的好印象，也会推荐其他合适的朋友来参加面试。

　　在书中，作者提出了一系列行之有效的建议用于改进面试流程和提高面试效率：

在开展面试之前，与团队其他成员探讨确定在候选人身上的重点考察点，包括而不限于编程天赋，对编程语言的掌握，算法，数据结构，产品思维，debug能力，沟通能力，文化适应能力或其他品质，确保面试过程涵盖所有的考察重点。在招聘过程中，适时反思讨论现有招聘和面试流程的有效性设计有难度层次的面试问题 —— 随着考察的深入，通过增加或删减条件，将问题引申到不同的难度等级适度把控面试进程，不要让候选人在一个问题上卡壳或停顿太久——你可以适时给出提示或者转移到另一个问题在面试开始时的热身阶段，可以快速问一些能够简短回答的问题，根据候选人的回答来确立进一步考察的范围偶尔邀请其他成员一起面试，了解一个候选人在不同面试官心中的评分，有助于校准最终评分以及探讨如何改进面试流程可以采取一些非常规的面试方式，如果它能够帮你筛选出符合标准的候选人

　　设计入职培训流程

　　对于新员工来说，入职培训流程决定了他对于公司的第一印象，因此入职培训也是提升团队整体有效性一个leverage point(杠杆点)。

　　作为一名工程师，你也许会怀疑为什么帮助新人入职能给你自身带来收获。其实原因正如之前所提到的，对团队成功进行投资也就是对你自身投资。一个更强大的团队意味着更轻松的code review，更多人可以修bug，以及更多的机会去应对更复杂的问题。

　　入职培训通常有几个目标：

让新人能够更快上手开发传达团队文化和价值观，比如data-driven培训与公司现有业务或技术栈相关的基本知识，确保新人们站在一个统一而坚实的起点介绍新成员给团队熟悉认识，建立友好的工作关系

　　设计一个好的入职培训流程是一个不断迭代的过程。也许最开始你仅仅只是写了开发文档告诉别人如何配置开发环境，后来你觉得做一些入职培训的讲座更高效，之后你决定为公司入职制作一本电子指南。但可以肯定的是，一个让新员工手足无措的入职培训不是一个好的入职流程。

　　本文首发于subtleWorks

　　《The Effective Engineer》读后感(二)：希望新的一年里，做一个有效率的工程师

　　其实这本书主要是写给程序员的，或是如何提高一个程序员团队的效率。作者在大(google)中（quora）和start-up互联网公司都工作过。可以说是行业中的老兵。这本书是作者多年工作经验的总结。

　　虽然大学和研究生的专业都是CS，也曾经做了3年C程序员，现在已经丢下老本行很多年了。有时候走过研发team的工位，看到他们在码代码不自觉的凑过去看几眼。作为一个曾经不称职的程序员，看到这本书，反思自己走过的弯路。深感惭愧。更惭愧的是虽然不coding了，还是在继续犯着这样那样错误。书中的一部分内容也适用于现在的我。希望新的一年里，改进自己，做一个更好的工程师。

　　作为非程序员的底层工程师，书中对于公司和团队高度的效率提高（招聘新人，培养新人，提高整个团队能力，代码和项目管理，降低运营成本等）我不关心。从individual的角度来看，从这本书中得到有助于我的观点有：

　　1. 时刻告诫自己，时间才是最有有限和最宝贵的资源。Time is our most finite asset, and leverage—the value we produce per unit time—allows us to direct our time toward what matters most。

　　具体实现：不要在工作时间做与工作无关的事情，尽量不参加少参加无用的会议。回想有时候参加一个讨论会，很多人都不来，以前我不理解为什么这些人不来，读过这本书理解了。不要把会议邀请当作必须去的义务。

　　2. 不是所有的任务都是等同的，在一些任务上花费的时间可以得到更多的效益。反之于事无益。需要在工作中能够辨别哪些任务是关键性的（对项目同时也对自身能力提高），哪些不是。

　　具体实现：给任务排优先级，如有可能尽量丢弃非关键性的任务。对于没有挑战性的任务尽量不去take。因为take这些任务的同时，你丧失了一个解决新问题，学习和提高的的机会。比如我在某个领域很熟悉和精通，领导也喜欢让你take这样的任务。以前我喜欢做顺手的任务。但是再想想，我是能很轻松的完成，但是从中能够学到什么呢？能力有buildup吗？

　　3. 把自己当作一个创业公司，push自己去完成任务。但是不要push的太狠了。找到自己的节奏，把工作看作一个马拉松，找到适合自己的pace。

　　具体实现：有时候只是为了完成任务而完成任务，工作中不思考。也没有固定的节奏。如果工作完成了就松弛，如果没有就忙。也没有一个（个人能力提高)长远的打算。这样是不对的。时刻问问自己我今天的工作中能力有提高吗？对将来的发展是否有所帮助？也不要把自己搞得太累或者太轻松，打持久战。

　　4. 尽量为任务保留大块的时间，不被打扰。

　　具体实现： 做好计划，不要被一些杂事所打扰。杂事用小块时间来处理。以此来提高效率。

　　5. 避免重复工作。如果一件事情要做两遍以上，考虑用工具来解决。

　　具体实现： 每次完成的case要有结果和记录过程。特别是可复用的部分要保留。重点在一些典型的cases。两次遇到同样的事情，就要提醒自己，如果第三次第四次出现的话，我是否可以用上可重用的部分？如果没有的话，马上去做。虽然会非一些时间去做可重用的部分。长期看是合算的。

　　6. 不要怕犯错误，出错要趁早，问题要及早发现

　　具体实现：不要把问题留到最后或者试图找workaround甚至掩盖。不要有侥幸心理。不要怕麻烦。及时暴露问题。

　　7. 对于自己项目至少要有简单的管理。要有任务的目标和里程碑。项目必须是可评估可质量进度可测量的。

　　具体实现：简单的管理任务，做自己的PM。衡量任务的质量和进展情况并即使的做出反应和调整。PM是站在项目的角度上来看问题。但是作为工程师，也要有自己的管理。不能被PM牵着走。

　　8. 通过review或者其他方式尽快得到反馈，越快越好。

　　具体实现：不必在任务完成时才review，可以是在task的任何阶段，哪怕是找一个同事做over-shoulder的review。也比没有反馈好。找对这个领域比较了解的同事。最好是没有保留乐于指出你的缺点的。避免自己在项目中想当然做出低级的错误。

　　9. A/B测试

　　具体实现：对于拿不准的方案，如果有条件可以做一下A/B测试。最小的代价得到一些数据结论。考量最坏的结果而不是平均的结果。

　　10. 尽量准确的估算项目的进展

　　具体实现：这是工程师的弱项。上月的站会上leader问一个task多长时间完成时，工程师说2周，项目经理认为1周就可以完成。但实际上3周了还没有明显的进展。可能只完成了20%。书中提供了一些方法，比如根据项目进展情况，及时调整等。

　　11. 尽量早做计划。An effective engineer knows to plan ahead.

　　具体实现：目前圣诞节期间因为国外放假，所以这阶段的任务比较少。可是实际上可预料到2，3月份的项目。可以早做打算。做好前期的工作，有利于减轻后续的负担。

　　12. DIY（Don’t Repeat Yourself）Principle。 不要做重复的工作。

　　具体实现：事实上工作中难免会遇到这样的任务。你只是个工程师没法挑活。遇到重复的工作，尽快完成，move on。。。

　　13. 不要欠债，有债必还

　　具体实现：了解自己欠的债在哪里，时刻提醒自己。不要等必须完成的那天再payoff。虽然书里讲的不是这回事。

　　14. 从简单的事情做起

　　具体实现，不要想一开始就建个复杂的模型，先想想完成这个task，最简单的方式是什么样子的。也要考虑到未来维护的负担。

　　目前能够想到的就这些了。最最重要的，时间是你最宝贵和有限的资源。怎么用，就看你了。

　　《The Effective Engineer》读后感(三)：Notes on The Effective Engineer

　　入行近两年，工作过两个组，时常还是在burnout的时候困惑自己是否是一个合格的代码生产者，在不断的reorg间，怀疑自己做的项目是否真的有价值，如何能做一个开心且有效率的工程师。这本书也是作者思考这个问题搜集的资料和自己的思考，读的过程中好多坑也是自己亲身走过，想疯狂点头表示+1，合上书后投入到日常工作中，没过多久焦虑和不知所措又重新涌上来。下次burnout/不想工作的时候可以回看这篇书里节选的notes吸取一点阳光。

　　（PS. 疫情前从library借走10本书简直是今年做过最好的决定，拖延症总是高估自己的阅读速度，之前两周的checking out period经常看到一半就需要还回去，这次county图书馆无限延长借阅时间简直不能太开心）

Part 1 Adopt the right mindset

　　# Leverage #

　　- High-leverage activities behave similarly, letting you amplify your limited time and effort to produce much more impact.

　　- 3 questions to ask:

　　1. How can I complete this activity in shorter amount of time？

　　2. How can I increase the value produced by this activity？

　　3. Is there something else that I could spend my time on that would produce more value？

　　- 3 solutions:

　　1. automate parts of development/testing process that thus far done manually

　　2. prioritize tasks based on how critical they are for launch so that you maximize the value of what you finally ship

　　3. talk with customer support to understand value

　　# Growth mindset #

　　- own your story: write your own story instead of letting others define it

　　- capitalize on opportunties at work to improve your technical skills

　　- locate learning opportunities outside of the workspace

　　- study code for core abstractions written by the best engineers at your company

　　# Prioritize Regularly #

　　- understand # of projects you can work on simulatneously; resist urge to take more (reduce context switches)

　　- build routine to manage and execute on your own priorities

　　- make if-then plans to combat procrastination

　　- work on important and non-urgent (prioritize long-term investments that increase effectiveness)

Part 2 Execute, Execute, execute

　　- optimize iteration speed: identify biggest bottlenecks and figure out how to eliminate them.

　　- optimize your debugging work flow

　　- invest in tooling

　　# Metrics #

　　Good metrics

　　1. help you focus on right thing

　　2. drive forward progress

　　3. help guard against future regression

　　4. measure effectiveness, compare leverage

　　# Data integrity #

　　- log data liberally, in case it turns out useful later

　　- build tools to iterate on data accuracy sooner

　　- write E2E integration test to validate entire analytics pipeline

　　- examine collected data sooner

　　- cross-validate data accuracy by computing same metric in multiple ways

　　- when a # look off, dig into early

　　# Validate ideas early and often #

　　- optimize for feedback asap, understand what user actuallly want and iterate on that feedback

　　- create a feedback loop (soliciting regular feedback)

　　# Improve project estimation #

　　- budget for unknown

　　- do the riskiest tasks first

　　- reduce risk early: stub out incomplete module & assemble E2E system ASAP

　　- think of estimate as probability distribution

　　- beware of anchoring bias (ignore timeline your manager gives you first)

　　- define specific project goals & measureable milestones (sharded)

　　# Rewrite projects with caution #

　　- add new features to new or old system

　　- Frederick Brooks "second-system effect: difficulties in rewriting"

　　- convert a large rewrite project into a series of smaller projects

　　- using an incremental approach may increase overall amount of work but dramatically reduce risk is often worth it

Part 3 Build Long-term value

　　# Balance quality with pragmatisim #

　　obby Johnson (director of FB engineer): "Instead of right/wrong. Look at it from work vs not work"

　　- To the point where the processes provide deminishing returns on quality and actually reduce effectiveness.

　　- Manage complexity through abstraction: create an abstraction too early, before you have a firm handle on the general problem you're solving, the resulting design can be overfitted to the available use case.

　　# Technical Debt #

　　- Since our initial understanding of problems always will be incomplete, incurring a little debt is unavoidable; it's just part of getting things done.

　　- The key to being a more effective engineer is to incur TD when it's necessary to GTD for a deadline, but to pay off the debt periodically.

　　- lightweight mechanism to pay off technical debt "Fixit week: with theme

　　# Minimize Operational Burden #

　　- keeping a system up and running, scaling a feature to support more users, fixing bugs, transferring an ever-growing body of institutional knowledge to new engineers --- all of these costs continue to tax a team's resources, even after a feature or system ships. When team is small, minimizing that tax is critical.

　　- Steve Job on iPod: When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can oftentimes arrive at some very elegant and simple solutions. Most people just don't put in the time or eneergy to get there.

　　- Mike Krieger, Instagram CTO. Pick solid & proven technologies instead of new ones

　　- "Do Simple thing first" mantra/core engineering tenet

　　- Fail fast

　　* crash at startup time when encoutnering config errors

　　* Validate software inputs early

　　* bubble up an error from external service you don't know how to handle

　　* alert engineers about any invalid or inconsistent program state as early as possible

　　* a lot of catches may not technically good slowly faling system. Make it difficult to discover what went wrong.

　　# Automate Mecahnical tasks #

　　- automatic mechancis

　　- automate decision making

　　# Batch process #

　　- ｓｃｒｉｐｔs executing a sequence of actions without human intervention

　　- "idempotent"

　　* make each process either fali entirely or succeed entirely

　　* the ability to run infrequent process at a more frequent rate than strictly necessary to expose problem sooner

　　- run batch process more frequently (a system check every 5 minutes to 10 minutes is not as good as every 60s and watch for consecutive failures)

　　- Netflix: Chaos Monkey actively wreak havoc on their own system, develop the ability to recover quickly

　　# Good interview process #

　　- screen for the type of people likely to do well

　　- get candidate excited about team/culture/mission

　　《The Effective Engineer》读后感(四)：读书摘要

　　高效的工程师是那些被认为可以把事情搞定的人。同时，是可以高效率的把事情搞定的人。

　　高效工程师聚焦在价值和影响力上。

Part 1: Adopt the Right Mindsets

Focus on High-Leverage ActivitiesUse Leverage as Your Yardstick for Effectiveness

　　杠杆率 = 产出 / 时间

　　简单的说就是 ROI，投入产出比。

　　时间是最宝贵的资源。

Increase Your Leverage in Three Ways

　　提高杠杆率的三个途径：

减少做某件事的时间增加做某件事的产出换到有更高杠杆率的事情上去

　　翻译成三个问题：

如何缩短完成这件事情的时间？如何提高这件事情的产出价值？有什么值得花费我时间的事情可以产出更多的价值？Direct Energy Toward Leverage Points, Not Just Easy Wins

　　聚焦于高杠杆率的事情

Key Takeaways使用杠杆率来评价你的工程效率有条理的提升你时间的杠杆率集中关注在支点上Optimize for Learning

　　持续优化学习是高效工程师的一项非常高杠杆的活动

Adopt a Growth Mindset

　　拥抱成长性思维，意味着对你可以改变的各个方面都承担责任，而不是将失败和缺点都归咎于你无法掌控的事情。

Invest in Your Rate of Learning学习也遵循指数增长曲线越早优化学习，可以享受越久的复利微小的差异在长期未来也能产生巨大的差别

　　把自己当作是创业或 beta 版的产品，需要每天不断的投资、迭代

Seek Work Environments Conducive to Learning

　　寻求有利于学习的工作环境

　　寻找公司或者团队的六个因素：

快速成长培训开放节奏人自主性Dedicate Time on the Job to Develop New Skills

　　在工作中花时间发展新技能

　　每天花 1-2 小时整块时间。对你长期未来能够更加高效投资。

　　可以对你工作的领域或者使用的工具有着更深刻的理解。

　　也可以获得临近学科的经验。（工作上下游相关其他工种的知识经验）

　　十条建议：

学习公司内最好的工程师的核心抽象代码。特别是在大型公司。写更多的代码。针对提高编码能力，和阅读代码相比，练习是更高杠杆率的活动。浏览内部提供的技术或者教育材料。掌握你所使用的编程语言。将代码发送给最严格的批评家评审。在要改进的地方学习。参加你感兴趣的项目设计讨论会。从事各种各样的项目。确保你所在的团队里，至少还有几个你可以向他们学习的工程师。毫不畏惧的跳入你不懂的代码中。Always Be Learning

　　持续不算的学习

　　学习的机会并不局限于工作场所。其他技能也值得学习。

　　学什么：

学习新的编程语言和框架。在当前高需求的技能上投资。读书。加入一个讨论组。参加一些技术会议、讲座等。建立并维系一些强有力的关系网。关注一些技术博客。写一些东西。做一些业余项目。追寻你所热爱的事情。Key Takeawsys为自己负责不要降低学习速度寻找可以持续成长的工作环境利用工作机会提高技术技能在工作场所之外学习Prioritize Regularly

　　规律性的制定优先级

Track To-Dos in a Single, Easily Accessible List

　　跟踪所有的 TO-DO 在一个单一、容易找到的列表里

　　关注于当前立即可以产生价值的，和重要不紧急的。

Focus on What Directly Produces Value

　　关注当下可以立即产生价值的事情

　　公司关注的是你创造的价值。价值例如产品推进，用户获取，销售额等，而不是开了多少会、写了多少代码。

Focus on the Important and Non-Urgent

　　关注重要但不紧急的事情。

　　我们每天都被紧急的事情淹没：开会、邮件、电话、bug、DDL。其中有些是重要的，有些并不是。

　　重要、紧急：高优问题、DDL 等 不重要、紧急：大多数的 email、电话、会议 重要、不紧急：职业生涯规划、建立了强人际关系、读书、建立新的高效习惯、构建工具以改善工作流、学习新的语言等等

Protect Your Maker’s Schedule

　　保护你的时间表。

　　和其他专业工作相比，软件工程师需要更多长、持续的时间段来提高工作效率。

　　尽可能的将会议安排在连续的时间段或者一天的早晚，而不是分散这些会议。

Limit the Amount of Work in Progress

　　限制同时在进行中的项目数量。

　　人脑的并发处理能力非常有限。

Fight Procrastination with If-Then Plans

　　通过 if-then 计划来避免拖延。

　　例如，收集一系列的 20 分钟内可以完成的短任务，如代码评审、写面试反馈、回邮件、调查小 bug、写测试等。

Make a Routine of Prioritization

　　制定优先顺序。

　　养成重新回顾这些优先计划的习惯。

Key Takeaways写下并 review to-dos做有直接价值的事情做重要但是不紧急的事情减少上下文切换使用 if-then 计划和拖延作斗争养成制定优先级的习惯

Part 2: Execute, Execute, Execute

Invest in Iteration Speed

　　高效工程师在迭代速度上进行大量的投资。

Move Fast to Learn Fast

　　迭代的越快，你能越快的知道这些工作是否有效。

　　持续部署是提供给你用于加快迭代速度的有力工具之一

Invest in Time-Saving Tools

　　节省时间的工具可以带来丰厚的回报。

　　更快的工具会被使用的更多。

　　值得花费一些努力去寻找一个更平滑的方式以便降低从现有工作流切换到新的工具的成本。

Shorten Your Debugging and Validation Loops

　　缩短调试和验证的时间周期。

　　下一次，当你修复一个 bug 或者迭代一个新的 feature，发现自己又在重复进行同样的行为的时候，停下来。想一想，你是否可以缩短这个时间周期。

Master Your Programming Environment

　　熟练你的编程环境。

在版本控制里跟踪变更编译、构建代码跑单元测试重启开发中的 Web Server测试一个表达式的行为查找文档跳到函数定义在文本编辑器里重新格式化代码或者数据找到函数的调用方重新排列桌面窗口导航到文件的特定位置

　　入手点：

熟练你喜欢的文本编辑器或者 IDE：Emacs、VIM or something else学习至少一个高产、高级的编程语言：Python、Ruby熟悉 UNIX 或者 Windows 的 shell 命令：grep、sort、uniq、wc、awk、sed、xargs、find更加习惯于使用键盘而不是鼠标自动化你的手工操作使用交互式解释器来测试自己的想法：Python、Ruby、Javaｓｃｒｉｐｔ使运行单元测试尽可能的快和简单Don’t Ignore Your Non-Engineering Bottlenecks

　　不要忽视你的非工程的瓶颈

　　优化迭代速度的最佳策略和优化系统性能一样：找出最大的瓶颈，然后解决它们。

　　高效工程师会找出并处理这些最大的瓶颈，尽管可能这些瓶颈并不涉及到写代码或者不在他们的舒适区内。

　　一个常见的瓶颈就是对其他人工作的依赖。

　　沟通对于推进与人相关的瓶颈点至关重要。

　　另一个常见的瓶颈类型是获得关键决策者的批准。

　　第三种瓶颈是项目启动之后的审查流程。

　　在大公司，解决这些瓶颈可能超出了你的影响范围，而你能做的最好的事情是围绕它们开展工作。在小的初创公司，你通常都可以直接解决瓶颈本身。

Key Takeways迭代的越快，学的越多在工具化上投资优化你的 debug 工作流掌握你手艺的基础全面了解你的迭代循环Measure What You Want to Improve

　　衡量你要改进的地方

Use Metrics to Drive Progress

　　使用指标来驱动进步

　　如果你不能衡量它，你就不能改进它。

好的指标可以实现许多目标当随着时间的推移而可视化时，好的指标有助于防止将来的回归。好的指标可以推动进步一个好的指标可以让您衡量一段时间内的效果，并将你正在做的事情与可能要进行的其他活动进行比较

　　很难衡量目标并不意味着不值得做。

Pick the Right Metric to Incentivize the Behavior You Want

　　挑选正确的指标来激励你想要的行为

　　指标选择：

最大化影响可行动的反应迅速同时健壮Instrument Everything to Understand What’s Going On

　　监控一切以便理解到底发生什么

Internalize Useful Numbers

　　内部化有用的数字还可以帮助您发现数据测量中的异常

　　了解有用的数字可以明确改进的领域和范围

　　有用的数字：

注册用户数、日活、月活每秒请求数数据存储容量上限每天读写数据量支持一个特定服务需要的服务器数量不同的服务的吞吐量流量的增长率页面平均加载时长产品不同部分之间的流量分布不同的 Web 浏览器、移动设备、操作系统的流量分布Be Skeptical about Data Integrity

　　对数据完整性保持着怀疑态度

　　有时候会混淆相关性和因果关系

Key Takeaways衡量进度小心的选择最高层的指标监控你的系统知道你的数据优先考虑数据完整性Validate Your Ideas Early and Often

　　尽早并且经常性的验证你的想法

　　尽快根据用户反馈来优化

　　尽早并经常验证我们的想法有助于我们完成正确的事情

Find Low-Effort Ways to Validate Your Work

　　找到低成本的方式来验证你的工作

　　一个可行的验证想法的方式是花 10% 的投入构建一个小而又足够信息的原型

Continuously Validate Product Changes with A/B Testing

　　持续通过 A/B 测试来验证产品变更

Beware the One-Person Team

　　当心一人团队

　　建立有效的反馈渠道：

保持开放，乐于接受反馈尽早经常的提交代码评审请求最严格的评审者来评审代码询问同事的想法看法先设计系统的接口和 API投入编码前先展示你的设计文档如果可能，请对正在进行的项目进行结构设计，以便与队友共享一些上下文在投入太多时间之前，对有争议的问题寻求讨论和支持Build Feedback Loops for Your Decisions

　　建立你的决定反馈循环

　　设计实验验证你的猜想，不论好坏，从实验结果中学习

Key Takeaways迭代的去处理问题，以避免浪费投入将大的实现拆分成小模块验证以降低风险使用 A/B 测试来持续的验证你的产品假设当工作在一个独立项目中时，寻求一个定期的外部反馈采取积极的态度去验证你的决定Improve Your Project Estimation Skills

　　项目估期是高效工程师需要学习的最难的技能之一。

Use Accurate Estimates to Drive Project Planning

　　使用准确的估期来驱动项目计划

　　一些策略：

拆分项目成小的任务估期建立在任务需要多久完成，而不是你或者其他人希望多久完成将估期视为概率分布，而不是最佳情况让实际做这项工作的人来估期当心锚定偏差使用多种方式来估计同样的任务警惕神话般的人月：加人缩短不了工期通过历史数据来验证估期使用时间盒子来限制任务的增长允许别人挑战你的估期Budget for the Unknown

　　给未知事物留下缓冲预算

Define Specific Project Goals and Measurable Milestones

　　设定明确的项目目标和可衡量的里程碑

　　明确定义的目标提供了一个重要的过滤器，用于将任务列表中的必须有与最好有分开

　　定义特定项目目标的第二个好处是，它可以在关键利益相关者之间建立清晰度和一致性。

Reduce Risk Early

　　尽早暴露并降低风险

　　如何降低集成风险？尽早做端到端的脚手架和系统整合测试。

Approach Rewrite Projects with Extreme Caution

　　极其谨慎的重写项目

　　有重写经验的工程师，倾向于把大的项目重写分解成一系列的小项目。

Don’t Sprint in the Middle of a Marathon

　　不要在马拉松比赛中冲刺

工作时长增加，每小时工作效率降低和你想象的相比，你可能比计划表落后的更多额外的工作会压垮团队成员增加工作时长会伤害成员的工作热情随着截止日期的临近，沟通的开销会增加最后冲刺会产生大量的技术债

　　当延期时：

确保每个人都了解造成时间表迄今延误的主要原因重新制定现实的时间表如果距离重新修订的时间表很远，随时准备放弃冲刺Key Takeaways将估期纳入到项目计划中项目表中流出缓冲时间定义可衡量的里程碑先做风险大的任务明确加班的局限性

Part 3: Build Long-Term Value

Balance Quality with Pragmatism

　　务实兼顾质量

Establish a Sustainable Code Review Process

　　建立可持续的代码评审流程

　　好处：

尽早发现 bug 和设计缺陷增加对代码变更的责任心建立正面的如何写好代码的样例共享知识提升长期的敏捷度Manage Complexity through Abstraction

　　通过抽象来管理复杂度

通过降低原始问题的复杂度变成一个简单容易理解的问题降低未来的维护成本并且更加容易后续功能迭代解决一个复杂的问题一次，未来就可以使用很多次

　　好的抽象应该是：

容易学习在没有文档的情况下依然容易使用很难误用、用错足够强大以满足需求容易扩展对使用者很合适Automate Testing

　　自动化测试

Repay Technical Debt

　　偿还技术债

　　技术债不会只是在我们做快速、肮脏的变通工作时才会积累起来。每当我们在不完全了解问题空间的情况下编写软件时，我们的第一个版本最终都可能设计得不如我们所希望的那么干净。

　　成为一个高效工程师的关键是在面临 DDL 的时候，可以引入一定的技术债，但同时也会周期性的偿还技术债。

　　高效工程师花费有限的时间以最高的杠杆率偿还债务——代码库中人流密集的部分中花费最少的时间进行修复。

Key Takeaways建立代码 review 的文化在好的软件抽象上投入以简化困难的问题通过自动化测试提高代码质量管理你的技术债Minimize Operational BurdenEmbrace Operational Simplicity

　　高效工程师关注于简单性上。

　　拥有复杂架构设施带来一系列的维护问题：

工程师的专长经验被分散到多个系统上复杂性带来潜在人员的单点故障问题新成员面临着陡峭的学习曲线投入到提升抽象程度、库和工具的资源被分散到不同的系统上

　　可以解决我们的问题并且可以降低未来的维护成本的方案是什么？

Build Systems to Fail Fast

　　快速失败

　　快速失败并不意味着让程序给终端用户崩溃。可以用全局的异常处理，快速上报这些错误，但优雅的给普通用户异常降级处理。

Relentlessly Automate Mechanical Tasks

　　无情的自动化机械任务

　　每次你做了某些机器可以完成的工作，问问自己是否值得自动化这些工作。

Make Batch Processes Idempotent

　　让批处理任务保持幂等性

　　无副作用，可重试

Hone Your Ability to Respond and Recover Quickly

　　磨练你的快速响应和恢复的能力

　　针对主要的故障，最有效的防御措施就是经常失败。

　　建立快速恢复的能力。

　　将时间和精力集中在我们的快速恢复能力上，比起一开始就预防失败，具有更高的杠杆作用。

Key Takeaways先做简单的事情快速失败以便快速找到问题的根源使决策过程自动化旨在实现幂等和可重试计划和练习失败模式Invest in Your Team’s Growth

　　但是，如果您想提高效率，那么重要的是要认识到，建立一支强大的团队和积极的文化具有相当大的影响力。

　　在职业生涯的早期就思考如何帮助您的同事成功，这会灌输正确的习惯，进而养成您自己的成功。

Make Hiring Everyone’s Responsibility

　　让招聘成为每个人的责任

　　良好的面试过程可以实现两个目标。 首先，它筛选可能在团队中表现出色的人员类型。 其次，它使候选人对团队，任务和文化感到兴奋。

花时间和你的团队一起考虑清楚，到底哪些特性对于潜在候选人是你最关心的周期性的回顾讨论当前面试流程的有效性设计面试问题，带有多个层次深度，以便能够适配不同能力水平的面试者控制面试节奏以便获得更高的信噪比通过迅速发出简短答案来探测广阔的表面来扫描危险信号在面试中经常另一位团队成员配对不要害怕使用非常规的面试方法，只要它们能帮助您确定团队所关心的信号Design a Good Onboarding Process

　　设计一个良好的入职流程

　　第一印象很重要。 良好的初始经验会影响工程师对工程文化的理解，影响其交付未来影响的能力，并根据团队的工作重点指导他的学习和活动。

　　入职流程的四个目标：

新工程师尽快提升产出传授团队文化和价值使新工程师拥有成功所需的广泛基础知识通过社交方式将新工程师整合到团队中Share Ownership of Code

　　共享代码的主人翁意识

　　当你成为某个项目的瓶颈时，你就失去了做其他事情的灵活性。

　　策略：

避免一个人的团队互相 review 代码和设计在整个团队中轮换任务保持代码的可读性和质量针对软件设计和架构进行技术演讲文档化。不论是设计文档还是代码注释记录完成工作所需的复杂工作流程或非显而易见的解决方法花时间在教学和指导其他团队成员上Build Collective Wisdom through Post-Mortems

　　通过事后复盘来建立集体智慧

Build a Great Engineering Culture

　　建立伟大的工程师文化

　　伟大的工程师文化：

为迭代速度而优化持续无情的追求自动化建立正确的软件抽象通过代码评审关注高质量的代码维护一个互相尊重的工作环境建立一个共享的代码主人翁意识在自动化测试上投入分配实验性时间培养持续学习和提升的文化雇佣最优秀的人才Key Takeaways帮助周围的同事成功让招聘成为高优先级的事情在入职流程和 mentor 机制上投入建立代码的共享主人翁意识沉淀集体智慧建立伟大的工程师文化

　　《The Effective Engineer》读后感(五)：全书书摘总结

　　阅读更多 https://github.com/gaohailang/blog/issues/3

　　书籍分为三个部分：

　　1 adopt the right mindsets 摆正态度

　　包含了识别和集中精力在 high-leverage activity，为学习而优化，优先级」

　　2 execute, execute, execute 执行的艺术

　　包含了加快迭代速度，为提高而measure衡量，经常和尽早的验证想法，提高项目预估

　　3 build long-term value 长期价值

　　在质量和实效间权衡，减少手动操作，给团队加把力

　　这些习惯来自于reinforced by scientific research, stories from industry, and concrete examples.

　　1 focus on high-leverage activities

　　- use leverage to measure your engineer effectiveness

　　- systematically increase the leverage of your time

　　三种方法： 1 find ways to get an activity done more quickly, 2 to increase the impact of an activity, or 3 to shift to activites with higher leverage

　　- focus your effort on leverage points / direct energy toward leverage points, not just easy wins

　　招聘这件事就是需要花很长时间去做的（Facebook 好几年优化）

　　Employees view themselves as the guardians of high standards, and hiring is a top priority for both managers and engineers. 招聘是头等大事. 高标准的守护者。但有些工程师 view recruiting and interviews as distractions from getting their work done. 如submit feedback immediately, first humnaly-possible time slot 如早上8点中午1点等

　　同样比尔盖茨在慈善事业上也是. global economy worth ten of trillions of dollars, any philanthropic effort is relatively small. 所以需要 way to put in a dollar of funding or an hour of effort and benefit society by a hundred or a thousand times as much.

　　2 optimize for learning 为学习而优化

　　- own your story/adopt a growth mindset

　　集中在自己能改变的事上，growth mindset，把失败看做提升的机会。

　　- don't shorchange your learning rate

　　学习也是复利，越积累越学越快的「easier to apply prior insights and lessons new things，为了长期的发展，早期加大学习的投入~

　　- find work environments that can sustain your growth/seek work enviroments conducive to learning

　　转组前的准备，向同事咨询和找到noboarding的机会，同时看看 how transparent they are internally, how fast they move, what your prospective co-workers are like, and how much autonomy you'll have. 六大因素for supporting high personal and professional growth rate. 1 fast growth, 2 training, 3 openess, 4 people, 5 pace,节奏 6 autonony

　　节奏： • What percentage of time is spent on maintenance versus developing new products and features？

　　节奏： • What tools does the team use to increase iteration speed？

　　eople： • Are there skills they can teach you？

　　openness： • Do teams meet to reflect on whether product changes and feature launches were worth the effort？ Do they conduct post-mortems after outages？ 「迭代的思路去提升而不是一开始就寻求最佳实践等」

　　- capitalize on opportunities at work to improve your technical skills/dedicate time on the job to develop new skills

　　利用工作提供的机会来提升，如阅读你同事好的工程师的代码让他们code-review，参加公司的培训，公司出钱参加的课程和书籍等

　　tudy code for core abstractions written by the best engineers at your company.

　　Write more code.

　　Go through any technical, educational material available internally

　　Master the programming languages that you use.

　　end your code reviews to the harshest critics

　　Enroll in classes on areas where you want to improve. [coursera, edx, udemy, udacity]

　　articipate in design discussions of projects you’re interested in [Ask project leads if they’d mind you being a silent observer or even a participant in a design meeting]

　　Work on a diversity of projects [interleaved practice of different skills is more effective than repeated, massed practice of a single skill at preparing people to tackle unfamiliar problems.]

　　Make sure you’re on a team with at least a few senior engineers whom you can learn from.

　　Jump fearlessly into code you don’t know.

　　- locate learning opportunities outside of the workplace / always be learning

　　每天都提高1%，不必都是工程软件相关的，其他领域的都可以。因为更愉悦的学习者长期有益于成为高效的工程师

　　在工作之外找到学东西

　　- learn new programming languages and framework

　　ew skills can expand your mind and teach you how to think in different ways.

　　- invest in skills that are in high demand 如看看job posting中，看业界潮流，如深度学习和mobile development等

　　- read books

　　ill Gates reads a lot and mostly non-fiction, using books to discover how the world works. 速度2-3x faster提升，同时作者给出了书单

　　- join a discussion group

　　I’m a part of a few book clubs and reading groups that meet regularly for discussion at cafes and apartments.如本杰明富兰克林就参加很多这样的来 discuss and debate morals, politics, or natural philosophy.

　　- attend talks, conferences, and meetups

　　- build and maintain a strong network of relationships

　　Lucky people dramatically increase the possibility of a lucky chance encounter by meeting a large number of people in their daily lives. 书籍 the luck factor 中有

　　- follow bloggers who teach

　　- write to teach

　　帮助你更好的理解你熟悉的东西（甚至帮助你自己reflecting和学习）.

　　- tinker on side projects

　　打磨技术，articularly in areas of interest that you don’t typically engage in at work.跨界.

　　- pursue what you love

　　不要passive time spent aimlessly surfing TV channels or the web.

　　3 Prioritize Regularly

　　- track to-dos in a single, easily accessible list

　　- focus on what directly produces value

　　- focus on the important and non-urgent

　　- protect your maker's schedule

　　- limit the amount of work in progress

　　- fight procrastination with if-then plans

　　- make a routine of prioritization

　　讲grow product's user. 增长团队。 deciated to the art of science of user growth, 优化how users flow into and out a product. 同时 data and metrics数据和指标，同时 run endless user experiments and optimizing conversion rates. 需要结合 engineering, data and product marketing to build their strategies. 和普通工程团队一样需要 building experimention frameworks, and analyzing metrics 同时不一样的是： the list of ideas for driving traffic and growth is extremely open-ended and spans virtually the entire product.

　　最重要的是找到方法让做优先级和todolist成为习惯！

　　rioritizing 很难因为它本身不create anything，而且消耗精力。不需要一直做。但是if have certian personal or professional goals that you want to achieve, prioritiization has very high leverage. - see its outsized impact on your ability to get the right things done.

　　4 invest in iteration speed

　　- the faster you can interate, the more you can learn

　　- invest in time-saving tooling

　　- optimze your debuging workflow [don't underestimate how much time get spent validating that your code works]

　　the extra investment in setting up a minimal debugging workflow can help you fix annoying bug sonner and with less headache. 建立最小可用debug流程帮助快速进入诊断问题

　　- master the fundamentals of your crafts [development environment 熟悉开发环境， pay off dividends throughout your career]

　　知道如何在IDE/editor 中完成下面的事情：

　　Compiling or building code

　　Running a unit test or program

　　Reloading a web page on a development server with new changes

　　Testing out the behavior of an expression

　　Looking up the documentation for a certain function

　　Jumping to a function definition

　　Reformatting code or data in text editor

　　Finding the callers of a function

　　Rearranging desktop windows

　　avigating to a specific place within a file

　　其他相关事：

　　Learn at least one productive, high-level programming language.

　　refer the keyboard over the mouse

　　Automate yoru manual workflow

　　Test out ideas on an interactive interpreter

　　Make it fast and easy to run just the unit tests associated with your current changes.

　　- take a holistic view of your iteration loop [don't ignore any organizational and team-related bottlenecks that may be within your circle of influence] 提升公司与组织层面上的如infra，利用你影响力能触达的

　　5 measure what you want to improve

　　- measure your progress

　　ecause it’s hard to measure a goal doesn’t mean that it’s not worthwhile to do so.

　　常常问自己. is there some way to measure the progress of what i'm doing. 如果我做的无法 move a core metric, is it worth doing, or is there a missing key metric？

　　- carefully choose your top-level metric

　　the right metrics functions as North Star.

　　1 hours worked per week vs. productivity per week

　　2 click-through rates vs long click-through rates

　　3 average response time vs 95yh or 99th percentile respopnse times [To decrease the 95th or 99th percentile, however, you’ll need to hunt down the worst-case behaviors in your system.]

　　4 bugs fixed vs bugs outstanding

　　5 registered users vs. weekly growth rate of registered user

　　6 Weekly active users vs. weekly active rate by age of cohort [防止哪种用了不用的人- measure the fraction of users who are still weekly actives the nth week after signing up]

　　a metric that, when optimized, maximizes impact for the team. [whether it’s products sold, rentals booked, content generated, or something else—enables you to compare the output of disparate projects and helps your team decide how to handle externalities]

　　An actionable metric is one whose movements can be causally explained by the team’s efforts. 而不是哪种 page views, registered users count 等「可能是之前的报道引流的」，观察 things like signup conversion rate, or the percentage of registered users that are active weekly over time

　　A responsive metric updates quickly enough to give feedback about whether a given change was positive or negative

　　- instrument your system

　　[The easier it is to instrument more metrics, the more often you’ll do it.] 使用Open-source tools like Graphite, StatsD, InfluxDB, Ganglia, Nagios, and Munin make it easy to monitor systems in near real-time.

　　The first describes a high-level, big-picture activity, whereas the second is about gaining insight into what’s going on with systems that we’ve built. 你的系统需要越多越全面越好的instrument.

　　Once they had some visibility into what was happening, they were able to add caching to bring down load times from 8 seconds down to 2, fix bugs to reduce error rates down from an egregious 6% to 0.5%. 建立dashboard 等

　　They measure everything including “numbers of new registrations, shopping carts, items sold, image uploaded, forum posts, and application errors.” By graphically correlating these metrics with the times of code deployments, they’re able to quickly spot when a certain deployment goes awry.

　　At Google, site reliability engineers use a monitoring system called Borgmon to collect, aggregate, and graph metrics and to send alerts when it detects anomalies.

　　Twitter built a distributed platform called Observability to collect, store, and present a volume of 170 million individual metrics per minute

　　LinkedIn developed a graphing and analytics system called inGraphs that lets engineers view site dashboards, compare metrics over time, and set up threshold-based alerts, all with a few lines of configuration

　　- know your numbers [方便获取数据]

　　- prioritize data integrity [bad data 可能会让你做出错误的决定]

　　譬如 common latency numbers（见系统优化）

　　6 validate your ideas early and often

　　- approach a problem iteratively to reduce wasted effort.

　　拆分到多个MVP迭代特性不要逞强

　　- Reduce the risk of large implementations by using small validations

　　- use a/b testing to continuously validate your product hypotheses

　　- when working on a solo project, find ways of soliciting regular feedback

　　- adopt a willingness to validate your decisions

　　建立反馈机制用于收集数据来验证你工作价值和有效性

　　7 improve your project estimation skills

　　- incorporate estimates into the project plan

　　Don’t let a desired target dictate the estimates.明确特定功能特性上线时间

　　- allow buffer room for the unknown in the schedule

　　- define measurable milestones

　　- do the riskest takes first

　　Reduce variance in your estimates and risk in your project by exploring the unknown early on 先做风险大的来提前暴露出unknown.

　　- Approach rewrite projects with extreme caution

　　- know the limits of overtime / don't sprint in the middle of a Marathon

　　[Work overtime only if you’re confident that it will enable you to finish on time.]

　　8 balance quality with pragramtism

　　- establish a culture of reviewing code

　　- invest in good software abstractions to simplify difficult problems

　　- scale code quality with automated testing

　　大胆重构前先要建立 suite of unit and integration tests. alleviate the fear of modifying what might otherwise be brittle code.

　　- manage your technical debt

　　不要花太多时间在maintain一个软件上。 if you spend all your resources paying off interest on your debt, you won't have enough time left to work on new things. focus on the debt that oncurs the most interest.

　　9 minimize operational burden

　　- do the simple thing first/embrace operational simplicity

　　imple solutions impose a lower operational burden because they’re easier to understand, maintain, and modify

　　When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can oftentimes arrive at some very elegant and simple solutions.

　　- fail fast to pinpoint the source of errors/ build systems to fail fast

　　系统有问题就尽早报错loudly！

　　- automate mechanics over decision-making

　　为什么不把自动化做了？ 短期没时间，能每一次都花10分钟会让人麻木而不去话一小时去构建自动化（其他如lack familiarity with automation tools, individuals act rationally according to their own self-interest but contrary to the group’s best long-term interests）

　　distinguished between two types of automation: automating mechanics and automating decision-making. Automating the right decisions to make, particularly in the context of building systems that can heal and repair themselves when things go wrong, turns out to be much more challenging. 譬如LB一台机器挂了把流量全部导入到另一台会打死剩下的机器

　　Validating that a piece of code, an interaction, or a system behaves as expected

　　Extracting, transforming, and summarizing data

　　Detecting spikes in the error rate

　　uilding and deploying software to new machines

　　Capturing and restoring database snapshots

　　eriodically running batch computations

　　Restarting a web service

　　Checking code to ensure it conforms to style guidelines

　　Training a machine learning model

　　Managing user accounts or user data

　　Adding or removing a server to or from a group of services

　　- aim for idompotence and reentrancy/make batch processes idempotent

　　One technique to make batch processes easier to maintain and more resilient to failure is to make them idempotent. 让脚本执行多次也是冥等的[如网络问题，数据量大奔溃，服务没起来等]

　　erhaps it generates a monthly analytics report, produces a new search index, or archives stale user data. the ability to run infrequent processes at a more frequent rate than strictly necessary, to expose problems sooner.

　　- plan and practice failure modes

　　10 invest in your team's growth

　　- help the people around you be successful

　　- making hiring a priority

　　- invest in onboarding and mentoring

　　- build shared ownership of code / AB岗位

　　When you’re the bottleneck for a project, you lose your flexibility to work on other things. High-priority bugs get routed to you more frequently because your expertise enables you to fix them faster.

　　Avoid one-person teams.

　　Review each other’s code and software designs.

　　Rotate different types of tasks and responsibilities across the team.

　　Keep code readable and code quality high.

　　resent tech talks on software decisions and architecture.

　　Document your software, either through high-level design documents or in code-level comments.

　　Document the complex workflows or non-obvious workarounds necessary for you to get things done.

　　Invest time in teaching and mentoring other team members.

　　- debrief and document collective wisdom

　　去询问 what worked and what didn't work. document and share the lessons so that valuable wisdom doesn't get lost

　　- create a great engineer culture

　　Appendix 作者书单，好的blogger

　　：

　　holy grails

　　idempotent

　　disparate

　　holistic 全面的

　　ack-of-the-envelope calculation 粗略计算

　　rittle 易碎的

　　debrief 询问

　　ramp up

　　measles 麻疹

　　hilanthropic 慈善的

　　jeopardy