這五年間我努力讓自己做事更順暢、更完善，為此需要努力從每一次的專案汲取經驗。
這篇文章算是為自己這五年的職涯作一些心得分享，有興趣的話可以點進來看看。
但如果是有心想要成就自己的人，還是買本 The Pragmatic Programmer 來看吧 XD
因為我偶爾會突然想到很重要的一些心得，所以會時不時加入新東西到這篇文章
持續關注技術發展
除了學習新技術，對於自己已經會的技術，也可以持續保持關注，因為這些技術仍會持續發展。而這些新的資訊通常都能為自己的工作帶來立竿見影的成效，比如使用 Javascript 的新語法 可以讓程式表達力更上一層樓，或者 AWS 強化原有服務可以讓花費變低（比如使用 HTTP API 代替 REST API）。
新手直奔開發、老手先讀文件
我在看 Michael Lin – How to Be a 10x Software Engineer 的時候看到「1. Not investigating tooling enough」這點非常有感，因為這也是我的親身經歷。
作為新手，儘管我的技術手段沒這麼多，但我有技術熱情，而且迫不及待的看到成果。因此當面對新的需求，我一找到套件，就會直接開始安裝、試著把他跑起來，然後得出這套件好或不好用的心得。
然後就會踩到各種坑。隨著這樣的經歷多了，我知道要在使用技術前好好調查這些事情：
- 我的需求是什麼？
- 是否有不須寫程式的解決方案？
- 我找到的這個「技術 / 套件」（底下簡稱 tool）是否能解決我的需求？
- 這個 tool 仍有在維護？
- 這個 tool 有夠多人使用？
- 這個 tool 有沒有限制？（API / Quota / Best practice）
職業倦怠很正常
作為工程師，我們要控制很多因素才能有好的產出，比如需求合理程度、專案時程、開發難度、引進新技術的風險、系統花費估算、程式易讀性、可維護性、與同事的關係、確保充足睡眠。也就是說，工程師不是無情的程式製造機，失去平衡在所難免，當不想面對程式的時候，好好休息一下吧。
睡眠管理很重要
該睡要睡，比如周休二日結束前，也許是因為不甘心，狠狠地滑了兩個小時手機才願意睡覺，但此時已經凌晨一、兩點，但明天還是得八點起床，接著就開始不好的循環：減少的睡眠時間、變差的精神、不清楚的思緒、不好的工作成果、變差的心情、更多的娛樂時間、然後更少的睡眠時間（這種推論方式是來自系統思考 XD）。還有需要午休的人就……誠實的睡吧。
更糟糕的是，要了解自己能喝多少含咖啡飲的飲料，以及能在什麼時段喝，才不會影響到睡眠品質。我曾有一段時間，每天晚上喝兩瓶四季春（雖然很好喝），導致我晚上睡覺，總在自以為睡了幾百個世紀後、在半夜驚醒、發現時間是凌晨三點整，連續好幾個禮拜都是這樣，非常可怕，直到我戒了晚上喝茶。
誠實面對自己的無知
從職涯之初，我們就選定了技術領域之一深造。在這領域中，我們只需要一部分技術就可以完成專案。
比如 Web 領域，可以寫單純的 HTML 並放上雲端供大家瀏覽，也可以用 PHP、MySQL，再來是 Laravel，又或者是 node.js，也許來一點 WebSocket，然後放在 EC2 或者 Lambda + API Gateway 執行。每次的開發，我們都是從眾多技術中挑出幾樣排列組合。
隨著專案的成功而獲得升遷，我們不會因為職稱的改變就突然變成無所不知的人，只是變成「懂得比較多的人」。所以不要驕傲，誠實面對自己有非常多不懂的事情，耐心聆聽其他人的想法，也許還能教學相長。
將「發現自己的無知」視為機會
如果遇到這樣的事情，吃驚之餘，卻像嚇傻了般什麼行動都沒有，那麼再次遇到挑戰的時候便毫無招架之力。甚至是對毫無作為的自己喪失自信，這樣子得不償失。
所以 do it right now，如果不行，馬上打開你的 todoist，把這件事情記起來，以便閒暇時好好研究。
記憶很不可靠
最明顯的例子，比如我曾跟同事在討論某一段程式寫得很爛，而且我認為絕對不是我寫的，結果 Git 紀錄打開來一翻兩瞪眼，超級羞羞臉ㄏ。
如果常常發生這樣的情況，除了多驗證自己的記憶力是不是高於平均值的不可靠之外，也可以驗證看看是不是有人在 gaslight 你（幹話）。
到處都是資源限制
即使現在是 2022 年，工程部門還是得努力在各項限制中找出可行方案。
比如系統面的，記憶體大小、vCPU 數量、硬碟大小、執行時間限制、網路限制、資料同步、資安。
人的方面：人力不足、能力分布不均、同事間無法互相代替。
還有常見的：瀏覽器對語法支援的不一致、IE 或 Safari 會遇到很多問題。
加班是必要之惡
「Work-life balance」是工程師的信條，能在這樣的環境工作是幸福。
但過緊的專案時程、過多學不完的技術會把人逼上加班的不歸路。正因為想把事情做好，而且不想再次經歷專案失敗，所以不得不加班。每次都是用背水一戰的心情在晚上七點之後繼續努力解決大大小小的難題，拉高完成度，取得豐碩的戰果。睡醒之後發現激情的只有自己，然後默默地開始下一個專案。
但履歷好像也變得更飽滿了一點。
溝通不能偷懶
語言很容易出現解讀不一致的情況，而這種不一致具有破壞力。
如果被誤會，會不好受；
如果在與會者看似達成共識，想的卻不一樣，生產力會打折；
如果工程師與其他人產生誤解了，會寫出一些沒人想要的東西。
而我認為做結論可以緩解這種情況，比如在會議的最後，描述我認定的共識。最好的情況是有人試著確認某個細節，次之是有人對某部分產生很大的疑問。及早同步能避免傷害擴大。
開啟對話前多想幾次
每當覺得有需要跟同事溝通，可以先把自己想說的話寫出來多讀幾遍，並確定這些事項：
- 是否能正確傳達？
- 是否有冗言贅字？
- 加入類比是否會更有效率？
- 部分內容用圖片呈現是否更有效率？（比如用 appleboy 於這篇文章提到的 draw.io）
- 對方是否具備理解這段話的能力？是否需要講得更簡單一點？
表達能力需要時間培養（尤其是工程師）
在 The Pragmatic Programmer 這本書裡面有一段話深得我心，大意是：「我們既是聆聽者，也是解讀者，有時也是獨裁者」。獨裁指的是我們對程式碼的撰寫方式有絕對的控制權。作為程式獨裁者的我們，我們能有效統治這些程式嗎？其實很難。
對新手來說，聆聽、解讀不是最困難的部分，在接收完使用者的需求後，回到自己座位上，這時才是惡夢的開始。比如需求不知道該用什麼技術實作，而用既有的技術實作又時常報錯。我們時常看著 Error 手足無措，唯一的反應是把訊息貼到 Google 搜尋。最終我們會被技術反噬，再也不能有效地吸收技術、應用技術、解釋技術，然後「聽不懂工程師在說什麼」就變成必經之路。
工程師會需要大量的時間練習深入淺出的講解技術，讓一般人覺得好懂、同時又不像工程師自身被細節所困。這真的很難。
搶先發佈留言