這篇感覺大家都可以看看，當身為工程師的你，總是思考要怎麼利用程式幫助增加你的效率時，你可以想想，或許除了自動化你還有其他選擇。
這篇演講主要講的是，你想讓工作更有效率，只想著複製自己是不夠的，你必須要想新的解法－領導力。
講者講到所謂的**技術能力，其實利用自動化你做事的流程，達到複製你自己的目的。**通常你想著是，當我有了這個automation，我可以成倍的增加效率變成N^2，但實際上用同樣方法達到的效率，通常只有N2或N3。所以如果你想要增加你做事的效率，你應該想的不只是複製你自己做的事情，而是用截然不同的解法。
講者講到有兩個可行性偏誤（Availability bias）導致我們覺得複製自己是很簡單的：
但當你看的角度越來越廣，做的事情越來越複雜時，你會發現到，基本上大部分做事效率的瓶頸，都與技術本身無關。
因此，如果你想帶來更多價值或讓你的乘數（Multiplier）更大，你必須採用一些其他的方法，下面便來提供三個方向。
以下三個美德其實是Perl作者Larry Wall寫在Perl的介紹文裡的三個美德：
工程師是很懶的生物，我們喜歡自動化，就是因為我們懶得手動做某些事情。而自動化不一定要靠機器做到，我們也可以訓練別人來取代你自己，一方面目的也是為了讓你自己不要成為單點故障（Single Point of Failure）。
雖然對我們來說這可能有個可怕的點是，當你訓練了一個人後，他其實可能做的比你還好。但如果你想要繼續成長，這卻是必須的。
工程師是種很沒耐心的生物，我們討厭做重複的工。而寫flexible跟extendable的code的目的，就是在盡力的去避免未來要不斷重複的改code。但比起做重複的工，更重要的應該是你要盡力避免做無意義或低價值的事情。
如果你有debug的經驗，你可能會遇到你查一整天，才找到的bug，交給別人可能半小時就找到問題所在了。這中間的差別其實就在於，厲害的工程師他們可以快速的找到bug的問題所在，知道哪些地方是重點哪些不是。但是如果單純做同樣的事情，他們可能也跟你做的一樣快。
因此厲害、效率比你快十倍的人，並不一定是因為他們做事有多快，更多是他們能更快速的抓到事情的重點與prioritize那些重要的事情做。
這裡其實要講到一個工程師非常常見的問題，或者說一個兩難，就是我們都有個工程師魂。我們想把code寫好，想把code寫完美，刪了又刪，改了又改，因此花了一週的時間。但是到最後，deliver出來的value與impact，卻跟只花兩天最基礎的版本差不多。這裡想強調的並不是說coding quality不重要，而是你花在tune好coding quality的過程的時間，是不是真的能創造價值的。
這件事情特別發生在新創（startup）之中，因為startup就是個需要快速deliver東西的環境，如果你「過度」強調code質量而忽略更重要的背後的價值，那往往會是拉低你的效率。
講者也說到對於非技術的人來說，流程是個很重要的東西，因為流程的存在建立了一套「人工的自動化」流程。但流程的問題在於，他無法解決「決策過程」的問題（因為如果可以就會直接被機器取代了），而決策的難點其實就在於prioritization。
所以，你必須要練習當個沒耐心的人，找出真正有價值的東西，捨棄沒價值的東西，才能真正大幅提高你的效率。
工程師也往往是傲慢的生物，我們根據我們的第六感去定義事情的好壞。也因此我們常常會抱怨各式各樣的東西：「這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都加上去，那我可以怎麼做？
大部分工程師可能覺得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|||。
iThome鐵人賽
看影片追技術