There are two thinking models — focus and diffuse. And these two methods cannot be used at the same time.

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 增加了價格上昇的壓力,又對買家、客戶增加了相應的負面感,但為何他們會選擇這條路?

又有沒有公司覺得因為不能得失客戶,而選擇維持現狀,只懂「增加」而不選擇「移除」?

這,又是另一個故事了。