專業程式設計師的生存之道﹍讀後心得摘要

這陣子借了一本給工程師看的書，但是內容跟程式碼無關，所以讀起來不傷腦、很輕鬆。其實這本書比較像在談心法，更多的是作者提醒工程師要如何在職場上存活下去、如何工作地更有效率。

我認為在實用性上，這本書反而比寫程式的工具書重要，因為程式寫得再厲害，許多工程師的通病是爆肝、把自己搞得很累，或是職場上缺乏與上級、下屬對話的技巧，或無法偵測客戶的真正意圖而瞎忙。

不只工程師該讀，這本書的心法其實所有使用「腦力創作」的職業都適合，例如設計師、文字創作者等等，只要你認為做的事是一門專業。

一、從錯誤中學習

作者是知名的資深工程師，歷經最原始的程式設計年代(打洞卡片、磁帶)直到現在，這本書敘述了他的工作經歷，包含各種失敗的小故事、職場的慘痛經歷。

很多書算是倖存者偏誤，成功者述說他如何成功，實際上可能是運氣好、機率下的產物。

真正對讀者有用的書，是作者敘述他如何失敗，不忌諱別人看到過去犯的蠢事，這也是推薦此書的原因。太陽底下沒有新鮮事，歷史會不斷重演，多吸收別人的失敗經驗、避免別人踩過的坑，才是王道。

本篇為個人的心得整理，不包含全部章節。因每個人的需求不同，建議閱讀原文會更有幫助。

二、成為專業人士

作者希望我們將身為專業人士視為榮譽、當成目標，而非當個可以輕鬆接受指令的員工，出了事有上級、或公司扛，不必負責任。

好的，什麼是專業人士？專業人士有什麼特質？

• 擔當責任：願意承受自己錯誤所造成的客戶損失。(這一點算是不小的門檻)
• 將公司利益視同個人利益：這句話是「專業主義」的精髓。(把每個 case 當自己的事做，這是一種將每件事做好的心態，不一定代表為了公司，而是為了個人能力成長)
• 如何負責：
  
  • 雖然追求完美，但人並不完美，一定會犯錯，所以需要學會「道歉」，並且要求自己避免一再犯相同錯誤。
  • 送出成果、交案之前，該做的所有偵錯、QA、檢查流程，這些時間不可省，才是負責的專業人士。
  • QA 完還被客戶發現錯誤，都該震驚羞愧，並且反思這些 bug 是如何產生，想辦法避免。
• 職業道德：
  
  • 上班的時間是雇主的
  • 其餘的時間精進自己領域的知識
  • 保持不斷練習(這個概念我沒想過，的確很重要，必須把專業技能練到變成反射動作，可有效節省作業時間。就像是學圍棋的基本功、練功夫的蹲馬步、鋼琴師每日都需練琴一樣)
• 站在客戶的角度思考(開發讀心術很重要，可節省白做工的時間)
• 謙遜：專業人士容易自負，但一定也會有出錯的時候，所以需要保持謙遜，也不要因別人犯錯就貶低對方。

三、勇敢說不

節錄書中一段文字：

奴隸沒有權利說「不」，勞工或許對說「不」有所顧慮，但專業人士應該懂得說「不」。優秀經理人對於敢說「不」的人，總是求賢若渴，因為只有敢於說「不」，才能真正做成一些事情。

作者認為無法說「不」，可能是無法瞭解「WHY」、無法清楚陳述理由。他舉出一些過去經歷，展示了溝通雙方都無法說「不」的場景，反而對未來造成更大的傷害，因為雙方認知的「好」卻各自代表不同意義，例如：

• 上司：WFU，明天之前要完成 XX 功能
• WFU：這麼急喔？嗯...我盡量試試看好了
• 上司：太好了，感恩

結果上司直接跟客人承諾明天就會完成，而 WFU 心想哪有可能，反正只是先試試看，明天再說，結果自然是悲劇。

作者認為以上雙方都極度不專業，上司面對下屬的遲疑完全沒有再度確認可行性。真正專業的對話大概像這樣：

