做一支鋼筆教會我的開發(fā)思維

「不要把所有雞蛋放在一個籃子里。」這句話出現(xiàn)在一篇講軟件開發(fā)的博客里，作者卻是在聊怎么做手工鋼筆。

一個開發(fā)者為什么要去車床旁邊削木頭？這種看似無關(guān)的跨界，恰恰暴露了技術(shù)行業(yè)容易忽視的問題：我們把技能困在了屏幕里。

兩種手藝，同一套底層邏輯

作者的核心發(fā)現(xiàn)很直接——軟件開發(fā)里那些反復(fù)驗證的方法論，在鋼筆制作中完全適用。不是比喻，是字面意義上的同一套操作。

模塊化設(shè)計（Modularity）是第一個被驗證的。鋼筆的握把部分可以單獨更換，就像代碼里的組件化。作者確實這么干了：第一次做的握把材料不滿意，拆下來換到另一支筆上繼續(xù)用。「模塊化設(shè)計的好處」——他原話如此。

迭代開發(fā)（Iteration）緊隨其后。沒有一次性做出完美成品的幻想，而是快速出原型、測試、調(diào)整。這種「先做出來，再改」的節(jié)奏，和敏捷開發(fā)里的MVP（最小可行產(chǎn)品，Minimum Viable Product）思路一模一樣。

減少摩擦（Reducing Friction）是第三個被點名的原則。讓流程更順暢，降低重復(fù)勞動的成本。無論是配置開發(fā)環(huán)境，還是準(zhǔn)備車床刀具，核心都是消除阻礙你進(jìn)入「心流」?fàn)顟B(tài)的障礙。

正方：跨界是技能的試金石

支持這種觀點的人會強調(diào)一個關(guān)鍵收益：具象化驗證。

當(dāng)你只在代碼里實踐這些原則時，它們很容易變成教條。為什么要有模塊化？因為書上這么說。為什么要迭代？因為Scrum流程這么規(guī)定。

但當(dāng)你親手做一支筆，看著模塊化的握把真的能從A筆拆下來裝到B筆上，迭代的價值就從抽象概念變成了可觸摸的事實。作者的原話是：「你能看到這些技能被應(yīng)用在一個具象的項目里，這才強調(diào)了那些規(guī)則的重要性。你學(xué)會了規(guī)則為什么存在，而不是盲目遵循。」

這種理解深度是單純寫代碼很難達(dá)到的。代碼的運行結(jié)果還是代碼，而鋼筆是物理實體——它能漏水、能開裂、能握在手里不舒服。反饋是即時的、無法忽略的。

另一個隱性收益是動機管理。作者提到「慶祝小勝利來維持動力」，這在長期項目里尤其關(guān)鍵。SaaS開發(fā)周期漫長，而一支鋼筆幾小時就能見雛形。快速閉環(huán)帶來的成就感，可以反哺主業(yè)的耐力。

反方：警惕浪漫化的分心

但另一種聲音會問：這會不會只是給「不務(wù)正業(yè)」找的漂亮借口？

時間成本是真實的。作者自己也承認(rèn)SaaS項目「還在開發(fā)中」——主業(yè)并未完成。手工制作的沉沒成本更高：設(shè)備、材料、學(xué)習(xí)曲線。如果三個月后發(fā)現(xiàn)鋼筆制作只是階段性興趣，這筆投入怎么算？

技能遷移的效率也值得質(zhì)疑。軟件開發(fā)的核心挑戰(zhàn)——系統(tǒng)復(fù)雜性、團(tuán)隊協(xié)作、技術(shù)債務(wù)——在單人手工項目里幾乎不存在。模塊化在代碼里是架構(gòu)決策，在鋼筆里只是物理接口設(shè)計。難度系數(shù)差了幾個數(shù)量級。

更尖銳的批評是：這種類比可能強化一種有害的認(rèn)知，即「好的開發(fā)者應(yīng)該無所不能」。實際上，深度專業(yè)化才是行業(yè)主流。你不需要會車床也能寫出優(yōu)秀的微服務(wù)架構(gòu)。

我的判斷：不是技能遷移，是認(rèn)知校準(zhǔn)

兩種觀點都有道理，但作者真正想說的不是「做鋼筆讓你成為更好的程序員」。

他的核心主張被埋在一句話里：「學(xué)習(xí)新東西，把這些教訓(xùn)應(yīng)用到你已知的領(lǐng)域。」注意順序——先學(xué)習(xí)，再應(yīng)用。鋼筆制作的價值不在于技能本身，而在于它創(chuàng)造了一個「可控的陌生環(huán)境」。

在這個環(huán)境里，你熟悉的原則被剝離了技術(shù)細(xì)節(jié)，裸露出本質(zhì)。模塊化不再是React組件或Java接口，就是「這部分可以換」。迭代不再是兩周的Sprint，就是「這次做得不好，下次調(diào)整」。這種去語境化的理解，反而能幫你看清主業(yè)里哪些做法是真正必要的，哪些只是慣性。

作者最后展示的鋼筆照片透露了更多信息：握把和筆身的顏色不匹配，明顯是后期替換的痕跡。他沒有隱藏這個「瑕疵」，反而標(biāo)注出來——這是迭代過程的物證。

這種坦誠本身就值得注意。技術(shù)博客往往展示成品的光鮮，而作者選擇暴露中間狀態(tài)。這和他倡導(dǎo)的原則一致：過程比結(jié)果更值得記錄。

所以這件事的重要性不在于「開發(fā)者都該去做手工」，而在于提醒我們：技能的上限往往被「應(yīng)用場景」限制。當(dāng)你只在一種環(huán)境里使用某種能力，你很難區(qū)分「真正理解」和「熟練模仿」。

找一個足夠遠(yuǎn)的領(lǐng)域，把你的方法論扔進(jìn)去測試。如果它還能跑通，說明你真的懂。如果跑不通，說明之前的理解有盲區(qū)——這本身就是收獲。

你的SaaS項目卡住了？也許問題不在代碼里。去試試完全不相關(guān)的事，然后帶著新問題回來。