「不要把所有雞蛋放在一個籃子里。」這句話出現在一篇講軟件開發的博客里,作者卻是在聊怎么做手工鋼筆。
一個開發者為什么要去車床旁邊削木頭?這種看似無關的跨界,恰恰暴露了技術行業容易忽視的問題:我們把技能困在了屏幕里。
![]()
兩種手藝,同一套底層邏輯
作者的核心發現很直接——軟件開發里那些反復驗證的方法論,在鋼筆制作中完全適用。不是比喻,是字面意義上的同一套操作。
模塊化設計(Modularity)是第一個被驗證的。鋼筆的握把部分可以單獨更換,就像代碼里的組件化。作者確實這么干了:第一次做的握把材料不滿意,拆下來換到另一支筆上繼續用。「模塊化設計的好處」——他原話如此。
迭代開發(Iteration)緊隨其后。沒有一次性做出完美成品的幻想,而是快速出原型、測試、調整。這種「先做出來,再改」的節奏,和敏捷開發里的MVP(最小可行產品,Minimum Viable Product)思路一模一樣。
減少摩擦(Reducing Friction)是第三個被點名的原則。讓流程更順暢,降低重復勞動的成本。無論是配置開發環境,還是準備車床刀具,核心都是消除阻礙你進入「心流」狀態的障礙。
正方:跨界是技能的試金石
支持這種觀點的人會強調一個關鍵收益:具象化驗證。
當你只在代碼里實踐這些原則時,它們很容易變成教條。為什么要有模塊化?因為書上這么說。為什么要迭代?因為Scrum流程這么規定。
但當你親手做一支筆,看著模塊化的握把真的能從A筆拆下來裝到B筆上,迭代的價值就從抽象概念變成了可觸摸的事實。作者的原話是:「你能看到這些技能被應用在一個具象的項目里,這才強調了那些規則的重要性。你學會了規則為什么存在,而不是盲目遵循。」
這種理解深度是單純寫代碼很難達到的。代碼的運行結果還是代碼,而鋼筆是物理實體——它能漏水、能開裂、能握在手里不舒服。反饋是即時的、無法忽略的。
另一個隱性收益是動機管理。作者提到「慶祝小勝利來維持動力」,這在長期項目里尤其關鍵。SaaS開發周期漫長,而一支鋼筆幾小時就能見雛形。快速閉環帶來的成就感,可以反哺主業的耐力。
反方:警惕浪漫化的分心
但另一種聲音會問:這會不會只是給「不務正業」找的漂亮借口?
時間成本是真實的。作者自己也承認SaaS項目「還在開發中」——主業并未完成。手工制作的沉沒成本更高:設備、材料、學習曲線。如果三個月后發現鋼筆制作只是階段性興趣,這筆投入怎么算?
技能遷移的效率也值得質疑。軟件開發的核心挑戰——系統復雜性、團隊協作、技術債務——在單人手工項目里幾乎不存在。模塊化在代碼里是架構決策,在鋼筆里只是物理接口設計。難度系數差了幾個數量級。
更尖銳的批評是:這種類比可能強化一種有害的認知,即「好的開發者應該無所不能」。實際上,深度專業化才是行業主流。你不需要會車床也能寫出優秀的微服務架構。
我的判斷:不是技能遷移,是認知校準
兩種觀點都有道理,但作者真正想說的不是「做鋼筆讓你成為更好的程序員」。
他的核心主張被埋在一句話里:「學習新東西,把這些教訓應用到你已知的領域。」注意順序——先學習,再應用。鋼筆制作的價值不在于技能本身,而在于它創造了一個「可控的陌生環境」。
在這個環境里,你熟悉的原則被剝離了技術細節,裸露出本質。模塊化不再是React組件或Java接口,就是「這部分可以換」。迭代不再是兩周的Sprint,就是「這次做得不好,下次調整」。這種去語境化的理解,反而能幫你看清主業里哪些做法是真正必要的,哪些只是慣性。
作者最后展示的鋼筆照片透露了更多信息:握把和筆身的顏色不匹配,明顯是后期替換的痕跡。他沒有隱藏這個「瑕疵」,反而標注出來——這是迭代過程的物證。
這種坦誠本身就值得注意。技術博客往往展示成品的光鮮,而作者選擇暴露中間狀態。這和他倡導的原則一致:過程比結果更值得記錄。
所以這件事的重要性不在于「開發者都該去做手工」,而在于提醒我們:技能的上限往往被「應用場景」限制。當你只在一種環境里使用某種能力,你很難區分「真正理解」和「熟練模仿」。
找一個足夠遠的領域,把你的方法論扔進去測試。如果它還能跑通,說明你真的懂。如果跑不通,說明之前的理解有盲區——這本身就是收獲。
你的SaaS項目卡住了?也許問題不在代碼里。去試試完全不相關的事,然后帶著新問題回來。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.