前言

这篇感觉大家都可以看看，当身为工程师的你，总是思考要怎麽利用程序帮助增加你的效率时，你可以想想，或许除了自动化你还有其他选择。

演讲总结

这篇演讲主要讲的是，你想让工作更有效率，只想着复制自己是不够的，你必须要想新的解法－领导力。

讲者讲到所谓的**技术能力，其实利用自动化你做事的流程，达到复制你自己的目的。**通常你想着是，当我有了这个automation，我可以成倍的增加效率变成N^2，但实际上用同样方法达到的效率，通常只有N2或N3。所以如果你想要增加你做事的效率，你应该想的不只是复制你自己做的事情，而是用截然不同的解法。

为什麽我们会想复制自己？

讲者讲到有两个可行性偏误（Availability bias）导致我们觉得复制自己是很简单的：

1. 人总是觉得，自己会做能做的事情是比较有价值的。
2. 身为习惯用技术解决问题的工程师，会觉得要改进效率，我们就应该使用「技术」的解法，而非采用用「非技术」的解法，不然就会被别人觉得「不够技术」。

但当你看的角度越来越广，做的事情越来越复杂时，你会发现到，基本上大部分做事效率的瓶颈，都与技术本身无关。

因此，如果你想带来更多价值或让你的乘数（Multiplier）更大，你必须采用一些其他的方法，下面便来提供三个方向。

三个有价值的美德（The Three Value）

以下三个美德其实是Perl作者Larry Wall写在Perl的介绍文里的三个美德：

懒 Laziness

工程师是很懒的生物，我们喜欢自动化，就是因为我们懒得手动做某些事情。而自动化不一定要靠机器做到，我们也可以训练别人来取代你自己，一方面目的也是为了让你自己不要成为单点故障（Single Point of Failure）。

虽然对我们来说这可能有个可怕的点是，当你训练了一个人後，他其实可能做的比你还好。但如果你想要继续成长，这却是必须的。

没耐心 Impatience

工程师是种很没耐心的生物，我们讨厌做重复的工。而写flexible跟extendable的code的目的，就是在尽力的去避免未来要不断重复的改code。但比起做重复的工，更重要的应该是你要尽力避免做无意义或低价值的事情。

如果你有debug的经验，你可能会遇到你查一整天，才找到的bug，交给别人可能半小时就找到问题所在了。这中间的差别其实就在於，厉害的工程师他们可以快速的找到bug的问题所在，知道哪些地方是重点哪些不是。但是如果单纯做同样的事情，他们可能也跟你做的一样快。

因此厉害、效率比你快十倍的人，并不一定是因为他们做事有多快，更多是他们能更快速的抓到事情的重点与prioritize那些重要的事情做。

这里其实要讲到一个工程师非常常见的问题，或者说一个两难，就是我们都有个工程师魂。我们想把code写好，想把code写完美，删了又删，改了又改，因此花了一周的时间。但是到最後，deliver出来的value与impact，却跟只花两天最基础的版本差不多。这里想强调的并不是说coding quality不重要，而是你花在tune好coding quality的过程的时间，是不是真的能创造价值的。

这件事情特别发生在新创（startup）之中，因为startup就是个需要快速deliver东西的环境，如果你「过度」强调code质量而忽略更重要的背後的价值，那往往会是拉低你的效率。

讲者也说到对於非技术的人来说，流程是个很重要的东西，因为流程的存在建立了一套「人工的自动化」流程。但流程的问题在於，他无法解决「决策过程」的问题（因为如果可以就会直接被机器取代了），而决策的难点其实就在於prioritization。

所以，你必须要练习当个没耐心的人，找出真正有价值的东西，舍弃没价值的东西，才能真正大幅提高你的效率。

傲慢 Hubris

工程师也往往是傲慢的生物，我们根据我们的第六感去定义事情的好坏。也因此我们常常会抱怨各式各样的东西：「这code不知道在写什麽超丑的」「这function也太难用了吧」「这架构当遇到...状况会有问题吧」。

讲者想讲的是，你应该善用你的这部份傲慢，去尝试把你的code、把你的产品，变成其他人无法抱怨你的形状。抱怨无法改变事情，无法帮助team变得更好，你必须要动手去做，提供更好的解法。而这不只是对於技术上的事，非技术上的流程更是。当你想抱怨某件事情时，想办法提出解法，改变环境，才能帮助你与帮助团队，让後人不要继续抱怨。

影响与影响力的差别

很多人会把影响（Impact）与影响力（Influence）搞混。影响指的是，你的行为会导致直接造成某个後果；而影响力指的是，你提供别人共融（inclusion）而驱使别人来完成有价值的事情。

