今天的文章是來自 medium 的一篇文章，點贊數有將近 1 萬 9，所以翻譯出來給大家分享一下，有些概念怕大家不瞭解，所以我放了一些 維基百科的解釋。如果有翻譯得不是很好的地方，請看原文：https://hackernoon.com/top-12-things-that-destroy-developer-productivity-2ddf0abc190
正文：
很多文章都涉及技術主管和項目經理的角色。我們經常遇到的一個共同主題是如何提高團隊的工作效率。但是在你集中精力來提高生產力之前，你可能首先要考慮是什麼在摧毀它，以便建立一個可靠的基礎。不幸的是，即使 Peopleware 近 30 年前發佈，我們也看到許多團隊在一些（消極的）顯着方式中遭受巨大的生產力損失！
沒有人希望程序員在沒有計算機的情況下完成工作，但是有很多公司希望程序員能夠在不知情的情況下完成工作。這同樣不切實際。
因此，讓我們深入探討我們的 12 個阻止您的開發人員“進入區域”並提高工作效率的事項列表。我將嘗試從大多數到最不具影響力的列表中優先考慮此列表。隨意評論！
如果您想知道這一切是否值得投資，只需考慮開發商的工資。生產力提高10％甚至更多！
1. 中斷和會議
在我看來，中斷是開發人員的首要生產力殺手。開發人員在中斷之前不能輕易回到他們正確的位置。他們需要進入發展的思維模式，然後慢慢追溯到他們離開的地方。這可能需要超過30分鐘。中斷越多，挫折越多，工作質量越差，錯誤就越多 - 而且還在繼續。
“The more times you trip me up while I’m trying to get started — the longer between each time I’m going to try. If you fill my morning with interruptions — don’t be surprised when the day is unproductive.。” --A developer on Reddit
大概意思就是說，每次被打斷都要重新開始，如果你的一天裏經常被打斷，那麼當你一天沒有任何成果的時候，不要感到驚訝。
會議怎麼樣？會議和中斷之間的唯一區別是會議是計劃中斷，這會使情況變得更糟。如果開發人員在處理任務時知道他們會中斷，則他們無法完成任務。因此，如果他們在一兩個小時內召開會議，他們將無法取得任何進展，因爲大多數工程任務需要更多時間。
As Paul Graham wrote, “A single meeting can blow a whole afternoon by breaking it into two pieces, each too small to do anything hard in.”
意思就是：正如保羅·格雷厄姆（Paul Graham）所寫的那樣，“單次會議可以將整個下午分成兩部分，每部分都太小而無法做任何事情。”
如何避免這種情況？這部分記錄良好; 你沒有任何藉口。例如，在一天的開始或午餐前舉行簡短的狀態會議，以避免不必要的中斷。
2. 微觀管理
在不同類型的管理者中，微觀管理者在開發人員的生產力方面可能是最糟糕的。當然，微觀管理者往往會有更多的會議和意外中斷。但不僅如此。他們表現出缺乏信任，通過這樣做，你會覺得他們不斷破壞你的技能和你完成任務的能力。開發人員在中斷之間的任何動機都會在那時消失。影響超出了生產力。微觀管理者可能是開發人員離職的第一個原因，或者至少是改變團隊的原因。
如果不知道什麼是微觀管理(micro-management)的，看下面的解釋：
在商業管理中，微觀管理（英語：Micromanagement），亦作微觀管理學、微管理學、微管理或顯微管理學，一種管理風格，與宏觀管理的理念相反。在這種手法裏，管理者透過對被管理者（員工）的密切觀察及操控，使被管理者達成管理者所指定的工作。相對於一般管理者只對較小型的工作給予一般的指示，微觀管理者會監視及評覈每一個步驟。這個名詞一般在使用上帶有負面的意思。-- 來自維基百科
3. 模糊
有許多方法可以說明模糊性。錯誤的報告，如“出問題了，快修復！”沒有足夠的信息供開發人員使用。順便說一下，擁有錯誤報告模板可以幫助解決這個問題。
或者對某個功能的規範不明確，在這種情況下，一旦管理員更好地詳細說明了預期的行爲，開發人員就會開始實施對他們感覺合適的事情。
不明確的優先次序也屬於此類別。開發人員想知道他們是否正在處理正確的任務的時間可以很容易地避免。如果有的話，他們會得到經理的評論，詢問他們爲什麼要處理這個特定的任務（雖然優先事項沒有定義）……好吧，你得到它 - 很多挫折……
4. 海鷗管理
你聽說過嗎？當管理者完全沒有參與工作時，就會發生這種情況，但是……他們偶爾會突然畏縮不前。“這是錯的，這個，這看起來很糟糕，”等等，然後又飛走了。我不得不承認我喜歡這個形象，但不幸的是，這種情況比我們想要的更頻繁。這種行爲讓開發人員感到非常沮喪; 他們將在接下來的幾個小時內無法返回該區域，有時甚至連幾天都沒有。
5. 信用貪婪
您是否有過經理或其他開發人員，他們在過去幾周內完成了您所做的工作？開發人員首先重視能力。爲別人贏得信譽是爲了自己並將其從他或她手中移除。這在我的名單上相當高，因爲我覺得它產生了如此多的緊張，它只會在很長一段時間內摧毀整個開發人員的生產力。
6. 環境 - 噪音，運動，工作區設計……
這對於非程序員來說可能看起來很奇怪，但開發人員工作的環境對他們的活動有重要影響。例如，有一些白噪聲 - 響亮的交流電，聽力汽車和卡車翻滾 - 幫助他們更好地集中注意力。這就是我們這麼多人戴耳機的原因！我其實剛剛發現了RainyMood - 非常棒?！
同樣，如果工作區設計爲儘可能多的運動，那將無法幫助他們集中注意力！或者讓臺式計算機屏幕以這樣的方式定位，使得管理者高度可見……這會產生一些額外的壓力，甚至更多的機會被打斷。
7. 範圍變動
項目管理中的範圍變動（也稱爲焦點變動，需求變動，特徵變動）是指項目範圍內的不受控制的變化。當項目範圍未正確定義，記錄或控制時，可能會發生這種情況。
範圍蔓延將相對簡單的請求轉變爲可怕的複雜且耗時的怪物！大部分時間它都發生在開發過程中！例如，對於一個簡單的功能：
版本1（在實現之前）：功能是“顯示位置的地圖” 版本2（當版本1幾乎完成時）：功能更改爲“顯示位置的3D地圖” 版本3 （當版本2幾乎完成時）：功能再次更改爲“顯示用戶可以飛過的位置的3D地圖”
8. 產品定義過程
所以這個看起來可能很奇怪，但實際上很容易理解。如果產品團隊定義其團隊的優先級而沒有驗證（通過客戶反饋或任何其他方式）相應功能的興趣，並且開發人員發現大多數功能最終都沒有被使用，他們會覺得他們所做的事情是無用的會失去動力。我們都希望感受到有影響力，這對開發人員來說可能更爲重要！
9. 缺乏對技術債務的考慮
技術債務是故意決定實施非最佳解決方案或編寫不是最好的代碼來更快地發佈軟件。承擔一些技術債務是不可避免的，並且可以在短期內提高軟件開發的速度。但是，從長遠來看，它會導致系統複雜性，從而降低開發人員的速度。非程序員經常低估生產力的損失，並且總是傾向於前進，這成爲一個問題。 但如果重構永遠不是優先事項的一部分，它不僅會影響生產力，還會影響產品質量。
10. 工具多樣性和硬件
開發人員每天使用許多工具來編程，推送和合並他們的代碼。自動化越多越好。不言而喻，如果您使用“古老”工具，這將影響您的生產力。同樣，擁有一個大屏幕而不只是一臺筆記本電腦會產生影響。考慮到硬件成本和開發人員的工資，只需 5％ 的生產率，就可以獲得任何投資！只需提供開發人員團隊喜歡的工具和硬件（單獨用於硬件，但作爲工具組）。
11. “如何”文檔
在學習如何編碼時，我們被告知要儘早和經常寫註釋。這個想法是，多寫一點註釋總比寫得少好。不幸的是，許多程序員錯誤地將其解釋爲他們必須對每一行代碼寫註釋，這就是我們經常看到這樣的代碼的原因（來自Jeff Atwood的帖子“Coding Without Comments”）：
r = n / 2; // Set r to n divided by 2
// Loop while r — (n/r) is greater than t while ( abs( r — (n/r) ) > t ) { r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}原文裏就是這樣，沒看懂啥意思
你知道這段代碼的作用嗎？我也不。問題是雖然有很多評論描述了代碼正在做什麼，但沒有一個描述它爲什麼這樣做。如果程序中存在錯誤並且您偶然發現了這段代碼，那麼您將不知道從哪裏開始。
12. 不可能緊迫的截止日期
最後一個與管理者傾向於詢問開發人員的估計，然後推動他們儘可能降低這些估計，然後神奇地認爲它們是最後期限有關！管理人員甚至會認爲，由於開發人員自己“決定”了估算，他們承諾在截止日期前完成，因此截止日期應該被視爲足夠有效，以便與高層管理人員共享。
毫不奇怪，開發人員認爲這些截止日期是不合理的，任意緊張; 這會造成緊張和無法集中注意力。
所有這些東西對開發人員來說都是獨特的
如果你看看所有 12 件事，它們實際上對於大多數其他基於項目的工作來說都很常見。只是每個人的影響對於開發人員來說更爲重要，因爲他們需要深入關注他們的任務進展。
如果您認識到公司內部提到的一些問題，那麼與開發人員討論這些問題可能會很有趣。與他們交談; 找出這些是否是一個問題以及如何解決。無論他們說什麼，最重要的是相信他們的反饋和見解。雖然今天的技術與 30 年前截然不同，但教訓仍然是相同的。在考慮團隊生產力時，您不能忽視人爲因素。與您的團隊一起考慮您的流程，環境和工作習慣，讓他們指導您如何獲得最高的生產力和影響力。
本來今天想法關於 React hook 的文章的，但是怕大晚上的沒人學習，所以放到明天早上發，明早請早。