在目前的公司剛待滿四年，因為是新創公司，人員規模較小，前面的三年都是獨立開發，一直到了去年，才有另一位相同部門且負責相同產品的同事。

初來乍到，前面的幾個專案中，花了不少時間帶著他熟悉整體程式碼的結構以及一些實作細節，所以基本上都是由他撰寫程式碼，而我負責審核。

這位同事的背景跟我很不一樣，我是一路大學、研究所都唸的是資訊工程，而他是自學程式設計，正是這個差異，讓我們之間有了不少火花。

某次審核他的程式碼時，看到下面這段，腦袋中充滿了各式的疑惑。

1
if (condition == false) { ... }

「為什麼要寫 == false？」
「不是寫 !condition 就好了嗎？」
「他是不是不知道怎麼用 !？」

我嘗試在提出改成用 ! 的建議，這個建議非但沒有被採納，反而得到了令相當訝異的回覆。

「用 == false 比較好讀懂，用 ! 很容易漏看。」

這是我進入職場之後，少數幾個具有啟發性的時刻

只有自己寫程式的時候，完全不會在意這樣的事情，自己寫、自己看，非常難看到自己的盲點。

簡單易懂的程式碼容易維護，但看起來就是不夠「精明」。許多程式設計師喜歡比拼「誰寫得短」、「誰用了比較炫的語法」等等，我曾經也是這樣的人，但這些習慣都極有可能造成程式未來不易讀懂，也就變得更難維護了。

在被點醒之後，我開始鑽研如何寫出「精簡」的程式碼，發現其實真的相當不容易。最洗練的程式碼的產生過程往往需要經過抽象化，再反向的把抽象化的結果用最簡單的方式呈現。

學習如何實踐的過程，有發現一些還不錯的資源，其中一個我覺得相當受用的訪談，就在討論如何用最直觀的方式表達你的邏輯。

這次的學習經驗很寶貴，完美地呈現了「教學相長」，我一直以為我是在教他，但其實真正學到東西的是我。

程式設計是一條漫長且孤獨的路，每位程式設計師都是走在自己獨一無二的路上，每次的相遇，都是寶貴的學習機會，值得好好把握，共勉之。