在此，無關技術，只是從效能上探討下，如何提升工作效率，結合了大量研究，分析，實踐證明。
同一時間最好只做一個任務
溫伯格提出一個經驗法則，用以計算由於切換項目而引起的浪費。
即使你只做一個項目，這種情況也可能會發生，你會被郵件、聊天所打擾。
這裏的奧祕是：在你管理程序員的時候，你會發現切換任務會花費很長時間，那是因爲編程這類任務需要你在大腦記住很多東西。你同時記住的東西越多，編程效率就越高，一個程序員在全力編程的時候，腦袋裏面同時記着數不勝數的東西（程序裏的一切），包括變量名稱、數據結構、重要的編程接口、他們自己寫的常用工具函數的名字，甚至是他們存放源代碼的子目錄的名稱。如果你送那個程序員休假三週，他會把這些東西忘得一乾二淨，人類的大腦似乎把這些東西移除了短期的隨機存儲器（RAM），然後把他們備份到了磁盤上；但再想通過磁盤恢復那些記憶，也許要花上一輩子的時間。
可是我們在工作的過程中很難做到只做一個項目，在開發的過程中被別人的問題打擾，以前的代碼出了bug，別人過來找你，等等，在辦公室想安心寫代碼，不存在的。下面我介紹下我的處理方式：
- 工作中我一般都會帶着耳機，但未必會放歌曲，以此來避免外界打擾
- 當有測試、前端來找我問問題的時候，我一般都是能馬上回答的我回回答一下，如果不能，我會回覆說等幾分鐘，我寫完這段東西去找你
- 對於釘釘發送的消息，除非有人釘我，在桌面彈出，否則我都會過一段時間纔會看一次，把釘釘消息的聲音提示關掉很重要
性能的重要性
根據谷歌的真實測試，請求時間消耗每增加100ms，損失的性能都是巨大的，所有在壓測環境使用鏈路請求時間監控工具，並極力優化性能，是非常重要的。
如果自己寫的代碼想要優化性能，就需要知道，數組、鏈表、棧、隊列、散列表、二叉樹、堆、跳躍表、圖、樹的操作原理和算法：遞歸、排序、二分查找、搜索、哈希、貪心算法、分治算法、回朔算法、動態規劃、字符串匹配算法，以及“算法複雜度大O”的基本原理。
關於算法複雜度的文章，博主找到一篇說明的比較清晰的：算法時間複雜度、空間複雜度
領導團隊適得其法
Dennis Forbes曾經發表過一篇文章，名爲“有效地融入軟件開發團隊”。我覺得他很出色地概括了關於有效領導方面的策略。他用一封假想的電子郵件開頭，描述了被人當做強制執行着的弊端：
我最近被拉取幫助一個軟件開發團隊完成一款產品的開發，具體的要求是協助一些web程序的編碼，我盡了自己最大的努力去融入這個團隊，熱心地幫助他們以贏得一些信譽和尊敬。
我時長轉發“Joel on Software”上的各種小文章給大家，還建議公司裏擺上一堆像《代碼大全》類的書籍。任何事情，只要我覺得可以做的更好，我都會盡力給大家指出來，我經常瀏覽源代碼庫，以找出可以讓其他成員工作的更好的方法。
當其他開發者來向我尋求幫助的時候，我不僅幫他們解決實際的問題，還舉一反三——指出他們在開發上的問題，教他們怎樣改進打字形式，告訴他們該使用哪種命名規範，提倡一種更好的代碼編輯工具。
然而這些努力似乎都沒起到作用，我還是會常常受到他們的抵制，而且我覺得整個團隊不是很喜歡我。我的很多建議都沒有被採納，並且我覺得有些人給我的迴應是毫不掩飾的諷刺。
我到底哪裏錯了？
相信我們都曾和這樣的人一起工作過。也許我們自己就是這樣的人。即使你有最好的意圖，並且已經熟讀我給大家推薦的優秀書籍，你最終還是會落得跟槍炮士官哈特曼一樣的下場：被你自己的團隊“槍殺”了。
在文章最後 Dennis對如何避免被自己的團隊“槍殺”，做了一個很有想法的總結：
保持謙虛：總是先假定你是錯的。雖然開發者的確是會犯錯誤的，並且作爲一個新人，你理所當然應該幫助其他人發現和修正錯誤，但是在你驕傲地宣佈你的發現之前，你應該努力確保你的觀察結果是正確的。如果你總是喊着“狼來了”，你的信譽將受到巨大的打擊。
提出建設性的批評時要小心：開發者更容易接受非正式的建議和具有巧妙引導性的問題，而不是把同樣的內容以電子郵件的形式發送給整個開發組。擴大受衆面可能會引起開發者的防禦和逆反。團隊總是會去猜測你的動機。如果你貶低他們的工作是爲了提升你自己，你會因此被投訴而流芳的。
要想贏得信譽和尊敬，最好的方法就是努力工作並且取得實實在在的成績：廉價而膚淺的替代品——例如羣發關於最佳實踐的郵件，或者轉發別人鼓吹某種關於“銀彈”的評論——它們不會產生同樣的效果，到頭來你可能也只是枉費心機。
百說不如一干：實施一種新的代碼控制機制，或者實現一種新技術——這些事情說起來都很容易。所有人都知道，你只是在聲明這些主意是你想出來的，而實現他們所需付出的艱苦努力卻最終會落在別人的頭上——他們會因此而討厭你。如果你想建議些什麼，你應該爲此付出實際的行動、做好充分的準備。例如，解決技術接入的難點。這並不能保證團隊你的倡議會一呼百應，而且你還可能徒勞無功，但團隊會意識到：你付出了努力，你再積極的推動它，而不是在試圖撿便宜。
真的關心那些你所領導的人：有的架構師領導爲了讓程序員快速開發，當看到員工在學習一些開發過程中有疑問的知識的時候，他會阻止你，當你加班在公司學習的時候，他們換個說法讓你回家，因爲有些人雖身爲領導，但他看到你提高便心生妒意，而且這種領導還會美其名曰“爲你好”，其實人都不是傻子，如果你真的爲別人好，別人感受得到。我想說遇到這種領導就離職把，沒有提升空間，沒有創新空間，更沒有發展空間。
最有效的一種技術領導就是以身作則
程序員的高效工作場所
符合人體工程學的設施
如果有時候會在家裏辦公的話，花比較高的金額購買一把在家用的舒適椅子是很重要的。
加強代碼測試
測試先行的優點
- 單元測試可以證明你的代碼是能真正解決問題的
- 你可以獲得一個底層模塊的迴歸測試工具
- 你可以在不破壞現有功能的基礎上持續改進設計
- 一邊寫單元測試，一邊寫實現代碼，這種工作方式更有樂趣
- 它們可以被用來真實地展示開發進度
- 單元測試可以被用作示例代碼
- 它逼着你在寫代碼之前做好計劃
- 它可以降低bug修復的成本
- 單元測試甚至比代碼審查的效果還要好
- 它實際上爲程序員消除了工作上的障礙
- 單元測試可以催生更好的設計
- 它比不寫單元測試而直接寫代碼的效率更高
程序員，你幸福嗎？
《哈佛幸福課》的作者概括了幸福的真諦
- 經歷勝過物質：我的理解是，一個人更應該在意自己做過什麼，而不是得到了什麼
- 助人爲樂：幫助別人的時候也是在幫助自己，任何可以幫助別人的事情都可以加深你和別人的關係，但是有條準則，這個人，這件事值不值得你出手，以爲無底限地去幫助別人反而讓自己跟傻子沒有區別
- 讓幸福細水長流：人是最能適應變化的，因此，最有效的花錢方式是經常買來一些小變化，而不是花大錢一下買來一個大驚喜，然後坐等新鮮勁很快過去。就拿幸福來說吧，頻率比強度更重要。大家需要改變一下觀念，記住很多次小的，愉快地購買能比一次鉅額的購買帶更能有效的給你幸福感
- 少買保險：關於爲什麼有這條，我也不太明白
- 爲將來買單：即刻的喜悅可能會讓你衝動買下承受不起的東西。它無情地扼殺了你期待的感覺，而期待恰恰是幸福的源泉。
- 三思而後行
- 小心比較購物的陷阱：比如，花2元錢買到一塊巧克力（不錯的買賣），跟這塊巧克力好不好吃其實沒什麼關係。
- 隨大流：不要高估你的能力，別以爲你能預測你會有多喜歡某樣東西。從科學的角度講，我們在這方面及其不擅長！但如果某些東西可靠地給其他很多人帶來了幸福，那它很可能也會給你帶來幸福。在你做出購買決定之前，請認真考量一下別人的看法和用戶評論。
賺錢不容易。幸福更不容易，請記住上面8點。
最後，是我想說的，也是所有程序員都要思考的，你選擇做程序員是爲了什麼？喜歡麼，熱愛麼？還是爲了這個行業還不錯的報酬？
我從事這個行業已經有些年頭，但是我稱不上喜歡或者熱愛，期初只是讓自己有資本在世界上活下去，其實如果我大學不是被調劑到了相關專業，我是一定不會去做計算機相關工作的，對我來說，這只是我的一份工作，我要靠此養家餬口，僅此而已，但是這就像是一個江湖，進入之後就再也無法退出，因爲沒人會想讓自己多年付出的努力，做出的積累付諸東流，我的路只有砥礪前行。
但是我再過一年就30了，隨着年齡的增長，身體會越來越差，腦子反應會越來越慢，這是一個需要體力去加班的行業，沒有人能逃脫的了歲月的摧殘，終究我們會被時代所淘汰，未來還是屬於那些年輕人的，我們將何去何從，是選擇通過驚人的自律來延長職業生涯，還是等到年紀不行的時候，放棄在第一線的工作而另謀出路，是每一個程序員都必經的選擇。
同時這個行業有無止盡的工作與加班，你會喪失與妻子相聚，陪伴孩子，養育父母的時間，這些時間都是一去不復返，失去這些去換一份還不錯的工作究竟值不值得，你從事程序員的目的是什麼，你想通過你的職業得到什麼，你所得到的與你所失去的是否值得，也是每一個程序員需要去權衡的問題。你做此行業的目的是什麼？