我們的社會需要更多的「軟體獨立承包商」(software contractor)
2019 年 2 月，我在台北市內湖的某家廣告公司擔任 software contractor。工作內容是要幫該公司開發一個軟體系統，取代既有的 Excel + PHP + SQL 解決方案。簽約前，人資小姐提醒我說這是一個 contractor 的職位。然而，我簽英文的雇用合約時，看到的英文字句寫的卻是 temp 。由於我的上一份工作的職稱是 senior software developer ，我看到了 temp ，心裡不由得碎念一番：「這種東西放在履歷上，肯定是扣分項目吧？」。
contractor 和 temp 在中文，都可以翻譯成「約聘雇」。然而，英文的定義卻有些不同。temp 通常是指，沒有專門技術的人員。contractor 則不同。在美國加州的法律規定：An individual is an independent contractor if the payer has the right to control or direct only the result of the work, not what will be done and how it will be done. 換言之，如果一個軟體開發人員是 independent contractor (獨立承包商) 的話，他應該擁有權力，去決定軟體該怎麼設計、軟體該怎麼實作，包含但不侷限於：程式語言、資料庫、API 的規格。用更淺白/粗俗的中文來講的話，temp 就是比正職員工低一個等級， (太廢了，公司不爽給你正職) 。contractor 至少和正職的員工同一個等級，(太貴了，公司沒有辦法天長地久地雇用…。)。
我做的企業內部系統在 8 月時準時上線，technical stack 使用 Clojure/Datomic 。既然，我獨立決定了軟體開發的 80% 以上的細節，我想我勉強算是一個 contractor 。 12 月時，我去了一趟英國倫敦，去參加 Clojure Conference 。在英國倫敦的軟體業，和台灣有一些明顯的不同：在英國，很多軟體工程師在成為資深工程師之後，下一步的職涯，他們轉行當軟體獨立軟體承包商 (software contractor) 。 此外，很多軟體開發者都做了這個選擇的同時，英國也衍生了一些其它的行業。比方說，就會有專門的機構 (Agency) 幫公司與 contractor 媒合。 我與英國當地的台灣人做技術交流時，當地的台灣人也隨口問我，「要不要來英國？當 contractor 滿好賺的，我自己再過幾年累積的技術足夠了，也想轉行當 contractor 」
我認為，我們的社會需要更多的 software contractor ，而這件事需要社會風氣的轉變。現在的社會風氣： 「資深軟體工程師總是先考慮成為『要帶人的經理』，而不多加考慮成為『獨立軟體承包商』」。這個風氣，對於社會整體的生產力，是一種傷害。如果朝更多 software contractor 這個方向轉變的話，將來整個社會生產的軟體品質會更好。
軟體開發的現況：
如果你要做軟體，從無到有，找沒有什麼經驗，比方說，剛完成 1000 小時的密集訓練的工程師來做，很有可能發生下列的災難。
* Deadline 一次又一次地往後延，始終專案就是不會完成。
* 專案做完了，但是發現做出來的東西照著規格做，但卻不是你要的。
* 專案做對了，但是要增加功能時，發現東西做不下去了，需要砍掉重練。
* 系統跑得不夠快，然後怎麼改，都還是不夠快。
軟體人員招募的現況：
* 大多數的中小企業，就是開薪水、招人，招人也是看看履歷。覺得學歷、經歷還可以，就用人了。然後，等到發現用的人好像有點不太對，做出來的軟體有問題，或是根本做不出來，再來換人。
* 比較有制度一點的大公司或是新創，則是設計複雜的考題、買 Codility 的題庫來考。然而，設計這些招募流程的人，往往沒有讀過 Joe Spolsky 的大作 Smart and Gets Things Done 。(考白板的概念，就是該書提出來的。) 於是，白板題年復一年，考得愈來愈難。想要進大公司的應徵者，也開始了刷題的行為。關鍵問題來了：『會考白板題，就能處理真實世界的軟體問題嗎？ 』
技術堆棧 (technical stack) 選擇的現況：
* 大多數需要做軟體的公司，做 technical stack 的選擇，並不是出自於純專業的決定，很大一部分來自政治考量。在公司裡，最有政治實力的工程師可以選擇 technical stack 。同時，technical stack 的選擇，也常常盲從潮流。我常常對於一些軟體公司選用 Golang 感到疑惑？ Golang 並不是適合小公司的選項，它真的比較適合 Google 這種大公司。不過，這並不是一個純粹的技術專業問題，真實的世界總是同時有技術、商業、政治等不同的力量，彼此較量。
上述的問題：軟體開發不能穩定地交付、招募的過程沒有辦法有效鑑別軟體人員素質、技術堆棧盲從潮流且犯錯而不自知、一環扣著一環。每一環的無效率都損害了最終軟體交付的品質。對於企業經營者，如果你懷疑公司的軟體開發流程真的出了問題時 (通常會懷疑的話，八成就是有點嚴重了。) ，只要肯花錢，就可以找到夠專業的外部軟體顧問來救火，這不是一大福音嗎？
更多有紮實技術的資深軟體工程師轉行做獨立軟體承包商，這是我個人對於台灣軟體業的想象與期望。
2024/01 更新：
新文章已經轉換到 https://replware.substack.com 發表，歡迎讀者訂閱
