早前，看到有為網友在社群發了一個po文，深有感觸，妄言說要寫一篇文章來討論這件事。
有幾個討論面相，我先來說結論。
- 你所在的公司環境 !== 產業環境，如果覺得不理想，準備好換公司即可。
- 工程師都是在解決問題，可能是客戶的問題，可能是應用的問題，可能是資料的問題，選一個你所在行的解決問題方向。
- 選好方向，自然要掌握好工具，工具的掌握比例，取決於你要專精的方向，在很多時候，他都是一個組合，在業界和眾多前輩的經驗中，我們都知道，不可能只掌握一個技能，就真的能「很好」的解決客戶的問題。
- 所以多面向的知識基礎，那是必須的，但倘若要做到很好，選一個領域專精，再和其他優秀的人合作，成為一個T型人才。
以上，就是一個很安全，基本上往這個方向走，都不會出錯的發展路徑。
說完之後，是否覺得有一種在說廢話的感覺，道理我都懂，我就是做不到啊，讓我們來拆解。
專案做完了，你得到最寶貴的是「經驗」
年輕，最不值錢的就是時間，請用它去換取「經驗」，我敢肯定只要你付出絕對多的時間，你就能得到比同齡人更多的「經驗」
經驗，是多麼抽象浪漫的感概，很多年前我就常說的一句話「你是有10年的經驗，還是一個經驗用10年」
怎麼驗證這句話，等下看我第二點論述。
每次在專案開始前，很常和同事說的一句話就是，多想想這個要怎麼做，因為只要你想通了，這個方法就是你的，這就是你的經驗，不管到了哪裡，他都會跟隨你。
經驗不是執行的過程，而是思考、思辨、執行時遇到的問題、解決思路等等體驗綜合，光是執行，這經驗不值一提。
因為你無法對這個「回憶」做出任何的解釋。
曾經有那麼一個故事，我遇到前公司的成員來面試，因為都是認識的，所以對於內部的細節，大概都知道，所以當他在描述一些「經驗」的時候，我更在意的是：
- 為什麼要選擇這樣做？而不是那樣做？
- 這樣做之後，效果如何？如果再來一次，你會怎麼做？原因又是為什麼？
- 如果現在請你建議我做一樣的事，你會怎麼說。
如果你的答案是「我也不清楚，我主管交代的」、「我也不知道也」
那麼不妨下次在做每一件事之前，問一下自己，問一下身邊的人，為什麼你要做這件事。
你和一年前，有什麼不同
應該曾經被我帶過的同事，都會被我問過同樣的話。
如果你無法確實說出些什麼，那麼要小心，你可能就是那位「一個經驗，用了10年」的人。
當然這些不同，不僅僅是說，你學會了用next js 13，你知道了什麼前端監控，更多的事，你看事情的面向和深度上，有什麼不一樣的見解。
因為也只有這些思維，你才能理解甚至設計出更厲害的工具，解決更複雜或困難的問題。
很多時候，因為我們的認知有限，我們接觸的事物也很有限，很容易誤以為一些事物的進步，解釋為「內卷」
因為或許當下的你根本無法理解，為何這些技術需要存在。
但過度的「知識焦慮」是非常不健康的，所以我們只需要量力而為，和自己比較即可，若你想要的進步多一些，你就努力一些，若你想要有些不一樣即可，那你就放多點時間在其他興趣上，這沒有一定的標準。
但「強迫」自己改變，並非一件什麼十惡不赦的事，不妨嘗試看看，若你不滿意現在的自己，那就改變自己。
學習思考問題，而不是好好的寫Code
「我只想好好寫Code」member發自內心的說道。
我說「當然可以」，之後，我也沒再說什麼。
不知道什麼時候，有幾本書我都會推薦同事有空必須閱讀的，包括著名的《clean code》
然後見山不是山，所謂執行一些最佳實踐，並非是真的為了「工程」，而是為了解決問題。
我們想想，為什麼我們要那麼在乎這些實作方式，因為實際上，我們每天都要維護和改動我們的程式，如果你亂寫，可想而知之後要怎麼改？
很常有人開歡笑，看自己三個月前的code，根本不知道自己在寫什麼。
所以有些前輩總結了自己的經驗，「建議」你這樣做，會更好，所以精髓並非是「用了」什麼了不起的架構，而是你進行了不一樣的改變，這種改變，不需要被肯定，這種改變，將會在你日後的工作中，漸漸體現出他的價值。
其他方法、框架、技術、其實也是如此，當你真的想要好好寫code，其實背後含義是真，你如何優雅的解決問題.
如果你不去理解問題，你怎麼能好好寫code呢，因為你所謂的「好Code」造成公司大混亂，團隊之間新舊交替無法平衡，業務功能無法交付，那麼這時候，你堅持的「好架構，好方法」是不是真的「好」呢？這一點很值得我們反思。
不切實際的技術改動和盲目崇拜，往往會帶領團隊走向毀滅之路。
最後的建議，耐心
好的東西，都不是立竿見影，因為如果那麼輕鬆就可以獲得，那麼它就無法表現出稀有性，既然不稀有，那就到處都是，既然到處都是，你就會知道。
工程師的價值體現就是資訊差異和技術差異。
你能帶走的，就是這些差異所體現出來的價值，你給你自己和組織的價值，不然你想想，人家為何要花錢雇用你呢？
我也發現，有些工程師光是追求「認知」而不實事求是，那也是不行的，所有的技術都是必須，而且是基礎，當然每個人都有技術缺口，都有不知道事，那不是什麼丟人的事，不知道就不知道，基礎好，舉一反三，學一下就會了，重點是問題本身，而不是技術。
再次強調，技術還是很重要的，但那不是唯一要重視的事。
我很常給同事一些「難題」請他們回去思考，例如以下都是我問過他們的事情。
- 我有一個編輯器，怎麼做同步編輯？
- 我有一個多語系網站，怎麼設計一個系統讓客戶自己填語系，又可以很快整合到專案？
- 如何不上版，把網站轉導到維護頁。
- 如何做一個開放平台？
- 如何做一個售票後台？
- 只有一週，如何快速的把專案完成？
- 設計師一直改設計圖（客戶拿不定主意）怎麼辦？
- 如果不能用GA，自己怎麼做前端資訊收集？
- 文案一直改個不停，有什麼辦法不讓他影響開發流程？
…
不管單位小至只有10個人，到現在在台積電，這個習慣依然每天的圍繞我，每天都列了許多待解決，但還沒解決的問題，只要一有空，我就會弄髒手開始寫解決方案，他可能是一個流程，也可能是一個工具，甚至是一個平台。
給自己一些耐心，堅持做對的事情，好的事情自然會發生。
插入一則無情工商，那就是我本人的React課程，將在9月份進行，有興趣的朋友可以前往 https://www.modernweb.solutions/ 了解更多課程資訊。
