為什麼老程序員的效率如此高？
2個月前公司有一個35+的老程序員入職，和項目主管一個年紀，但是還是干技術，基本沒話，就是干自己的。公司暫時還沒有讓他挑大樑，他在我隔斷的斜上方，我觀察了他2個月，手速不快，滑鼠不快，碼字不快，我看他的代碼，中規中矩也沒有什麼特別的地方，但是工作進度就是快很多。
Three programmers were asked to cross a field and go to the house at the other side.
The novice programmer looks at the short distance and says, "it"s not far!. That will take me ten minutes"
The senior programmer looks at the field, thinks for a while and says "I should be able to get there in a day". The novice looks surprised.
The ninja programmer looks at the field and says. "Looks like ten minutes, but I think fifteen should be enough". The senior programmer sneers.
The novice programmer sets off, but within a few moments, explosive land mines go off, blasting huge holes. Taking him off course, and requiring him to double back and attempt the crossing many times. It takes him two days to reach the goal. Although he is shaking and injured when he arrives.
The senior programmer sets off on all fours. And carefully taps the ground searching for mines, proceeding only when it is safe. Slowly and meticulously he crosses the field over the course of the day. Only setting-off a couple of mines.
The ninja programmer sets off, and walks directly across the field. Purposefully and directly. He arrives at the other side in just ten minutes.
"How did you do it"?, the others ask. "How come the mines didn"t get you?"
"Easy" he replies. "I didn"t plant any mines in the first place".三個程序員被要求穿過一片田地，到達另一側的房子。
菜鳥程序員目測了一下之間很短的距離，說：「不遠！我只要十分鐘。」
資深程序員看了一眼田地，想了一會，說：「我應該能在一天內過去。」菜鳥程序員很驚訝。
大神程序員看了一眼田地，說：「看起來要十分鐘，但我覺得十五分鐘應該夠了。」 資深程序員冷笑了一聲。
菜鳥程序員出發了，但只過了一會，地雷爆炸了，炸出了巨大的洞。這下他必須偏移預定的路線，原路返回，反覆嘗試穿過田地。最後他花了兩天到達目的地，到的時候顫顫發抖，還受了傷。
資深程序員一出發就匍匐前進，仔細地拍打地面，尋找地雷，只有在安全的時候才前進。他在一天的時間內小心謹慎地緩慢爬過了這片地，只觸發了幾個地雷。
大神程序員出發之後徑直穿過了田地，十分果斷。他只用了十分鐘就到了另一邊。
「你是怎麼做到的？」另外兩個人問道，「那些地雷怎麼沒有傷到你？」「很簡單，」他回答道，「我最初就沒有埋地雷。」
原文是Glyn Williams"s answer to How do I train myself to code faster and with fewer bugs?
譯文是程序員如何做到『編程速度又快，Bug 數量又少』？
我想說的是,老程序員不是APM比你高,也不是思維比你快(純指反應速度)...
只是經驗比你多...基本不埋雷而已...
說不埋雷其實也只是一方面，因為一個人寫一個軟體做到死的情況是罕見的，所以老手也要去給別人掏糞挖雷插，哦不，擦屁股。
但是老程序員見得多了，這個世界上經常出現的bug一共就那麼幾種。
P.S.
說來我最近要參與一個office補丁的生命周期的過程，需要從一個古老的版本一直修到2016，那個bug在我還不會編程的時候已經存在了，只是居然20年來沒人遇到過（逃
期間就遇到了很多問題，我也只能去問一些寫了30年Office的老年人，解決起問題來超級快，根本不用思考。
主要還是見的多，所以也能說明為什麼有些人年紀大，但是水平不行，因為見的少。
IT的東西，很多時候真的是沒見過你怎麼都想不出的。
上周五有個項目提過來一個性能問題，說查了一個月，沒任何頭緒。
我問他們：
GC report有嗎？
沒有
AWR report 或者Trace file有嗎？
沒有
JVM flight record有嗎？
沒有
於是我好奇，你們查了一個月，到底差了什麼？
結果5，6個人，都說不出到底做了什麼有頭緒的事情。
因為IT的技術體系對於剛入門的新手，是線性的的，需要順著編程語言、數據結構、計算機體系結構、離散數學、編譯原理、操作系統一步步點亮技能。這是新手階段，此時戰鬥力成長速度是O(n)。
對於強一點的的熟手，可以再同時點亮網路基礎、資料庫、圖形學、動態語言、前端技術這些分支，形成技能樹。這可以算一轉，此時戰鬥力成長速度是是O(2^n)。
而對於已經有豐富經驗的老手，技能樹早已點滿，二轉飛升，跳出老鼠賽道進入快車道。
飛升後的老手，技能體系是圖狀的，此時戰鬥力成長速度是O(n!)。
明白差距為什麼那麼大了吧？
========以下大霧========
至於如何能夠快速飛升呢？
當然是修仙啊！
不然為啥程序員開發效率最高的時候永遠是在半夜？
題主觀察他兩個月不如請他吃頓飯，讓他告訴你一些工作方法。
老司機，躲紅燈抄近道，輕車熟路，你還堵在二環呢，人家已經繞道奔機場了，能不快嘛
老手程序員知道哪些事情不該去做，哪些路不要去走，所以趟的雷就少；新手覺得什麼都新鮮，什麼都要嘗試一下，所以容易自己被炸得灰頭土臉。
走的彎路少，心情好，效率怎麼可能不高。寫代碼這件事，事先設計好很重要，同樣是4小時工作，人家預先用了1個小時設計了代碼，一小時慢慢編寫，然後測試順便刷刷知乎什麼的。
而你一上來就寫代碼，寫到這個for發現前面的class缺了點東西，寫到這個if發現有些東西忘記做。
而在你空閑或者上廁所接水的時間，路過看到他當時的狀態，自然就是：卧槽這貨很閑，這貨手速很慢。寫代碼不是一天啪啪啪敲個幾千行然後刪來刪去的，而是一天的有效代碼（逃
當然經驗也是很重要的0.0
可以說樓主是倖存者偏差么（逃
因為會避坑。
普通程序員解決一個問題：
想三分鐘
寫半個小時
debug一周
遇到新的需求 推倒重來
寫兩個小時
debug一周
高級程序員遇到一個問題：
想三天 打滿了草稿和腳本
寫兩個小時
debug兩個小時
遇到新的需求
再寫半個小時
debug半個小時
知道為什麼人家快了吧坑踩過了就是很快，一切都很熟悉，不過其實踩坑是一方面，還有編碼能力和意識。
注意代碼分層、結構
新手寫程序，都喜歡把代碼全部寫在一起，我個人認為這個是屬於意識層面的，並需要太強的編程能力，通過看別人寫的代碼，還是能夠明白如何去組織代碼，拆分代碼的。核心思想就是「盡量每一個變數名有意義，每一個函數名有意義，每一個函數只干一件事情」
以早上起床上班為例子，新手版本喜歡這樣：
import 7788的能力
function getUpAndGotoWork(){
let i = 我;
i鬧鐘醒了，去關掉鬧鐘;
i賴床一下;
i起床了;
....
i去廁所，擠牙膏;
i刷牙;
i上廁所;
i洗臉;
....
i做早餐;
i終於出門了..
i上公車...
}
getUpAndGotoWork();
如果是老手，做法就是
function getup(i){
...
}
function fuckWC(i){
...
}
function fuckTheJob(i){
...
}
function Todo_Morning(){
let i = 我;
getup(i);//起床
fuckWC(i);//上廁所
fuckTheJob(i);//去上班
}
Todo_Morning();
這麼做的好處就是，對事件的抽象，以及屏蔽，各司其職，一個函數干一件事情，在Todo_Morning裡面，我們其實就是要干：起床，上廁所，然後去上班。其中的細節，Todo_Morning完全不用知道。
這一手漂亮的代碼，是之後維護代碼，寫單元測試，定位Bug的關鍵！這很大程度取決了你的代碼速度。
這一點，新手需要長期的訓練+看別人的源碼才能獲得，因此，老程序員因為練得多+看得多，所以就自然而然的幹得快。
這跟寫文章是類似的。
（一個35＋的來回答下）
在軟體工程的經典《人月神話》中作者提出好的程序員和差的可以達到100倍的效率差別，我還沒搞清怎麼做到的，但是現實中，好的程序員與差的程序員完全可以達到1：5到1：10的效率比。上次我聽到有人說某公司發展很快300人都不夠用，我半開玩笑說把這300人都裁了，用他們3倍的工資招30個人，你會發現所有的事情都做完了，公司也節約了70％的費用。
剛好在寫一相關Blog量化分析1：10是怎麼做到的。。。轉在下面
1個頂11個？程序員效率差距的量化分析
因為高危行業，時日不多，要學會珍惜時間
特別贊同@嘿嘿 關於事先設計的回答。自己做事情的時候也經常因為缺乏「大局觀」被老闆批評，教導我應該在動手前，先後退一步搞清楚目的和全部過程，再開始動手。如果一上來就一股腦的干，很可能會發現和既定目標不符合導致做了很多無用功還得返工推倒重來，反而效率低下。
這種「大局觀」，感覺除了通過經驗的積累，很難從其他的方法入手提高，可能這也是資深程序員和菜鳥程序員最大的區別了。
以下內容摘自邁克爾·劉易斯（Michael Lewis）的《高頻交易員》(Flash Boys)：
高盛一半以上的程序員都是俄羅斯人。俄羅斯人在華爾街久負盛名，他們被認為是最優秀的程序員，阿列尼科夫自認為了解個中緣由：俄羅斯人總是被迫在沒有充足上機時間的情況下學習計算機編程。多年之後，阿列尼科夫已經有了充足的上機時間，但他仍會在輸入計算機前先將代碼寫在紙上。他說：「在俄羅斯，上機時間是以分鐘計的。寫程序時，可供調試的時間非常有限，長期下來我們就學會了能夠把錯誤降到最低的編程方式。所以在你把代碼寫到紙上之前，你一定要考慮周全……而如果你有充足的上機時間，工作狀態通常是這樣的：當你腦中閃現一個想法的時候，你馬上就會在計算機上敲下來，之後可能會來來回回修改這個代碼上十遍。優秀的俄羅斯程序員通常都有一段在非常有限的上機時間內編程的經歷。」
另外，代碼自身的運行效率那就真的是比拼見多識廣以及智商的領域了，如@謝益輝大神所述：
在做計算之前，人的腦子多思考一分鐘，也許計算機的「腦子」 會少轉一個小時。
相關回答：Johnnie Drinker：俄羅斯人編程為什麼那麼厲害？
啊，打字好累呀。
程序員的動手能力很重要。所謂動手能力，其實是指動腦而不是動手。當然「動手」還是需要的，主要是為了避免程序員變成數學家。
經驗~
說多了都是故事
任何一個 成功的程序員 都是從 bug堆里爬出來了
沒有捷徑
之所以 你看他什麼都不快 但是進度快
原因很簡單， 思路清晰，目標明確，出錯率低
只有我一個人覺得是倖存者偏差嗎？？
效率低的早就轉崗了……謝邀。本人剛好過了35，搞軟體十三年，平時主要協調團隊各方面的資源、解決小夥伴的技術問題、編寫一些核心框架代碼和寫一些「有點難度」的業務代碼。簡單說一下我和小夥伴寫代碼的區別：
如果按照編寫業務代碼的能力，我和小夥伴的速度沒有太大差別，唯一區別可能就是我打字的時候基本不需要看鍵盤，盯著屏幕打字即使打錯了也可以及時更改過來，有些小夥伴打字的時候還要低頭看一下鍵盤，結果回頭一看屏幕發現打錯位置或者拼錯單詞了。
我在編寫代碼的時候，遇到重複的場景不願意把代碼直接抄過來，而是考慮代碼復用比較多，而小夥伴們完成工作的時候這方面的習慣還是不夠，經常是把代碼複製過來的，從而導致有些業務變更的時候，還需要找到N處進行修改。
當業務比較複雜的時候對代碼進行拆分封裝，不會在一個函數中實現一些複雜的判斷，寫東西的時候會比較嚴謹，所以看到問題的時候大多數看一眼前後文關係大多可以定位到問題根源，其實現在大多程序上的問題基本都是不夠嚴謹造成的。
還有就是寫程序的流程，就是自己心裡有個流程圖，按照流程圖去實現各方面的功能，然後再跑起來試一下，沒有輸出預期結果的時候就按照流程圖的步驟去排查原因，這樣只要記住關鍵代碼在哪裡就可以了，所以排查的時候也很容易找到問題，一個項目里的代碼是記不住的。
最後就是一個學習心態了，遇到新的東西或者問題，去探一下究竟，搞明白原因，對於基礎知識的學習是很有幫助的。
簡單問題，效率差異不大
但是複雜問題，有時候就不是效率差異了，是能不能弄出來的問題了
推薦閱讀：