ExplainThis 全端開發雙週報 #66 如何寫好年末績效考核 (performance review)
如何寫好年末績效考核 (performance review)
嗨～歡迎閱讀第 66 期 ExplainThis 全端開發雙週報！
在最開始，想先分享 E+ 今年最後一堂線上課程《寫出好維護的程式碼 (上) — 經典的程式設計觀點》已經正式上線了！
寫出能動的程式碼，不是件困難的事；不過如果想寫出功能正確又好維護的程式碼，就沒有那麼容易。在實務上，資深與初階工程師的一大區別，在於前者不只是寫程式，還會擔當起守護程式碼健康度的重責。
特別是進到 AI 代理能夠快速完成實作的時代，AI 雖然能快速完成實作，但寫出來的東西不必然是好維護的。如果生成的程式碼是難維護的，長久累積下會成為難以重構的技術債，反而讓團隊必須花更多成本去解決；資深工程師的存在價值之一，就是避免這種狀況發生。
對此，希望透過這門線上課，讓讀者們有效掌握寫出好維護的程式碼，有哪些推薦的原則與思考框架，成為有能力在程式碼審查 (code review) 時去點出程式碼的問題，避免難維護的程式碼被合併到程式碼庫中。
感興趣的讀者，歡迎加入 E+ 成長計畫觀看 (連結)。
如何寫好年末績效考核 (performance review)
2025 已經逐漸到了尾聲，每當到了年末，相信許多人在工作上會覺得很苦惱的一件事情，莫過於要寫年度的績效考核 績效考核可以說是一種必要之惡，因為假設想要能夠拿到好的績效， 想要能夠獲得升遷，在績效考核上面花心思是避免不了的。
過去在業界有些人會戲稱，寫績效考核的自評有點像是寫小作文比賽。每當到了年末大家就會傾盡畢生的寫作功力，卯足全力去寫這個在該年度最重要的小作文。
在這期雙週報中，我們會討論如何可以有效的寫好績效考核的自評；希望讓大家能夠在年末要寫績效考的時候可以更有方向。
從工程經理的角度怎麼看績效考核?
當提到績效考核，相信多數人最直接會想到的人是自己的主管，或者從職位上來看，會想到團隊中的工程經理。因為工程經理是最直接處理工程師績效的人，所以如果能同理工程經理，從工程經理的角度看績效考核，會更清楚如何跟工程經理有效合作，讓自己拿到更好的考核結果。
在有一定規模的團隊中，通常工程經理只是「推薦考核結果」的人，而不是真正決定績效考核的人。在工程經理送出的評估後，往往會有更上一層 (例如工程總監、工程副總) 看完後，決定是否接受，或者是駁回。
因此，比起把工程經理當成目標閱讀者，在思考寫績效考核的時候，推薦要更往上一層，把目標閱讀者設定為工程總監 (Director) 或副總 (VP)。而看待工程經理的角度，更會偏向是自己的推薦人；換句話說，你的目標是要讓工程經理，能夠有效去推薦你、藉此爭取到好的績效結果。
從這個角度看，花時間把績效考核寫好，等同幫忙自己的推薦人減輕工作量。試想，假如工程經理要管理十多個人，在績效考核的期間當中，他要去幫十多個人寫給工程總監以及工程副總審核的內容。
假如你足夠認真去寫，讓工程經理看到的時候覺得寫出來的東西很好，也會讓工程經理有多一個動機去幫助你，去推銷你過去半年做的成果。反之假如你沒有花太多的心思，寫出來的東西讓人看了覺得是不用心的，很可能為讓工程經理覺得「這個人自己都不用心了，不會特別想推他一把」。
從推薦人的角度來看，要讓推薦人能夠成功推薦自己，就需要讓推薦人有論點與佐證。
如何寫好自評?
上一段談到寫績效考核的自評時，要有論點與佐證，往下讓我們具體來談該怎麼寫。
首先，想要寫好自評，需要先有足夠好的素材；畢竟有再多撰寫的技巧與方法，假如本身沒有足夠的料，寫出來的內容也只會是空洞無據，不太可能獲得好的成果。
先前在《軟體工程師都該有的炫耀文件 (brag document)》一文 (連結) 我們有談過炫耀文件 (brag document)，這個非常有幫助的方法；我們也有製作炫耀文件的模板，如果先前還沒看過的讀者，推薦可以讀先前的文章。在平常工作時，在每天或者每週的結束時用模板提供的形式為自己記錄。如果平時有記錄，在寫自評時就會有很多素材可以用。
如何讓佐證有說服力
如果只有素材，沒有把過去累積的轉換成某一個有力的論點，在寫自評時也會很難寫出說服人的內容。而要形成具說服力論點的方式，就是把公司在衡量績效時的指標放在旁邊，然後針對這些指標來論述。
因此，要能做到這點，就需要先去了解公司是用什麼指標來評估。詳細的相關內容，我們在《軟體工程師的職涯路徑概覽》一文 (連結) 有討論過，推薦回顧。舉例來說，業界常會用的指標包含商業影響力(Businss Impact)、工程卓越 (Engineering Excellence)、團隊 (Team) 等等。
推薦平常就可以在跟工程經理的 1:1 中去了解，對於目前團隊來說，這些指標中又有哪個是特別重要的。先前 ExplainThis 團隊成員 Li 在工作上，正好那個半年公司放很多心力在推降低成本 (FinOps)，而 Li 在那個半年做了一個重構，讓公司每年可以省數百萬日幣的運算資源。因為公司當時看重這個商業指標，所以 Li 就在自評的第一點直接談那個重構帶來的影響力，也讓該半年的績效拿到超乎預期。
由於在自評中，通常不會只是寫一個點；在眾多可以寫的列點中，務必要把最能連結到核心指標的，放在最上面，藉此建立好的第一印象。這點對更上層的人來說特別重要，因為對工程總監或副總來說，要看的績效考核量會更多，所以每個能花的時間會更少，所以如果沒能在最開始放最重要的來抓住目光，會相對可惜。
在寫自評時有個很可能會不小心犯的問題，就是寫太多過去 Li 在某次升遷過程失利的經驗，就是因為在升遷申請的內容中，寫很多但都是比較小的事。切記，雖然理想狀況是質與量兼具，但這兩者間質會大於量。
本期推薦
先前我們分享過在許多程式語言，0.1 + 0.2 不是 0.3 (連結)，這是因為採用 IEEE 754 標準，浮點數的運算無法完整被十進位表達。最近看到一篇多年前的舊文《Floating Point Visually Explained》 (連結)，用視覺化的方式把浮點數講得很清楚，推薦一讀
Cursor 員工 Brie Wolfson 最近分享了 《Inside Cursor》一文 (連結），談到她對 Cursor 運作 (從招募到協作方式) 的觀察，文中提到很多獨特的點，非常有趣。過去我們也有寫過一系列 Cursor 教學文，感興趣的讀者可以參考 (連結)
最近社群有一篇《Kafka is fast -- I’ll use Postgres》 (連結) 作者提出用 Postgres 即可無需 Kafka 的觀點，隨即有另一篇 《”You Don’t Need Kafka, Just Use Postgres” Considered Harmful》 (連結) 反駁該論點。非常推薦多讀這類討論，先不論認同與否，這類討論都有助於培養技術觀點
Ghostty 作者 Mitchell Hashimoto 前陣子分享了《Vibing a Non-Trivial Ghostty Feature》一文 (連結)，詳細解析用 AI 代理協助開發複雜度高的功能，寫得很精彩 (備註：過程中其實很不 vibe，而是更偏向 AI 輔助)
《The Inner Workings of JavaScript Source Maps 》一文 (連結) 用循序漸進的方式談 JavaScript 的 source map 如何運作。對 source map 不熟的讀者，可以參考我們先前寫的《如何在開發者工具上 debug 原始程式碼?》一文 (連結)
這週社群有一篇《becoming a compiler engineer》 (連結)，分享了找編譯器工程師的心得，包含如何準備、求職管道等等。編譯器工程師是相對小眾的求職市場，在網路上的求職資源沒有應用端工程師來得多，非常感謝原作者無私的分享 (內文有很多點，對應用端的前後端工程師也很有幫助。
Midjourney 的工程師提到，Midjourney 的應用端技術棧已經全面遷移到 Bun 上面。從伺服器端路由、執行環境、前端打包、腳本、即時生成預覽，全都用 Bun (連結)。如果還不熟 Bun，我們先前有寫過一篇介紹文 (連結)
白帽駭客 Gal Nagli 揭露F1 網站漏洞，讓冠軍車手 Max Verstappen 的護照、住址資料輕鬆被拿到 (連結)。該漏洞是個非常基本但很容易被忽略的，推薦任何後端開發者，千萬不能缺少該有的防禦意識 (連結)
文末彩蛋
前陣子在社群中讀到一句很有感觸的話「人生會一再用同樣的考驗來測試你，直到你學會那個該學的課題」。
Life will test you with the same challenge until you learn the lesson.
對我們來說，過去幾年一再被人生測試的課題是「健康」。在二十的尾巴時，想要衝刺升遷，也想要在 ExplainThis 這項個人專案上做出一些成果，所以經常沒日沒夜地加班、寫內容。
然而，邁入三十大關後，不如以往年輕的身體，漸漸開始無法支應這種不惜一切代價地操勞；當熬夜後，隔天的整體生理與精神狀況會變很差。一次兩次後，才總算痛徹地意識到不能繼續這樣。
這也是為什麼從去年以來，ExplainThis 的整體步調變得比過往慢很多。假如某天晚上沒辦法完成某篇內容，我們不再硬撐到寫完為止。更平衡地把健康納入考量後，也得以用更好的狀態來創作內容。
在 2025 年底回頭看，很慶幸我們總算學會這個人生給的課題。雖然整體沒有過去幾年來得多，但穩定且持續的創作，仍讓 2025 是個產出豐富的一年。