「沒有前輩帶、很多東西都靠自己摸索，一個人寫程式一路成長。」

雖然我主要是寫前端，但前端真的是一份很需要跟人溝通的工作，而且大部分公司這個職位都只有你一個。Alone，可憐。但我就喜歡。哈哈

這份工作你需要理解專案產品在做什麼，什麼情境下使用，畫面要怎麼安排，需求等等...因此你需要面對主管、PM、設計師、其他工程師...

其實你最大負責的工作就是——「通靈」。大部分是通靈老闆主管在想什麼，按照他們的需求去做，你也會遇到上頭沒想法，所以你要先自己做出某個程度，他們就會告訴你哪裡需要修改，甚至有時候做出來他們也只說個「好」或「不好」，要自己想出接下來的功能。

有時候會遇到亂寫 Interface 的工程師就需要通靈他寫出來的這坨鬼架構是什麼。
Object 裡面包 Object 再包 Object，包了祖宗十八代。參數收 apple 跟 APPLE 但功能完全不一樣，到底誰可以記得大寫 APPLE 是回傳蘋果還是收頻果還是丟掉蘋果呢？但你記住了，小寫的 apple 做的絕對不是上面那些事情！絕對！

你要包含介面設計，先畫個 Figma 給人看，如果老闆看不懂，那你就自己畫完之後用程式做成網頁給他看。

功能實作，老闆說這裡怎麼不會動呀？ 那你就要說這是設計雛形，功能之後補給你（老闆都會以為有畫面就可以用了）

輸入的範圍值確認，避免有人手殘輸入錯誤或按錯，跟後端工程師溝通功能，有時候雞同鴨講，有時候對方搞不清楚 Restful API，有時候對方說我自己電腦用可以啊為什麼你不能接...諸如此類的。

你要會使用 Docker ，你要會搞定電腦環境，你要會 Linux...你還要在大會議室裡用投影片交接，教會所有不是工程師的人寫你的程式碼！

可能我命主天同，一生鳥事不斷ＸＤ

但上面這些還不夠，你最好還要會後端的語言框架，你最好一個人可以包山包海。

之前看 Dcard 感情版有網友說：
「
感情不是靠心動撐到現在
而是靠一次次把對方看清
卻還願意留下來
」

寫程式也是，靠著一次次看清職場光怪陸離的生態，但你還願意寫，你還是很喜歡這份當碼農的工作。

有時候最大的成就感，是跟著同事一起完成某個功能，一起解出某個 BUG，一起討論解決方案的那個當下，可能就是寫程式最幸福的事情。

我還是很喜歡寫程式，雖然寫的不是特別優秀，像是面試那種從來不會出現在實作上的考題我都特別爛...🥲還有數學...

但我都能在各種公司的指揮下完成一份漂亮的專案，主管讚賞的比例是很高的。至少實作能力方面是完全沒問題甚至超出期待，不然前公司也不會從老闆副總一路到主管都叫我留下來了吧ＸＤ

這裡就要講一下我的人格特質，我的個性會想把東西做到最好，事情提前做完會去找主管要新工作，摸魚偷懶對我來說非常痛苦，我非常需要上班有工作可以做！換句話說我是相當喜歡上班寫程式的！哈哈。如果主管可以教會我新的東西我會相當期待上班這件事。

但我下班就是下班，不太會再自己去寫程式，這可能是跟其他超厲害的工程師的分岔點XD

但說真的，單獨的前端基礎職缺大概會完全消失，因為 AI 的關係，但要往上爬到非常非常厲害的前端，我覺得我好像做不來。

因此我考慮了很多次應該轉去寫後端。

我學了 PHP、C#、Python ，但就是有概念，對資料庫也有概念，甚至之前工作上也開始寫了一點點，但我還是覺得跟他們不太熟。

不熟的程度是看AI的產出我看不出問題，但這會是個大問題。如果是 React 的話我看一眼就明白了。

這大概就是寫的時間的差距，我寫太少了，寫得還不夠多，我要練到可以從一片空白中自己架架構，自己寫出來，自己無中生有。