• 上司：WFU，明天之前要完成 XX 功能
• WFU：不可能喔，這要 5 個工作天才行
• 上司：可是 XX 功能 1 天應該寫得出來吧
• WFU：1 天只能寫出初步功能，還要上到客戶伺服器，不同的環境不曉得是否有相容性問題，等安裝成功後還需要進行測試，若有 bug 還需要往返來回測試。
• 上司：這樣就糟糕了，客戶明天想來看 DEMO，要有畫面能展示才行。
• WFU：這樣的話我先想辦法作一個極簡化的版本，放在公司電腦執行特定效果給客戶看就好，就先不用往返測試，DEMO 完再正式做 XX 功能。
• 上司：這樣真是太好了。

以上展示了雙方各自對異議說「不」，並想辦法找到雙方都能接受的折衷方案，是一段展現專業的模擬對話。

如果在説「不」的同時，雙方都能讓對方理解「為什麼」，那麼說「不」雖然會產生衝突，但同時也想辦法為對方找出「替代方案」，多半是能夠一起找出最佳解的。

四、輕易說「好」的後果

• 客戶永遠不像你想的那麼在乎：雖然客戶常常給與緊迫的交期，表現的很急的樣子，實際上你趕工出來後，他們常常也只是把這件事放著
• 我們常常為了趕工而寫出應急的程式碼，但這些程式碼不易擴展、維護，也就是所謂的欠下程式債，日後會很慘。
• 因為客戶總是會想到新的需求，等客戶追加新功能時，後續就會被欠下的程式債累垮。
• 客戶提出的需求，其實不一定能解決問題，他們是想像提出的需求可以解決問題 → 所以別輕易說好，別對客戶的話全盤接收，溝通時最好能先確認客戶的用意為何，早一步釐清真正的需求，才能避免白做工，避免程式碼重寫。
• 交期有狀況時愈早反應越好，別時間到了才通知來不及，讓他人可以儘早調整預期。

當可以瞭解應該何時說「不」、何時說「好」，以及相關的溝通技巧，我們就能有效避開大部分的壓力來源。

四、關於寫程式

作者根據過往的經驗，提供寫程式的一套規則、原則：

• 程式碼要讓其他工程師能看的懂：
  
  • 寫好註解
  • 變數命名、寫程式的原則要一致
  • 影集 Silicon Valley 有看過，國外大公司會要求工程師彼此 code review(代碼審查)，除了可避免錯誤，也可互相學習、進步，是很好的協作機制。
• 適合工作的狀態：
  
  • 如果感到疲勞、心煩意亂，不要逼自己寫程式。
  • 無法全神貫注下寫程式，除了會出錯，往往容易留下程式債。
  • 撥一段時間來解決焦慮的狀態。最好在開始工作之前就解決會引起焦慮的問題，避免焦慮在工作時段產生。(處理好家庭、朋友的關係，別讓某些事在工作時還在背景持續執行，干擾大腦)
  • 專業工作者知道如何好好保存自己的精力，才能維持創造力。(參照後面章節談到「專注力」的部分)
• 大腦阻塞時怎麼辦：
  
  • 想不出解法是常有的事，可以暫時離開目前的作業環境一段時間。
  • 以 WFU 的經驗，一直想不出來的東西，常常在交通工具上、或洗澡時，忽然間就找到 solution。
  • 跟別人交流、協作一下，有時就能產生新的想法。
  • 作者建議閱讀不同領域的書，可以激發出創意。
• 管理進度延遲：
  
  • 延遲一定會遇到，為了不讓同事、客戶有錯誤的預期，最好提供「樂觀」、「正常」、「悲觀」這三種交期數字
  • WFU 實務上的經驗，會提供例如 15~20 天這樣的模糊交期
• 幫助他人：
  
  • 當自己陷入困境、或是被某個小問題卡住時，不妨請求別人的幫助。
  • 正因為我們需要協助，所以協助他人是必須的，互相幫助是每個工程師的職責。
  • 但為了工作效率，我們都需要不被打擾的時段，因此需要禮貌地告訴別人，幾點到幾點不希望被干擾。

五、時間管理

這是本書我最受用的一個章節，其中「專注力」需要補充這件事，是我原本沒有的概念，導致過去會逼迫自己在不合宜的時間拼命工作。

• 拒絕不必要的會議：
  
  • 會議的成本非常昂貴，參加的會議必須慎選，只挑必要的，避免影響工作產出。
  • 如果發現參加某個會議是在浪費時間時，想個禮貌的辦法退出。
  • 主管最重要的職責之一，是幫你從某些會議脫身，因為他跟你一樣關心你的時間。
