TL;DR
今年還沒躺平。
你不是喜歡寫程式的人，是用程式吃飯的。
年前 CEO 這麼對我說，後面接著一段話:
像我跟他(指主管)是喜歡寫程式的，沒人打擾的話我們可以在家一直玩這些。
跟主管借了《Clean Architecture》來看，每次在看軟體「工程」的書時，都備感挫折。《程式設計師的自我修養－連結、載入、程式庫》 中提到的編譯器、連結器，我壓根就沒學過，這種滿滿的挫折感，在 Clean Architecture 中得到了解答。
台灣的資訊系在國外的最正統名稱是 Computer Science a.k.a. C.S.，而我的學士學位是資訊管理 Department of Information Management，我們接受的教育是怎麼去快速理解 domain，並在運用該領域的領域知識開發輔助用的資訊系統，課程著重在 ERP、CRM、KMS 等等資訊管理系統(MIS)。作業系統課程不會教你減少分支預測帶來的好處，資料庫管理課程不會教 Lock Level 把整張表鎖起來會被罵，資料結構課程不會教你怎麼用程式實作 linked list、tree，程式設計課程更不會去看你的時間/空間複雜度。
或許也只能怪自己在念書時得過且過，讓現在的自己需要花時間去補其他人早就知道的知識。
似乎也是因為這種挫折感給了自己莫大的動力，不想輸給「本科系」的學生，雖然已經 25 歲了，但及早發現及早治療吧?過去總是喜歡把不理解的部分都弄懂才往下一步走，也是慢慢地改變自己且戰且走、以戰養戰。
舉例來說，如果要把整個公司專案的程式碼、技術債的原因、神秘數字的由來、歷史共業等等，全部都摸熟才能開始寫 code，那可能就會失去許多成長的機會。
工作不像在學校，不會要求你每次都要一百分，應該是先做出 60 分，甚至 40 分，再慢慢迭代成 100 分。
CEO 如此說著，也符合軟體開發流程迭代機制，先拿 prototype 去撈錢再來修(?)。
除了有些設計原則是需要最初就先講好比較好(e.g. Cloud Native, API First)，似乎沒有甚麼是「非這麼做不可」，更多的是「不要這麼做比較好」。
言歸正傳，對 2023 年的展望呢，希望身體健康，也希望能拉近與同儕間的距離，多少不想輸給碩畢的同學XD。