Oct 1, 2016
Learn how to learn — Diffuse and Focus
同事問了一條有趣既問題：If you can learn one thing instantly, what would that be? （如果你可以「秒懂」一樣東西，那會是甚麼？）
我答：如果我可以學懂一種方法，可以「秒懂」其他東西，那不就是最好的選擇？
最近的確在學習「如何學習」。https://www.coursera.org/learn/learning-how-to-learn/
只是第一個星期已經讓我大開眼界，其中有一個有趣的短片提及一位寫作高手是如何寫作，我卻嘗試將她所指出的問題，放進到Software Engineering 的世界哈哈。
她指的問題是，我們一直學習寫作的方式，特別是在中學時期，都經常教我們：先寫大綱，再寫文章。但她卻發現這一種方式就像是預備吃飯的時候，一邊放碟子上枱，一邊做清理的樣子，最後你就吃不了一餐飯。文章要寫得有趣，需要在寫作前多一點「發散」，而她選擇的方法是 Mindmap 。
最近就發現到自己在寫 Code 的過程中，有時候會出現同樣情況。我會一路擔心這個寫法會唔會行得慢，好像那種做法又有些優點，現在的寫法又有一種缺點，應該要提前做多些 Design 先再開始嗎？
結果就容易導致不斷的修改，同時又想不斷的完成某一功能，但時間卻因為不斷在兩種思緒之間掙扎和跳脫，結果得不償失：時間又過了一圈。
在這個 learn how to learn 的 online course 中，其中我學到的是大腦思維，並不能同時讓「發散」和「集中」並存。我的了解就是一心不能二用。
如果在寫 Code 的過程缺乏單一目標，經常在 coding 的過程又要想像 Performance Optimization，又要兼顧 Error Handling，又要 implement 實作功能，只會對你寫 Code 的效率大打拆扣。
我自己的做法會是嘗試用 TDD 的策略。
Red - Green - Refactor!
嘗試在實作的過程前，寫好測試，便容易規範自己的目標就是處理一件小事，不讓自己作出他想，達致高度「集中」；如果見到有問題的地方，簡單加上 TODO 或者放入 github issue 作紀錄；到 refactor 的階段便開始作出「發散」模式，嘗試想像有那些改進的空間，才開始整理你覺得有問題的地方。
即使是不用 TDD 的你，我覺得能夠成功將「集中」和「發散」兩種模式，在同一時間只用一種，便能提昇效率。
放到 Business 思維下，又有一種有趣的想法。不過這想法很大膽哈哈。
在我的觀察中，不少人覺得 Business 是一種可以靠邏輯運作，越 Make Sense 就越好。
我想這種想法，只是偏頗於以常見的方式了解商業邏輯，但事實上是很多商業邏輯都不能單靠正常邏輯思維了解。
意思就是指，如果我們太依賴自己平日接觸的東西，就誤以為那些東西是合理和正常，我們就像是依賴「集中」的思維模式去思考和解決問題。「集中」有其好處：如果兩個問題具有很大相近性，用相同或相似的做法去解決問題，自然就是少了風險，甚至更快的解決問題。
但往往在商業範圍中，我見到的會是完全跳脫日常生活所了解的東西。而這一種商業邏輯，我覺得是著重「發散」的思維模式才能出現。
例如 Zappos 這間大公司，曾有一段時間靠 drop shipment 這做法，佔了公司不少比重的利潤，但也選擇放棄整個 drop shipment 模式，而選擇自己管理倉務和運輸，結果利潤不跌反升。公司可能因為少了一個 drop shipment 增加了價格上昇的壓力，又對買家、客戶增加了相應的負面感，但為何他們會選擇這條路？
又有沒有公司覺得因為不能得失客戶，而選擇維持現狀，只懂「增加」而不選擇「移除」？
這，又是另一個故事了。