• 管理專注力:
  
  • 程式設計是需要持續投入精力與專注力的智力活動
  • 「專注力」是一項稀有財，類似玩遊戲時的魔法點數 MP，當用光的時候，需要休息才能恢復 MP 值
  • 專業人員知道如何妥善使用自己的 MP 值(專注力)，在專注力夠的時候寫程式，在專注力匱乏的時候做其他事。
  • 專注力會隨著時間流逝而減少，所以若不即時使用，就會逐漸消失
  • 如果用光了專注力，需花一個小時或更多時間，做「不需專注力」的事，來進行補充，例如聊天、運動、處理雜事。
  • 每天好好睡飽 7~8 小時，可確保早晨有飽滿的專注力
  • 定期運動，有助於提高專注力(MP)的上限值
• 蕃茄工作法：
  
  • 工作上常見的蕃茄時鐘法，現在終於知道這麼做的原理。
  • 例如在專注力足夠時，不被打擾地完整工作一段時間(例如 30 分鐘)
  • 接著可做一些雜事(例如 5~10 分鐘)，作用在於讓專注力回補
  • 然後繼續完整的工作時間 (30 分鐘)
  • 循環 4 次蕃茄時間後，休息 30 分鐘，回補更多的專注力。
  • 每個人都需要根據自己的狀況調整工作時間與休息時間，而重點在於抓住自己「專注力」最充足的時段進行工作，可讓效率、產出最大化。
• 要避免的行為：
  
  • 優先順序錯亂：專業人員知道如何評估每項任務的優先順序
  • 避免走入死胡同、與陷入泥沼：此點後述

以上「要避免的行為」的內容，書中比較難看出確切的作法，只能算是口號，這裡補充我的看法。

所有要避免的行為，我認為只能由過去的工作經驗自行歸納，或由他人的經驗記取教訓，避免重複犯錯。

例如接案會陷入泥沼的狀況可能是「遇到奧客」，奧客會：

• 不斷殺價
• 各種小地方想盡辦法佔便宜
• 溝通耗時間
• 不時凹你做額外的功能
• 付款拖拖拉拉，難以結案

以上這些狀況都會壓縮工作時間，排擠好客戶的處理時間，造成巨大壓力。

然而能否在詢價階段就判別出奧客，這有賴累積的工作經驗，也可以說成為專業人士後，才有辦法整理出所有自己「要避免的行為」。

六、工藝典範

我非常喜歡作為總結的最後一章，作者為何用「工藝典範」下標呢？

許多極度專業的行業，對於入行者有著極為嚴格的學習、訓練過程，例如：

• 醫師：專門的醫學院給與完善的教育體系，接著經過實習醫生、住院醫師等等時期的訓練，務求培養出專業的醫師。
• 廚師：學徒從洗、切菜等基本功夫慢慢磨練，由師傅帶領、傳授各種廚藝，成為大廚可能要近 10 年的功夫。

作者要表達的是，醫院不會把手術交給剛畢業的醫學院學生，餐廳不敢請只學 3、5 年的學徒掌廚，但是在程式設計師的領域卻不是這樣子的，剛出茅廬就有可能被丟上戰場！

我想連國外的作者都這麼講了，台灣的環境一定更離譜。實際上我也的確看過很多案例，公司為了省錢，不請專業工程師架站，而是叫員工把 HTML/CSS 的書看一看後，要員工自己把網站生出來，有問題就到 PTT / 各大討論區去問。

這樣的心態就是網站能動就好，然而外行的人能寫出什麼樣的程式碼，一定是剪剪貼貼來的，日後需要維護、或網站出問題時根本不會修，這時再來找專業人士擦屁股。而專業人士看了那些悽慘的程式碼也不會想接手，導致公司要花更多錢善後。

因此作者的願景是，希望「程式設計師」這個領域能夠被重視，當成專業人士一樣看待，有完整的教育、培養體系，像學徒般有大廚手把手教導，除了瞭解程式該用什麼樣的 SOP 撰寫、擴充、維護、偵錯，還有心智、精神上的訓練流程。

就像「工藝」的傳承一般，希望程式設計師的專業，將來也能成為一種工藝典範。

更多 接案心得 相關文章：