20年軟體工程師的20條忠告(上)
20 Things I've Learned in my 20 Years as a Software Engineer
標題我差點要說成是「開發者的20道陰影😅」…
在看這篇文章的時候，算一算我竟然已有19年的資歷了？！ 所以我想我應算是有足夠的資格，來給這篇文掛個保證：真的是有20年軟體開發資歷的人，才寫得出這麼極具智慧的忠告。 翻譯的比例約是85%，其他的部分則是我的消化內容，若堅持要看原文的，我覺得沒太大問題。他用字不難，文法不刁，很推薦。👍
說在前面
網路上關於軟體開發的忠告很多，雖然從前人的智慧結晶中吸取重要的成功經驗很好，但我們一定要謹記在心的是，任何的忠告都有它適用的環境，沒有任何一個忠告是可以在什麼狀況都通用的。就像一樣是軟體產品，有人會建議你要定價要高一點，才回收得了整個開發成本，但20年後公司在軟體產品的定價要低一點，才能獲取更多的用戶，獲得更大的成功；在開發出指標性殺手級App的公司，後來可能會軸轉(Pivot)開發方向，將所有元件功能開發成微服務(Microservices)，然後也這樣子建議其他的開發者。
若你沒有搞清楚所在的環境是什麼樣子，這些忠告或建議並沒有什麼意義。硬是照著這些早期的忠告，可能只會讓事情變得更糟。僅管這些忠告真的是實務的智慧結晶，但我們仍需記得以現在的環境及視角，來看待這些忠告是否還合宜。在經過小公司和大公司的軟體產品研發經歷後，以下就是經過20年的軟體開發經歷後，我學到最重要的20堂課。
1. 我懂得還不夠多
由於資訊散播成本已幾近為0，而任何一個科技領域深究下去幾乎都是幾十年的經驗積累。僅管軟體開發者幾乎都是終身學習者，但你距離任何一個領域的「專業」，很理所當然地都會是一個很大很長的鴻溝。你越早認清這個事實，越早能擺脫「冒牌者症候群」的困擾，就帶著愉快的心態，去學習及教導別人吧，輸出就是最好的輸入。
2. 軟體開發最困難的，是開發「對」的東西
就算你乍聽起來就是一個老生常談，但對永遠都對新東西充滿好奇心的工程師來說，要專注開發對用戶來說是「對」的東西，簡直就是貶低了他們的價值。這是一定要被校正的觀念，不論面對的環境或問題是多麼的困難或複雜，多麼有挑戰性，只要開發出來的東西，無法讓用戶用來解決問題，那就是沒有價值。
設計軟體本質上就是一種「傾聽」，我們軟體開發者，得讓自己的一部分是軟體開發者，一部分是心理學家，甚至有一部分是人類學家。投資這個傾聽的過程，就是「設計」的一部分，不管有沒有專屬的UX團隊。認真的自學這個能力，就能為股東帶來可觀的股利，因為誰又能真正精算得出來，浪費了工程師大把的時間，開發出錯的東西，用戶不使用的成本有多大呢？
3. 最好的軟體工程師，會像設計師那樣思考
好的軟體工程師，會深入去想自己的源碼會給用戶什麼樣的體驗。僅管「用戶體驗」似乎跟源碼沒有直接關係，但軟體開發領域中那些呼叫介面(External API)，用戶介面(User Interface)或是通訊協定(Protocol)，都是好的軟體工程師會打磨的地方，他們會思考誰會用它？為什麼用它？會怎麼樣用它？對用戶來說什麼是必須被滿足，最重要的需求？時刻把這些問句謹記在心，就是創造良好用戶體驗的根本。
4. 最好的實作，就是不用實作，或是修改量極小的實作
軟體工程師就像手裡拿著鐵槌，看到問題的第一個想法就是寫code去解決它。人們傾向用自己擅長的技能解決問題本就是天性，而資歷較淺的軟體工程師，又常有「文人相輕」的毛病，很容易掉進「非我所創(Not Invented Here)」症候群，覺得別人寫的東西就是不夠好，無法解決問題，所以就去重新發明輪子，這是我們必須要多注意的有毒文化。
5. 軟體只是一個達到目的的手段
軟體工程師的主要工作是「交付價值」，而不是「交付軟體」。很少軟體工程師真正瞭解這個觀念，更少人是已經將這個觀念內化於心。能將這個觀念內化的軟體工程師，會以不同的角度看待問題，自然也會用不同的角度找出解法。唯有當你能正確的意識到，軟體並不總是所有解法中最重要的那一個，你就具備了「以正確的工具解決正確的問題」的思維，而且有可能會找出根本不需要是軟體的解法。
6. 有時，你就是需要停止強化技能/認知，而專心在解決問題上
有些人會傾向在接到問題之後，馬上跳下去開始寫code。另一種人則是習慣在寫code之前要做好十足的調查，研究，不斷的確認及評估，最終在過多的資訊或可能性中癱瘓掉，動彈不得。不管是哪種人，都難以專心在「解決問題」上。在這種狀況下，唯有設下死線(Deadline)，才能迫使他們回頭專心面對問題，在不斷的迭代"不夠好"的解決方案的過程中，讓解法一次次變得更好。
7. 如果你不能掌握什麼是合理的可能性，你就不能設計出一個好系統
越是資深的技術經理人，越是遠離軟體開發的實作面越遠。僅管如此，瞭解並掌握在軟體開發的生態系統中，「什麼是可能(以)發生的」這個問題，仍然是一個技術經理人不能荒廢的技能。或許跟上這個生態圈的變化，是很累人並需要投入心力的一件事，但如果你無法掌握什麼是合理的可能性，你不但不能自己設計出好系統，你也無法找到值得信任的人來做。總而言之，越久沒寫過code的人，越是要質疑他設計系統的能力及品質。
8. 每個系統最終都會變得很糟，習慣這個事實吧
Bjarne Stroustrup 有句名言：「世界上只有2種程式語言，一種是大家一邊嫌難用還繼續用的，一種是根本沒人用的。」套用到系統這個規模的軟體開發也是一樣，永遠不會有正確的系統架構，永遠都有還不完的技術債，永遠設計不出完美的介面，而且驗證程式永遠來不及測試及保證系統的品質，習慣這個事實吧。不過，這並不是把源碼寫爛，把事情搞砸的理由，而是一個新的學習視角。別再焦慮著不斷追求「簡潔」和「完美」，而是要積極的在「優化」品質上保持活力。最重要的是，要讓你的團隊為創造一個「活著」的，能持續交付價值的系統為榮，並樂在其中。
9. 留意每一個QBQ
對每一個「以往都是這麼做(完成)」的作法，每一個對環境的假設，都要有質疑的空間。如果有新人入職，留意他們卡住的地方，為什麼那邊會是問題？他們在想什麼？如果有一個不明就理的功能需求，確保你有打破砂鍋問到底的好奇心，瞭解為什麼他們有這種需求。如果不夠清楚，就繼續問，每一個QBQ(Questions Behinds Quesions)都有值得我們瞭解的洞見。
10. 10倍工程師沒那麼難找，只要閃過0.1倍的那些就好
「10倍工程師」就是個神話，而且是很蠢的那種。那個神話是說這個世界上，會有一個技術超群，思慮深廣的工程師，他1天的產能，能抵其他一般職能水平，但努力工作的工程師2週的份。也許你現在正會心一笑想著，你確實遇過"10倍工程師"，他們產出了10倍的源碼產量，然後你和團隊成員，得花上10倍的時間去把他寫的code優化或除錯。「10倍工程師」不是這麼定義的，但也沒那麼難找，只要你能閃過那些0.1倍的工程師，像是不尋求反饋，不測試結果，不考慮極值(Edge Cases)狀況等等的那些，那麼那些一般水平的工程師，個個就都是10倍工程師了。你看，沒那麼難找吧？
to be continue...