我現在的狀況是這樣：幾乎只能工作大約半個工作日（約四至五小時），手臂跟背部就開始抗議了，有時覺得那一天狀況奇佳，可以衝了快十小時，隔天就又被討回來。
於是我覺得我該重新檢討自己的技術選型。再不然，我就得考慮盡早轉行。
誠實地說，以往我因為自己的學歷出身，長期在這個圈子裡覺得很自卑，喜歡電腦科學、軟體工程，但是幾乎沒有用過比較貼近系統底層的語言，遑論做相關開發，這種無法往 “bare-metal” 靠、「榨乾、徹底且有效發揮硬體能力」的歷程，讓我覺得自己始終低人一等。
以前我讀朱邦復的組合語言教材《組合語言的藝術》，他錙銖必較於「少用幾個指令，卻做到相同的功能」那種情懷，很讓我嚮往，雖然我知道現在很多編譯器產品做的最佳化，已經很聰明了，往往只要你的程式寫法不要寫得太爛，效能表現其實都不會太差，反之，如果你的程式爛到原本就用很差的算法去叫電腦做事，用再怎麼貼近底層的程式語言，編譯器可能還是會編出同樣也是在繞很多路來做事情的機器碼，這樣並沒有比較高明。
但是我一直以來都在用相對「軟式」的 scripting language 做開發，常常還是會想「哪天我也可以做點比較『硬底子』、更貼近系統底層的東西」，如果可以這樣，自己是不是就可以更往 “bare-metal” 靠、更 rock 一點？
不過以我現在的狀況，我想了想，我必須選擇那些更能讓我表現 “intent” 的程式語言與工具，也就是那些雖然可能還是很「軟式」，卻可以一眼望去，就立即知道這段程式碼想要處理、解決什麼問題的程式語言與工具。
當然，scripting language 不盡然都可以很不反人類地表達 intent（為了怕傷感情，我就不多舉例了…），貼近系統底層的語言也不盡然就寫不出「高 Intent 表達力」的程式。所以我說的是，我接下來的技術選型，可以讓我更能表現 “intent”，粗糙一點來說，就是「同樣行數，卻更能涵蓋問題解法，且不管你資淺資深、本科非本科，有基本程式觀念的人都容易讀懂」的程式。
一來是因為我必須很容易找到人一起跟我共事，做出解決方案，二來，考慮我的生產力整個打折，我必須用更少時間，做出原來在正常工作日該有的產能。
再來就是，就算我沒能做出什麼揚名立萬、揚眉吐氣、超硬底子、超貼近系統底層的東西，只要我在這行，還能有點用處，解決一些其他人覺得很煩、很痛的問題，其實，就很好了。
補充：這篇網誌寫完後的晚間，我恰巧讀到〈尤雨溪回应：Vue与TypeScript为什么相性特别差？〉一文，其中提到 “intuition based design”，即符合我上面講的「表現 “intent”」這件事。我書讀的少，不知道有這麼一個現成的好詞可以表達我的意思，真是笑話了。