到這種程度了，我才敢自稱是後端工程師。

本來只是想幫AI的摘要打個前言的，卻不知不覺打了這麼多字。哈哈

聽說我的紫微斗數命盤很適合寫，我也覺得寫文字很有趣，但這個目前應該賺不到幾個錢XD

正文開始：

這些年寫程式一路走來看過很多工程師，我覺得程式寫的好的工程師都有以下幾個特質（以下來自 Gemini 摘要）

一、 獨自一人時，該如何讓程式持續進步？

當團隊沒有其他人能給予反饋時，你需要建立「自我反饋」與「外部借力」的機制：

1. 建立「與過去的自己 Code Review」的習慣

• 間隔審視：寫完功能後不要立刻結案，隔一兩週甚至一個月後重新回頭看自己寫的程式碼。如果你覺得當時寫得很爛、有更好的重構方式，代表你這段時間進步了。

• 自訂 Check List：針對可讀性、擴充性、效能與例外處理，條列檢查清單。每次提交前用更高標準審視自己的 Commit。

2. 把 AI 與開源專案當成導師

• 讓 AI 做 Code Review：將非機密的程式片段丟給 AI（如 ChatGPT, Claude, Cursor），問它：「這段程式碼有何效能瓶頸、資安風險或可讀性問題？如果是 Senior 會怎麼重構？」

  （我的想法是你也要可以看得懂AI是 over design 還是他只是為了重構而重構。）

• 深度閱讀優質開源專案：看知名框架或熱門 Lib 的原始碼（Source Code），學習大廠或頂尖開發者如何設計 API 介面、處理錯誤與組織專案結構。

3. 設計「極限壓力測試」與自動化

• 強制撰寫單元測試（Unit Test）與整合測試：好的測試會逼你寫出低耦合、高內聚（Clean Code）的程式碼。如果程式碼很難寫測試，通常代表模組設計有問題。

• 建立 CI/CD 與自動化 Linter：導入最嚴格的 ESlint / Static Analysis 規則，讓工具成為你第一個技術把關者。

4. 主動走出閉門造車的環境

• 參與社群與技術聚會：參加研討會、技術論壇或社群（如 Meetup、Discord 技術群），看看別的公司遇到了什麼問題、用什麼架構解決。

• 嘗試寫技術文章或筆記：用「費曼學習法」把研究過的新技術寫成 Blog 或筆記。能清晰解釋給別人聽，才代表自己真正掌握了。

二、 程式能持續進步的人，有哪些人格特質？

技術進步極快的人，通常具備以下幾種核心特質：

• 極強的好奇心與「玩具心態」（Curiosity & Playfulness）

  • 他們看到新技術時，第一反應不是「又要有新東西要學了，好累」，而是「這好酷！它是怎麼做到的？能不能拿來解決我現在的問題？」。他們把寫程式當成疊積木或玩遊戲，從探索中獲得正向回饋。

• 耐得住孤獨的「死磕精神」（Pragmatic Obsession）

  • 遇到 Bug 或效能瓶頸時，一般人可能「改到能跑就好」，但他們會想「為什麼這裡會這樣？底層邏輯是什麼？」。這種想挖到最底層的偏執，會讓知識體系變得非常紮實。

• 對「混亂」低容忍度（Pragmatism & Order）

  • 他們無法忍受冗長、重複或難以維護的爛程式碼。只要看到不順眼的地方，就會忍不住想把它重構得優雅、簡潔。這種對質感的追求是驅動技術精進的隱形動力。

• 高主動性與自驅力（Autonomy）

  • 他們不等待別人給任務或指引方向，而是主動發現問題、尋找新工具，甚至自發性地去改進現有的架構與開發流程。

結語

我大概有遇過二個真的很厲害的工程師，從他們身上真的學到很多。

還有一項特質 Gemini 沒說，這才是最重要的，就是要聽得懂人話，就是要溝通！要會溝通，會講人類自然語言！

這雖然很像屁話，但如果你跟夠多工程師合作過的話就懂我在說什麼XD

祝福大家都可以找到自己適合的位置，待在適合的位置，發揮所長。