Manager基本上自带有Impact，因为你要团队成员做事情，大家会去把事情做出来，所以你造成了Impact。但要influence成员的未必要是manager，因为大家受到你潜移默化的影响，而自动的去做出了有价值的事情，那这就是你的influence。

而如果你想大幅提昇你的效率，增加你的multiplier，你该influence别人而不是impact别人。因为influence是永久的而impact只是暂时的。

个人心得

又是一场知名作者Camille Fournier的演讲。这次的重点比较没有像上次那一篇那麽发散XD。我来讲讲我的一些小心得。

自动化只是改变效率的最基本元素

在之前20. 在公司响起革新号角演讲里的有提到：自动化并不是专业能力的表现，创造改变才是。

If you never disagree with anything happening at your company, if you never push for things to be better, then what are they paying you for? If you unquestioningly toe the party line on everything, you're not a professional, you're an automaton. — Kate Taggart

我自己一直以来都很讨厌做重复的事情，所以每当我要做重复的事情时，我都会想写code把事情自动化，不过自动化真的不能有效的解决效率问题，有时候还会带来额外的maintainese effort，如果真的要解决根本的问题，还必须寻求另外的方式。

举个简单的例子，之前有次Project Team想利用ticket的tag来做些filter，但是我们有很多的ticket都还没有某个tag，老板请我帮忙把整个team的ticket都加上去，那我可以怎麽做？

1. 简单行事：我自己手动一个一个加。
2. 自动化思维：我花个半小时写script做些简单的content parsing，然後自动打上tag。
3. 永续性思维：我开个meeting，跟我的成员说做这件事的目的是方便PJ们快速的找到需要被处理的ticket，请大家帮忙，也请大家记得未来新的ticket也要加上去，然後分配下去给大家做。并且也同时也把这件事情记录在使用ticket的document里。

大部分工程师可能觉得2就足够了，现阶段看起来或许是没错。但是你可能也要想到，有code就要maintain，那之後是一直都要你自己来maintain吗？的确2与3可能都是蛮可以的作法，但3还加上了教育成员们与下放责任们。因为2来说，你ticket没加到tag你可以怪罪script有bug，但是3的状况是，大家要意识到做这件事的意义，与承担忘记加tag的责任，所以长远来看应该是比较好的选择。（当然还有很多现实因素，例如人家不听话之类的XD，那就是另一回事了）

只是用个简单的例子说，工程师因为习惯自动化这件事，所以往往也把眼界限缩在看到的问题上，这就是什麽批判性思维如此的重要，因为你要去想真实要解决的问题是什麽，然後去解决他，而不是单纯把其中一小部步骤给优化而已。

做有价值的事情更重要

我对这个主题也深有感触，因为我自认为自己是个非常非常不擅长时间管理的人，在尝试各种时间管理的方法之後，我发现我完全无法做到任何一个XD，但我後来发现对我来说与其找方法做好时间管力，不如去做好prioritization其实是更重要的。这在《高绩效心智》里也有提到这点「双重专注，否则前功尽弃」，其便是在解释priority的重要性。

换句话说，你要想的不是「输出outcome」是什麽，而是「影响impact」是什麽。特别是像工程师如我们，很喜欢做自己擅长、做很快的事情，因为这让我们获得成就感，但是当你时间不够用的时候，这件事就必须要更谨慎思考，到底哪些是真正对你来说有价值，而且无法被delegate出去的事。

其实priority也解释了为什麽我们总是觉得junior花时间在奇怪的事情上，而导致他们做事很没效率。这是因为他们对公司理解还不够深，还无法分出哪些是重要，又哪些是不重要的事情。所以对於junior他们觉得时间管理能力不好时，我都会先请他们想想他们做的事情是不是最关键的，与他们讨论哪些才是真正关键，哪些是可以偷懒或迟些做的。

讲到productivity我想偷推荐我喜欢的Youtuber：Ali Abdaal，他曾经做过一集是在讲他自己在尝试各种productivity tips之後给出的排名，虽然每个人有自己的排名但他的排名跟我自己感觉的蛮像XD 有兴趣可以点下：

不过价值也很难衡量

虽然是这样讲不过有时候也很难拿捏，演讲里有提到startup常常为了快速delivery必须要牺牲code quality，或留下technical debt。我自己是接受这件事，毕竟我的公司S社就是不断的在做这件事XD。但是说真的也不能完全不管coding quality，因为我们想要的不只是现在可以快速delivery，也希望未来能快速delivery，而quality很低落往往也是bug的温床，所以我们可以牺牲品质但又不能牺牲太多，那实际上怎麽拿捏？我自己也无法给出好的解答就是了XD|||。