寫程式不是打字。大部分時間是在思考，除錯和修改。

程式設計師一天時間寫出來的程式碼，讓打字員照著打一遍，可能連一個小時都用不了。但是這些可能真的是他們用了一天才寫出來的。有的時候費了一兩天寫那麼一段程式碼，最後測試還有bug。

所以程式設計師不比流水線工人，一個小時生產100個零件，8小時就能生產800個，加四小時班又生產400個。

產出和時間有關，但是關係不大。

純腦力工作者的產出主要跟：

個人的興趣愛好、思維方式、技術水平、認知程度和做事態度決定的。

有些人花費好長時間好幾天功能寫了好多行程式碼結果無非有以下幾種：

1、功能實現了，沒有bug.

2、功能實現了，有bug.

3、功能勉強實現了，一堆bug.

4、功能未實現還一堆bug.

而有的人，只花了幾個小時或者小半天功夫只碼了很少的程式碼就實現了功能而且幾乎no bug。這種人我們叫人才，放在it領域就是高階程式設計師、軟體設計師……

而前面的1和2只能說是勉強合格，距離對企業真正發揮作用的人才還有距離.而3還有點救，4直接就是廢材幾乎可以pass掉，對單位來說就是毒瘤定時炸彈，說爆就炸。

所以，程式設計師的產出和時間關係不大。畢竟不是工廠流水線可以計件可以用時間來衡量。

我來解答這個問題：

例：工作8小時，6個小時在看網頁、低頭、喝點飲品、抽根菸，2個小時埋頭寫程式碼，你覺得他只工作了2個小時嗎？其他6個小時是在做無用功或者是偷懶？

答：程式設計師一般接到一個任務時，他的腦海裡會有這個專案的思路，這個思路是很重要的，一旦這個思路出現問題，他就寫不了程式，很多程式設計師在遇到問題、困難的時候都會查詢網頁看看有沒有相關解決方法，一般的解決方法，也不是適用每個專案，都需要程式設計師對自身專案進行思考、修改，這都是需要時間的，有的時候不是說想明白就能想明白的，可能你出去溜達一下、放鬆一下回來就想通了呢？

寫程式是需要感覺的，感覺來了一個功能可能十幾分鍾就能寫出來，沒感覺的時候，兩天都不一定能寫出來，不能用時間來衡量。

怎麼可能，提這個問題的同學可能不瞭解網際網路，看看各大網際網路公司996的工作時間就知道不加班你只能是一個普通的公司

我寫程式碼的時候，就得老查資料看部落格借鑑他人的思路，而那些大神們直接就寫出來了，至少這一部分時間省了，或許人家寫的還比我好哈哈哈。

很現實地說，如果你不是超級聰明的技術咖，那你的問題的答案是肯定的。程式設計師的產出是需要付出比一般職業的人多時間的，畢竟碼程式碼不是個簡單的活。但是這個技術活會隨著你付出而收穫更多，如果你不付出更多的時間，如何去學習更多的知識與積累更多的經驗。

最近吃雞類遊戲極為火爆；現在還新出現了一個叫APEX的。

這個APEX是免費的。你只需付出一點時間下載就能把它裝到你的電腦上。

現在，我們要利用它的資料統計功能。

你可以多找幾個人，統計一下他們每天的擊殺數，很容易就能拿到量化的“產出資料”

實驗準備： 認真打一星期APEX，每天四個小時，使得實驗參與者的遊戲水平進入穩定期。

實驗一： 連續兩星期，每工作日遊戲四個小時，統計每天擊殺數。

實驗二：連續兩星期，每工作日遊戲八小時，統計每天擊殺數。

實驗三：連續兩星期，一週六天，每天遊戲十二小時，統計每天擊殺數。

在下是個FPS鐵桿粉絲。不過我玩的是CS。

根據我自己的遊戲經驗，資料如下：

1、每天遊戲四小時

按平均每局3分鐘算；在合理遊戲、保持精力充沛的前提下，我可以做到場均擊殺3人。也就是每天可擊殺240人左右。

2、每天遊戲八小時

一般連續遊戲兩小時以上，玩家就會出現眼花、嗜睡等症狀；使得之後場均擊殺不到1人——其實我很少連續玩兩小時以上，中間一定會休息；休息後精力基本恢復，但一般再玩一小時左右就會再次疲憊，而且恢復越來越慢。

這會造成成績不佳，但隔一晚後可完全恢復。

加起來，一天至多也就是6小時滿狀態加2小時疲勞狀態，360+40=400人左右。

3、每天遊戲十二小時

學生時代的瘋狂。通宵玩遊戲是很多人都經歷過的。

年輕人恢復快，一般玩一天/一個通宵，第二天睡一整天就差不多了。

但如果持續通宵，很容易出現眼前重影、看螢幕流淚、精神不集中等症狀。壓根不是睡一兩天能休息過來的。

其中最嚴重一次使得我一個月後都還只能眯著眼看螢幕；螢幕突然一亮我就淚兩行——當然，那次是因為挨個把Windows 95系統資料夾下的所有檔案全都研究了一遍，不是玩遊戲。

總之，在這種極度疲憊的情況下，連續若干局0擊殺是常事。

因為此刻玩家已經不是有意識的在玩遊戲，而是隨緣打上兩槍應付應付罷了。不然眼睛腦子手腕全都受不了。

在這種狀況下，一個人一天十二小時加起來，能拿100到200人頭已經很了不得了——這還是手打熟了、水平提升的結果。

