剛剛滑了一下 PTT 看到一篇文章提到「科技業最大的問題是成就無法儲存」，簡單的說，他認為科技業的工作成果是難以累積的，看了一下論點，我想難怪他會這麼想，因為他的工作算是標準的仰賴體系。
剛出社會時，我被分派在一個做技術底層元件開發的團隊，我們的工作任務就是開發一個又一個可被 reuse 的元件，以及將複雜的問題封裝起來，讓其他人在實現相同功能時可以不用了解技術細節，但就能做得跟我們一般好。
簡單的說，你本來要寫一支程式，功能要包含新增、修改、刪除、查詢，可能光輸入的部分你就有很多的邏輯需要判斷，像是必填欄位檢查，數值、日期、email 格式檢查，重複資料的判斷，特殊格式的處理，輸入代號帶出名稱等一拖拉庫的事情得處理。
這還只是新增的部分，修改、刪除跟查詢也還有不少地方得留意，說難不難，但林林總總還是有很多地方得留意。而我們的任務就是將這些共通性的需求寫成元件，搭成框架。所以其他工程師只需要將資料結構建立好(一般還不是他們定義的)，套上我們的框架做一些設定，上面這些功能就 work 了。
原先需要 3 天時間的開發，套上我們的框架，只要半小時到一小時。
處理元件跟框架的人，總是得做很多新技術的研究，也要直接面對最難處理的那些技術問題，一旦程式出現難以理解的錯誤，大家第一個想到的就是「是元件的問題」、「框架有 bug」。這樣的工作算起來並不輕鬆。但我們專業的成長性是高的，在公司內的能見度也是相對好的。
有一次我問一位使用我們元件開發的工程師：「你每天使用我們的元件開發程式，不會好奇我們是怎麼做出這些元件的嗎？」
他告訴我：「會啊，不過每天忙著趕工，交付客戶的程式都沒時間了，哪還有那麼多時間想那麼多。」
那時我心裡想：「不知道有一天你去到另一家公司，沒有我們這個框架與元件可以用，你還能完成程式嗎？」
不過我也只是想想，也不好開口多說些什麼。
另一次，有一位從事相同工作的年輕工程師來找我，他問了我很多問題，包含我們元件底層的技術是怎麼運作的，以及為何我們會這麼設計，如果他想實現一些特殊的功能可以怎麼改。我花了很多時間跟他說明，也從中找到一些自己設計的盲點。而他記了滿滿兩頁的筆記。
後來我問他：「不了解這些你也可以完成工作，為什麼要特別花時間？」
他說：「因為感興趣，想要知道底層怎麼跑的，也想自己寫一次看看，之前在書上有看過類似的東西，但沒看懂，想說來問問你們，這樣下次我也可以自己做一個。」
我那時聽了覺得有點欣慰，欣慰的原因不是因為覺得他很上進，我那時也不過剛出社會沒兩年，我單純只是覺得有人想要聊聊我花了很多夜晚研究並設計出來的東西，覺得他真是識貨而已。
不過在公司工作幾年，我觀察身邊的同事大致可以歸為三大類：
第一類，遵從體系，按著體系內的流程與分工做事，能做好事情很大比例是仰賴體系，而非個人能力。
第二類，打造體系，他們是體系內規則與流程的創造者，面對相對困難的問題，然後將複雜問題封裝起來，提供給其他人使用。
第三類，充分善用體系，也理解體系運作的原理，能一邊用體系的流程創造好的績效表現，但也不會受制於體系，有時甚至能比體系更超前。
第一類人，一般會覺得自己的專業能力沒有累積，因為他們就是我以前提到的，他的經驗是屬於「十個一年」，也就是他只有第一年有成長，後面的九年是重複第一年就已經會的東西，他的成長，基本上可以從薪資上直接看見。
第二類與第三類人，在找尋工作時則相對容易，因為他們面對的是比較高的不確定性，一直以來在處理的問題相對複雜，工作的每一年，可能要處理的問題都不同，這種人的成長一般也是比較快的。也才是真正能持續累積的。
那第一類工作真的不可以做嗎？我覺得也不是，在毫無經驗時累積經驗是不錯的起步，但並不適合長期做。我個人蠻鼓勵成為第三類人，因為要當第二類人真的要有比較濃厚的興趣會比較適合。
善用體系，但千萬別讓自己成為體系員工。
