读到一篇不错的文章，试着翻译一下。
原文请见：《Top 12 Things That Destroy Developer Productivity》
许多文章都在谈及技术领导的作用。这中经常提到同一主题 —— 如何提高团队的效率。但在尝试提高团队效率之前，你或许应先考虑是什么在消弱效率，这样才能更好地达到目的。不幸的是，即便《Peopleware》已出版近30年，我们依然看到许多团队在些显而易见的地方浪费着巨大的生产力！
没人会认为程序员能在没电脑的情况下完成工作，但很多公司却认为程序员可以在不知情的情况下完成工作。这很不切实际。
所以，让我们深入讨论下降低程序员效率的12个误区。我会将这12个误区的影响力由大到小进行排序。
欢迎大家评论！
如果你还在考虑这么做是否值得，那么请考虑下程序员们的工资。仅仅是提高10%的效率，换成工资会是多少呢！
1）被打断与会议
在我看来，频繁地被打断可称得上是程序员效率的第一杀手。程序员被打断后，再想回到开发时的思维是很慢的，有的甚至要30多分钟。所以，更多的打扰，会导致更低效的工作，进而导致更多的 bug - 如此往复。
在我要开始工作时，受到的打扰越多，我就越难以开始。
如果你在早晨就不断打扰我，那么这天我没有任何产出时，请不要吃惊。
- A developer on Reddit
那关于会议呢？相比打断，唯一的不同是会议是有计划的，这会使其更具杀伤力。当程序员明知自己在工作时会被打断，他们很难全身心投入工作。所以，如果在一或两小时内要开会的话，他们几乎完成不了什么事情，因为大部分的 task 都需要超过两小时才能完成。
正如 Paul Graham 所写：“一个会议能将整个下午分成两块，每块都因太小而做不出啥事儿”。
那要怎么将其避免呢？如会议可以是早晨站会或在午饭前简短进行，同时避免不必要的打断。
2）细究型领导
注：原文为 “Micro-management”，个人认为应该是指事无巨细，悉究本末的领导。
在各类领导当中，细究型领导也许最有碍程序员的效率。毫无疑问，细究型领导往往会有更多的会议和突如其来的打断。不仅于此，他们看上去很难信任别人并会反复作出一些消弱程序员技能的事情，此类事情对程序员的伤害远远超过被打断造成的低效。细究型领导也许是让程序员离职的第一原因。或者，至少也会影响整个团队。
3）交流不清
有好几个角度能说明什么叫“交流不清”。
如提测报告中写到“项目崩溃了，修复它！”这报告基本没给程序员什么信息去有方向的解决问题。顺便一提，此类提测报告可用标准的模板。
或者一个不清楚的功能描述，这种情况下程序员会朝自认为对的方向去开发，而一旦产品经理给出了更详细而又不同的原型时，那么这个功能就不得不被重新开发。
task 优先级不明确也属此类范畴。
有了 task 优先级，程序员便不会再在思考自己是否正在做有价值的 task 上浪费时间了。嗯... 如果他们曾有过正在开发某一 task 而被老大问到为什么着急做个 task 时（然而这些 task 并没有优先级）... 所以，你知道这个坑之所在了吧...
4）海鸥型领导
你听过这个词吗？
这种画面通常是，有的领导就像飞在空中的海鸥，对项目不闻不问，但是...他们偶尔会突然冲下来对项目一顿乱批：“这里是错的，还有这儿，那块看起来也太特么差劲了吧”，等等...我承认我还蛮喜欢这种画面感的，但不幸的是这事发生的频率已超过了我们喜欢它的程度。
这种行为会让程序员感到很大的挫败感，接下来的几个小时他们很难找回工作状态，有的甚至需要几天。
5）抢别人功劳
你是否曾遇到他人将你几周来的工作成果归功于自己？程序员最重要的是工作能力。抢别人的功劳意味着抢走了别人的工作能力。这是为什么我将其排名如此之高，我觉得这会造成很大的消极感，以至于在很长时间内消弱程序员的生产力。
6）办公环境——噪音、人来人往、工作区的设计...
这对非程序员来说会觉得很奇怪，但办公环境真的对程序员的状态有很大影响。一些白噪音，如交流电的声，汽车或卡车的行驶声能让他们更好地集中注意力。这就是为什么他们通常都带耳机！顺便安利下我发现的好声音 RainyMood ！
同样的，如果工作空间被设计成很方便走动，这并不能帮助程序员集中注意力！
或者某人的屏幕很容易被其老大看到...很棒，这会对其产生更大的压力，也让他有了更多被打断的可能性。
7）范围变更
范围变更（也被称为卖点变更、需求变更、特性变更，这有时也被称为「厨房水槽综合症」）在项目管理中这指的是项目范围不受控制的变更。
这种情况常发生在项目的范围没被好好确定并落到文档上，或者项目执行没被好好地把控。
范围变更能将一个简单的需求变为一个巨复杂且巨消耗时间的怪兽！
例如一个简单的需求：
V1 时（在开发前）：功能是“显示一个能够定位的地图”
V2 时（在 V1 快开发完）：功能被改为“能够定位的 3D 地图”
V3 时（在 V2 快开发完）：功能被改为“能够显示用户行动轨迹的 3D 地图”
... OMG ...
8）产品的设计流程
这标题乍一看很奇怪，但实际很好理解。
如果产品团队确定了团队的优先级，而没有根据用户的反馈，从用户的兴趣点设计对应的功能。最终程序员看到他们开发的大部分功能并没被使用，这会很打击他们的积极性。任谁都想有存在感，这也许对程序员更重要些！
9）随意欠下“技术债”
技术债 Technical debt 是为了更快速的发布软件而选择不用最好的解决方案或不写最高质量的代码。通常，欠下一些技术债是不可避免的，这可以在短期内提高软件的开发速度。但从长远来看，它会导致系统复杂性的增加，进而降低了开发的速度。门外汉经常会低估技术债的危害而倾向于继续前进，这最终会成为一个大问题。
当「重构」从不被优先考虑的话，欠下的技术债将不仅影响开发效率还会影响产品质量。
10）工具的多样性
程序员每天会用许多的工具来编程，推送和合并他们的代码。自动化越多越好。如果你还在用“古老”的工具，不用说，这肯定会影响效率。同样地，拥有一个大屏幕而不只是一台笔记本电脑会更高效。考虑到硬件成本和程序员的工资，只需提高他们5％的生产率就能收回这些成本！
11）“How”型注释
在学习如何写代码时，我们总被教导要多写注释。其理念是注释多总比少要好。
不幸的是，许多程序员误以为这意味着他们必须注释每行代码，这就是为什么我们经常看到这样的代码（来自 Jeff Atwood’s 的 “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)
}
你知道这段代码的作用吗？我也不知道。这虽然有很多注释在描述代码在做什么，但没有描述代码为什么这样做。如果出现了 bug ,你 debugger 到了这段代码，至此你将无从下手。
12）如此曼妙 Deadline
最后一个是关于领导会让程序员评估开发时间，然后迫使他们进一步缩减已评估的开发时间，再神奇地将该时间定为 deadline！领导们倾向于认为程序员自己评估的 deadline 往往是最有效的，其有效程度到这个 deadline 应该再告诉他们的领导。
毫无疑问，程序员会觉得这种 deadline 是很不合理的，这也会给他们造成很大的压力而难以集中精神进行开发。
上面列出的问题只是针对程序员的吗？
如果你看完这12条，其实这几条对于大多数基于项目的岗位都很常见。只是这几条对程序员的影响会更大，因为他们更要集中精力去开发 tasks。
如果上面说到的几条也发生在你的公司，你和程序员们去讨论一下这些或许是很有意义的。和他们好好聊聊，发现问题并找到解决办法。让他们畅所欲言，并认真思考他们的反馈和看法。
同时，现在的技术和三十年前确实很不一样了，但经验教训仍然还是共同的。在你思考团队效率的时候绝对不能忽略人的因素。请和团队成员一起思考工作流程、工作环境和工作习惯，相互学习，大家一起思考如何提高团队效率和影响力。