軟件工程師通常認為好的軟件是采用正確的模式、遵守規(guī)范、制定規(guī)則、遵循最佳實踐和正確處理流程的產(chǎn)物。

但程序員知道這些都是狗屎。

相對于建設一座大橋，編寫代碼更像是創(chuàng)作音樂，編寫書籍，拍攝電影，或者是繪畫。事實上，編寫代碼更難。這需要我們做更多，使我們的產(chǎn)品不僅僅是好看或者好聽那么簡單。大家知道，好的音樂、繪畫、文學作品不是關于如何循規(guī)蹈矩，更多的是關于如何打破常規(guī)，探索新想法。你以為音樂排行榜或者最佳銷售榜上那些最流行的作品是因為遵守了什么標準或者規(guī)范而上榜的嗎？如果是那樣，那些榜單將會變得很不一樣，而且也不那么流行，因為社會在向前發(fā)展，總會出現(xiàn)新事物，或者以不一樣的觀念審視舊事物，而且永遠不會停止。

最好的程序員能夠簡單自然的完成他們想做的事情，工作穩(wěn)定，而且有足夠的直覺讓自己不那么討厭。通常那些被忽視的東西，要比顯而易見的東西要重要的多。比如：相對于一個可配置的軟件，我們更希望得到一個可以自己完成配置，或者干脆不需要配置的軟件。我們大概沒有意識到身邊存在許許多多正在使用的運行良好的軟件，因為它們只是在默默的在運行，我們不需要關心或者擔心他們。當軟件出現(xiàn)問題的時候，我們才會關心那些“軟件工程師”是不是遵循了規(guī)范和流程，軟件崩潰讓我們很滿腦，因為軟件是一樣關注人，關注解決問題的東西，而不僅是工具或者技術（直到有一天，你嘗試了各種各樣的軟件最后發(fā)現(xiàn)一款合適的軟件的時候才能深刻的理解這一點），也不是其他什么。當軟件好用的讓我們吃驚時，我們?nèi)匀徊粫浀檬裁匆?guī)范什么流程，除非我們做過類似的事情。所以看起來只有軟件工程師關心規(guī)范或者流程之類的東西。

我發(fā)現(xiàn)那些傾向于工程師的心態(tài)， 傾向于聚焦技術、代碼、流程是否被正確執(zhí)行、以及測量那些武斷的規(guī)范或風格的執(zhí)行是否到位 的人往往忽略了真正的問題是否被解決了？使用者的真正需要是什么？好的軟件能夠在用戶體驗、實際問題以及技術之間取得平衡。最好的結(jié)果通常來源于對三者都做微小的修改，但是如只聚焦于工程本身，那就顯得過于短視。

當被要求遵守規(guī)范的時候、當糾結(jié)于繁復的流程的時候創(chuàng)造力被扼殺了，這是個問題。大部分主流的指導和流程是對管理友好的，管理者得到了他們想要的東西。但是軟件工業(yè)發(fā)展非?？?， 真正的創(chuàng)新不會產(chǎn)生自“最佳實踐”。當工程師還在糾結(jié)于流程的時候，程序員則在不斷創(chuàng)新，不斷尋找更先進方法，這時候他們也許不會遵守流程，不會按部就班，但是他們往往能成功。

舉個例子：也許大約200行 Node.js 代碼也許能比10000行 java EE 代碼更好跟容易的解決問題？也許稍微修改一下用戶需求能大幅降低實現(xiàn)的復雜度？

當用戶體驗、軟件功能、技術實現(xiàn)出現(xiàn)沖突的時候，只有程序員能看透其中的奧秘。而軟件工程師傾向于忽略這些問題，因為在搞清楚到底出了什么問題之前他們已經(jīng)決定該如何解決了。他們會控制變更，好像問題會自己修復一樣。

當我14歲的時候我成為了一名程序員（自學的），后來我成為了設計師、架構(gòu)師，然后我意識到我整天只是在畫流程圖，編寫文檔，這是在浪費時間，而且感覺糟透了。我現(xiàn)在48歲我又開始寫代碼了， 而且很喜歡，這是因為相比之前，我能讓軟件變得更快更好，讓它能真正滿足用戶的需求， 而不是整天在宏觀層面胡扯。

有些人認為雇傭工程師能夠帶來比卑微的‘程序員’更多的穩(wěn)定性，但我更愿意雇傭程序員或者叫軟件開發(fā)者，因為工程是反自然的，比如鋼筋混凝土，我們?nèi)绻_的安裝它，但是計算機、人、軟件并不是這樣運作的，想想一下你需要給一個飛行中的飛機更換零件。

對于我而言，編程和軟件開發(fā)不僅僅是需要實踐的天賦或藝術，雖然它的確需要一些規(guī)矩，而更多的是關于創(chuàng)造一些真正的新的充滿希望的，讓人快樂的或者能夠帶來真正價值的東西。