你可以找一些志願者測一測，看看是不是每天超過8小時，打的越多每天人頭數反而越少。

這還只是玩遊戲。滑鼠追逐螢幕上的小點、然後點下左鍵的體力勞動。

但哪怕這種勞動，我們也能輕易的發現，更長的“上班時間”不僅不能提升工作效率，反倒會影響潛在高手的發揮（人與人對抗中，每局一個人頭就已經是中等偏上水平了），造成一種“每天遊戲時間越長水平越慘；水平越慘，打到某個人頭數就需要越長的遊戲時間”的惡性迴圈。

寫完站不起來了。之後近一個月精神無法集中，沒有再寫一行程式碼。

從那以後，我學會了合理安排自己的工作時間，每天進入極度專注時間不超過4小時。

即便如此，我的工作效率在同事之間也屬於第一梯隊。

之前我在一些帖子裡提到過，我曾一年搞定十三項任務，還寫了兩份A級文件和十幾份B級文件；同組其他同事最快也不過一年完成四項任務。

因為這事，後來新上任的一小頭目還糾集一幫人在我和前女友之間攪風攪雨。使得我實名在各大IT論壇揭批此人。

很顯然，當一個人精力完全投入工作時，一天4小時足夠達到最大產出；熬更長時間反而損傷長久產出能力。

但“精力完全投入工作”是個很難量化的引數；而且完全投入狀態並不是說來就來的。因此8小時工作相對較為平衡。

但是，和玩遊戲不同，軟體業的產出很難衡量。

甚至，一整天屁事不幹，就琢磨著對同事下手，拿的KPI可能一樣多——會玩手段說不定還能更多一些。

就好像有人挖苦的那樣：程式碼質量很高，結果經理一看，沒多少行（好程式碼往往會實現的極為精簡），從沒被安排處理過bug。

於是，算KPI你排不上號，經理又從來不用催你完成任務、修復bug——因為你總是按時保質完成任務，而且壓根沒寫出bug來。

這就使得你水平越高、態度越端正，KPI反而老是賺不到、管理層反而更加看不見你；反倒是水平最差、老是完不成任務的，每天一堆經理圍著催，好像他才是最最重要的大忙人一樣。於是既突出了“領導的重要性”，又顯得他勤奮事多重要。

這種“逆淘汰”現象是管理水平低下造成的。

問題是，“管理水平”看不見摸不著……

這就造成了“低水平的管理人員透過強迫程式設計師加班來提升自己的考評”、而“強迫加班”使得程式設計師花更多心思在“磨洋工”上，甚至挖空心思鑽漏洞賺KPI上——我就見過某管理水平低下的公司，它的程式設計師熱衷於把迴圈拆開一句句寫出來湊程式碼行數。程式碼行數多，KPI才高，才有錢賺。

換句話說，996並不代表著“工作強度高”，而是大部分時間被用來花式磨洋工了；其中程式設計師往往會以劣質程式碼的方式賺KPI，而專案經理則以“指揮著程式設計師無事忙”的方式磨洋工。

在這種低劣的管理水平作用下，每個人都付出了大量的精力和大量的時間，工作的極為痛苦；但公司的技術水平管理水平反倒直線下降（都去研究磨洋工賺KPI了），最終得到的產品無論質量還是功能點反倒更少了，造成雙輸。

搞笑的是，一旦習慣了這種雙輸模式，延長工作時間反倒切切實實提高了每天的產出——哪怕花式磨洋工，多磨倆小時怎麼也能多幾分鐘產出吧。

換句話說，當因為管理水平的低劣、導致無法正確評估程式設計師的產出、傷害了真正努力工作者的積極性、又容忍東郭先生在裡面混日子時，他們只好默認了“磨洋工”的現實；然後以一種令各方都痛苦的形式、靠延長勞動時間來減少“磨洋工”造成的效率損失——然後更加劇了“磨洋工”這股歪風的流行，逼的真正認真的工作者也不得不加入磨洋工的行列。

說白了，996就是劣質管理層帶領下、給老闆看的一種表演。

而老闆之所以會喜歡看這種表演，是因為那些腦殘只跟著雞湯文唸叨過兩句“狼性”。

不能說完全無關，但也不是明確線性相關，他們之間的關係制約的因素很多，比較複雜，這也是為什麼許多軟體公司KPI並不能有效準確地衡量工程師工作量的主要原因。影響的因素包括但不侷限於：具體的開發任務涉及到的技術與開發成員技術背景匹配率高低，完善的開發測試流程，測試程式碼覆蓋率，這點對程式碼重構有著重要的影響，如果沒有足夠的測試覆蓋，修改程式碼尤其是涉及原始程式碼改造將會是非常影響效率的，因為修改原始程式碼，如果對內部邏輯理解不透徹或者有錯誤，就會容易引入Bug，只有保證足夠的測試覆蓋率，自動化實現迴歸測試，會給程式碼開發效率的提升帶來很大的幫助。至於如何用資料做衡量基準，目前比較有效的是引入敏捷開發流程，透過task的分解，每位開發者的任務量化到小時，每兩週作為一個Sprint，階段回顧開發效率和最佳化開發流程，可以比較有效的衡量開發者開發任務的承擔量。

大部分是的，進入狀態的時候一小時可能搞定一個複雜的問題。要是沒狀態或者不想幹的時候坐三天也可能沒一點進展。