這陣子借了一本給工程師看的書，但是內容跟程式碼無關，所以讀起來不傷腦、很輕鬆。其實這本書比較像在談心法，更多的是作者提醒工程師要如何在職場上存活下去、如何工作地更有效率。我認為在實用性上，這本書反而比任何寫程式的書還來的重要，因為就算程式寫得再厲害，很多工程師的通病都是爆肝、把自己搞得累死，不然就是在職場上不曉得如何與上級、下屬對話，不瞭解客戶的真正意圖而瞎忙。
不只工程師該讀，這本書的心法其實所有使用「腦力創作」的職業都適合，例如設計師、文字創作者等等，只要你認為做的事是一門專業。
一、從錯誤中學習
作者是一位知名的資深工程師，歷經最原始的程式設計年代(打洞卡片、磁帶)直到現在，這本書敘述了他的工作經歷，包含各種失敗的小故事、職場的慘痛經歷。
很多書其實只是倖存者偏誤，成功者述說他如何成功，實際上有可能只是運氣好、機率下的產物。
真正對讀者有用的書，是作者敘述他如何失敗，不忌諱別人看到他過去犯的蠢事，這也是我極力推薦此書的原因。
太陽底下沒有新鮮事，同樣的慘事一定會不斷發生(歷史不斷重演)，多閱讀、多吸收別人的失敗經驗，避免別人踩過的坑，才是王道。
模仿成功幾乎都無法複製成功，只有避免犯錯、不複製前人的失敗，才可能逐步走向成功。
本篇為個人的心得整理，不包含全部章節。因每個人的需求不同，建議閱讀原文會更有幫助。
二、成為專業人士
如果沒有將身為專業人士視為榮譽，如果不把成為專業人士當目標，只想當個可以輕鬆接受指令的員工，出了事有上級、或公司扛，不必負責任，那麼接下來的內容與你無關了。
好的，什麼是專業人士？專業人士有什麼特質？
- 擔當責任：願意承受自己錯誤所造成的客戶損失。(光這一點就是很大的門檻，通常有老闆特質的人，才有辦法做到)
- 將公司利益視同個人利益：這句話是「專業主義」的精髓。(以前 WFU 在公司上班時，一向把每個 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 撰寫、擴充、維護、偵錯，還有心智、精神上的訓練流程。
就像「工藝」的傳承一般，希望程式設計師的專業，將來也能成為一種工藝典範。
更多 接案心得 相關文章：