我爸常跟我說的一句話是，慢一點碼，才能快點把程序寫完。

　　我在舊金山很多家互聯網公司工作過，現在已經 52 歲了，對于程序猿這個職業來說，我的年齡算偏大的。我寫代碼的速度近乎龜速，事實上，我更像是一個會寫代碼的設計師。

　　以前有一次，我和一些比較年輕的程序猿一起工作，他們信奉的編程宗旨是“速度快、更迭少”。我們在同一個 codebase 里合作，就像在共同煮一大鍋湯一樣。如果我們每個人都持續不間斷的貢獻代碼的話，未來這個工程應該就會很美很壯觀的呈現出來。

　　但是并沒有。

　　問題在于，這些年輕的程序猿們在心里其實有這么一種思想，他們覺得：1、每個人都是可替代的;2、沒人應該對某一部分的具體代碼負責;3、所有人應該都可以任意修改整個工程的代碼。

　　他們覺得，現在已經有了github這種神器用來管理異步時間內的代碼貢獻，只要每個人都持之以恒的貢獻代碼，工程和產品就會順理成章的出爐了。

　　事實不是這樣的。編程從來就不應該是拿工具來減少軟件開發的時間的。

　　編程應該是一項有節奏感有韻律的運動。我傾向于把工程依照不同的規模和時間度量分成不同的涂層，每一個涂層再從探索、實驗、error、臨時變量這些細小的東西開始做起。有點像建設腳手架的形式。每一個涂層最終完成的時候是一段可以部署和擴展的 implementation-ready 代碼。這種開發過程有點像是從策略到設計方案***到完成一棟真正的建筑。

　　有時候當這棟建筑完成之后，我還會推倒重來一遍，因為我覺得我有更好的建筑方法。這種新的方法有時候是對的，有時候是錯的，事實上除非真正去再做一遍，不然你永遠無法知道究竟哪一種方法更好。

　　回到最初那鍋湯的問題：在軟件開發生態圈里，關于對整個設計流程產生推動與支持的混合思考是很重要的，沒有這一部分的工作，再快的程序猿又能做出多好的設計?很多神經系統科學家相信神經元信息的流動在大腦的傳導過程中會有一個短暫的堵塞和混響，這對思維和感知會有很重要的作用。編程的設計也應該是這樣，需要時間。

　　慢速編程運動

　　慢速編程運動在維基百科里的解釋是這樣的：慢速編程運動是慢速運動的一部分，這是一種強調謹慎設計、高質量代碼、軟件測試和思考的軟件開發哲學，反對混雜組裝、布滿 bug 的代碼，以及過于快速的發布周期。

　　世界上的軟件開發團隊都在尋找更具預測性的工程項目，希望能促成更多的程序員擁有可持續性的職業生涯。他們提議了一些可以切身操作的實踐方法，比如結對編程、代碼審查和代碼重構，以開發更可靠更健壯的軟件應用。

　　在舊金山海灣地區，風險投資支持的軟件開發正呈現出一種高燒般的熱度。利益正驅動著軟件開發以一種完全不自然的不對拍的節奏感在運動，它打亂了設計進化(design evolution)原本應有的周期節律和生物鐘。關于這一點，Rushkoff在Present Shock里說得很明白了。

　　另一個問題在于，人們對科技越來越詭異的迷戀，以及開發人員對工具異常的狂熱。大家總在說，為什么有的軟件和應用做得這么爛?沒錯，確實很爛。爛的原因在于，太多一味求快的程序猿在忙著建設工具，然后用這個工具去支持和適配另一個他們建好的工具，然后再用這個工具去支持和適配另另一個他們建好的工具，然后再用這個工具幫他們寫出更快的代碼。

　　這就是我為什么覺得軟件開發需要更多的“人”，而不是“工具”的原因。并且，這些人不僅僅只是幫忙做做外面的 UI 藝術之類的而已，應該要有更多的人深入軟件開發的內部——確保軟件更多的與人文產生共鳴和回響。

　　當我們談論編程時，我們在談論什么?

　　編程不是打字。

　　所有的程序猿都明白這一點，但是大部分人都容易忘記這一點。

　　我妻子有時會跑到院子里問我，你在編程嗎?我說，對，我在編程。事實上我可能正拿著鉗子修剪花盆里的花草，或者做做施化肥之類的事情。

　　植物、土壤、鉗子，這些都是編程的好工具，正如鍵盤、鼠標和雙屏幕一樣。

　　目前，我們正在經歷一個經濟產業的轉型期，從新興到可持續發展之間的一次過渡。新的軟件產品和商業模式是需要發展，但為了互聯網行業發展的可持續性，這種速度應該降下來一些了。擼代碼不僅僅只是在擼當下用戶的需求，擼的更是未來某個行業領域的架構基礎。代碼應該在程序員的關愛下慢慢的、茁壯的成長。Like good wine. Like a baby.