<快思慢想>讀書會最後一塊拼圖

原本以為快思慢想讀書會早在6月初就結束了，當時很高興寫了一篇快思慢想讀完啦～～
，然後讀書會的其他組員就開始整理這段時間來整理照片、整理slide，從二月到現在，也差不多過了半年，一個讀書會可以活這麼久實在讓我始料未及。

合併完的slide不加這一份一共有400多頁，幾乎等於快思慢想的頁數，沒有想到合併起來會這麼誇張，或許把這份加進去以後會公開出來給大家看。最近也聽說這本書賣得很好，排行榜也第一名很久了，看到這個現象真的會有種疑惑阿??

買這本書的人都有把它看完嗎?有多少人是因為書評才買的?

我在準備快思慢想投影片的時候，一個章節至少都要看一小時，為了要講到別人聽得懂，至少會看三遍，30頁投影片差不多花一個禮拜時間準備，在聽別人分享的時候，常常會聽到心理學的名詞解釋，像是海馬迴或月暈效應、也有時候會聽到統計的概念，像是常模或抽樣。

有參加讀書會才發現，作者花了整本書2/3的篇幅在埋梗，要是我自己讀，應該讀到一半就放棄了。不知道這些人有多少?再加上前陣子很紅的翻譯事件ptt 文章跟教授的批評，理論上會有更多人棄讀，我想既然算是看完這本書，就跟讀書會的夥伴們討論一下，我們的想法是

雖然翻譯上有錯，但是也都是一些小錯，洪蘭是心理學家、不是語言學家，如果給翻譯社翻譯可能心理學相關的解釋都會錯掉、會被罵更凶。

這本書並不是一本科普書，很硬不好毒，雖然他賣得很好，但有買的人真的看得完嗎？我們可以把它讀完真的很厲害。另一個很難讀的原因，大概是他花了 2/3 的篇幅在埋梗，得到經濟學獎的模型在很後面才出現。縱然有些錯譯，出個勘誤表或者再版時修正不就行了，快思慢想依然是經典。

不喜歡看繁中版的人就看英文版吧，iBook store 有賣，一本$4.99，我也有買

快速切換多國語系

以前我都傻傻的在設定裡面改語系，

現在只要在scheme裡面加一個arguments就可以了，像是

 -AppleLanguages (Japanese)

全部加好就像這樣，需要注意的地方都寫在圖裡

如果同時勾了好幾個，會使用最上面那個的設定：

比如說我同時勾了English、Japanese、zh_TW

因為我把English的排序放在最上面，所以會使用English；

如果我同時勾了German、English

那就會用German語系

Reference:

eng: http://useyourloaf.com/blog/2013/07/22/using-launch-arguments-to-test-localizations.html

chs: http://fann.im/blog/2013/07/23/use-launch-arguments-to-test-localizations/

將社群聚會學到的招式帶入公司內

標題是隨便寫的，上禮拜在cocoahead分享的內容，把我開始寫objC以來學到的遇到的事作一個總結，講了很多：像是app開發的工作流程、在社群聚會上學到的東西整理、需要面臨的挑戰....，最重要的兩點是怎麼把社群學到的工具招式帶入公司，跟激起夥伴創意熱情的一些方法。

雖然我準備了很久，寫了好多頁，但是我並不打算把全部的投影片放出來，提到了很多名字，雖然大部份我是抱著感恩的心態在介紹，感謝各位大大無私的貢獻，教我寫code教我有這麼多工具可以用；但另一方面也開了一些朋友的玩笑，大部分的人都沒有來，我想我還是不要放出來免得日後造成一些誤會。

重點摘要這四張：

下面是開發時的時間軸，會經過哪些成員的排序，有些成員的工作是可以同時進行，我沒有特別標明，但很明顯的mobile developer是最後一道防線（當然有些公司還有QA），這張圖重點是兩條斜線：以UI和mobile 來比較，UI畫完整個app 10幾個View的畫面大概要1~2個禮拜，mobile拿到截圖把他實作出來大概會需要1~2個月。如果製作時要修改什麼功能，像是把fb登入變成fb登入或微博登入都可以，UI只要加一張圖，mobile要作的事可就多了。developer對比Art 花的時間比例倍至少是四倍以上。

這張圖示我從前公司CTO的演講投影片借來的。

是工程師的天賦樹，技能點數點下去以後會變成什麼樣的職業，這張圖一覽無遺。我就從狂戰士轉職成德魯依惹。

我想每個人都可以從這張圖看到一些東西，比如說一樣是工程師，能力卻有高有低，因為工程師的範圍比較大。

值得一提的是，相同title的職業在每家公司做的事可能不一樣，比如說技術PM，有些公司的技術PM不用寫code，有些的要，甚至有些的技術PM會管到業務那一塊，那就更複雜了。要依照自己公司的職業能力分布來畫這張圖。

這張圖是晚上talk的重點，其實光是這張圖提到的這幾項我就可以講半個小時了。被客戶多搞幾次以後就會練出很多應對方法，這張就是在講這件事。生命會自己找到出路、正如胖子會自己找到食物。

追求細節 燃燒熱情，這句現在看起來還蠻驕傲的，我也不過寫了幾年code，講這種囂張的話，那那些寫了幾十年code的老師傅不是要笑死了嗎！
其實我也還在學，追求細節應該要吹毛求疵到什麼地步，我認為的細節是至少要包括UI、api還有module三塊，但如果過度要求細節的話勢必會拖到開發時程，開發時間越久的案子會越容易失去熱情，所以這句話的另一層意思是要如何在app品質跟開發時間中作取捨。

燃燒熱情是指如何透過一些小工具凝聚同事之間的感情，還有把分享的氣氛帶給周圍夥伴。
舉例來說公司內的教育訓練就跟社群上的分享會很不一樣：公司間彼此都很熟，大家都是兄弟，完全不會害羞問問題，公司內講的題目都是大家急迫會用到的，所以（理論上）台下的人對題目都有大概的了解，還有討論時間也會比較長，如果是120分鐘的教育訓練，可能就會配一個小時分享一個小時討論。除了燃燒自己的熱情外，也要激起夥伴之間的熱情。


最後的結論是如何將社群聚會學到的招式帶入公司內？
我有很多推廣失敗的經驗。我後來才學到，不是每篇新招式都適合寄給同事，同事已經有他習慣的工具。應該是要先了解同事平常的工作模式，投其所好，才比較有效。