如果你问一个互联网公司的老板，他一定觉得自己的员工还有可以挖掘的潜力。因为，没有人满足于现状，都想开发出更好的软件。作为搞软件开发的编程人员，深恶痛绝的就是有人打扰他们编程，影响编程效率。

编程效率障碍No.1：会议

最常见的抱怨是打断开发人员编码思绪的会议。如果老板信任该程序员，就会要求他们时不时地去那间数周甚至数年昏昏暗暗的会议室闲聊有关细节。尽管程序员通常归咎于是管理人员毁了会议，但他们偶尔也会指责其他的程序员老是跑过来询问有关或bug或功能或架构策略的问题。

虽然有些抱怨是愚蠢的——但程序员依然会埋怨，如果老板让他们自己在黑暗中摸索，没有一点沟通——任他们自己在软件的抽象世界里埋头苦干，自己去面对各种困境。快餐厨师和咖啡调配师或许还能够兼顾不同的需求，但如果是切换大脑到正确的模式来操作抽象算法则通常需要时间。从会议模式中切换回编码模式，可能会浪费一个小时左右的工作时间。

编程效率障碍No.2：答复所有的电子邮件

如果说会议很糟糕，那么这一种可能更糟糕：需要查看发来的无穷无尽的邮件。回复邮件需要时间，而且没人会对回复结果表示满意。然后那些最不耐烦的开发人员或许会选择简单的回复——“tl;dr”(即too long，didn’t read。篇幅过长，没有阅读)。

有的团队试图开设每周一天的禁邮日。还有的团队就完全不用邮件。虽然解决了邮件过载的问题，但却是以沟通为代价的。要是突然不在一起工作。这还能算是好办法吗？

编程效率障碍No.3：试图衡量生产力

总会有管理团队受那些所谓“你不能管理你无法衡量的东西”的书籍启发，于是开始衡量提交的或代码库或软件代码行或bug修复。他们认为，计数就是衡量，而且衡量一定是好事。

但是程序员并不是砌砖工，不能数数砌了多少砖就知道其效率。相反，为了写出更好的代码，程序员需要或专注于编写的代码行，或解决bug，或提交到代码仓库，或做一些无法计数的事情。如果bug修复可以加分，那么一些微小bug的报告就会激增，bug修复也会如此。有人因为报告bug得到了奖励，然后另一个人因为修复它也能得到奖励。或者，如果是计数代码行数，那么那些可以用10行代码解决问题的程序员，可能就会转而表示5000行的代码将更灵活或功能更兼容——任何可以添加到5000行中的都加进去。

衡量效率实际上会因为鼓励功能丰富，代码过度设计的长文件，而让代码库变得更糟。

对于此问题还没有真正的解决方法。我们需要跟踪bug。我们需要组织工作流程，协调软件的创建。这种优雅是无法衡量的。

编程效率障碍No.4：“以后修复”的思维定式

我们总感觉不够时间在项目中按计划构建我们想要构建的东西。于是，我们偷工减料，给代码打补丁，缠满了虚拟胶带。曾有明智的经理将此称为是“技术债”，因为“债”是以后必须要还的。即使他们不理解代码，也知道“债”的含义。

每个项目都有一定的技术债务。有时它会快速见效，但通常直到下一代才会发现这已经成为了一个坑。他们需要构建上一代没有做到的东西。就像滚雪球一样，越滚越大。

编程效率障碍No.5：非程序员经理

总会有那些面带微笑，西装笔挺，却不是主修计算机科学，也不懂编程项目的家伙成为了经理。有一些程序员表示很欢迎这样的经理，因为愚弄他们很容易。而且他们还承担了来自于更高管理层的炮火。但也有人承认，这些人只会不断地开会，只会妨碍编程。他们几乎给不了任何有用的指导，他们可以提供的只是那么一点质量检测。

编程效率障碍No.6：善于社交的程序员

虽然程序员可以将每个问题和任何中断的责任归咎于巧言令色的销售团队，但编程人员也必须承认，有一些问题在于他们自己。程序员被聘请的目的在于他们的计算机技术，而不是他们的人际交往能力。

程序员通常不善于沟通，不知道如何表达他们的感受和思维。他们可以准确抓住技术参数，就像庖丁解牛一样迎刃有余。无论客户想要改变什么都不要紧：程序员总是时刻思索着技术参数，即使是在公司野餐上也不外如是。

尽管程序员通常可以过滤掉对方的特质，但当程序员之间发生磕磕绊绊时也会让团队失败。当同一个团队中两个人有着不同的政治观点，比方说，动态语言或NoSQL，那么团队就会永无宁日。一切都像是在战场一样，战火纷飞，硝烟弥漫。

编程效率障碍No.7：可怜的文档

写文档需要时间。但由于老板雇我们来是来写代码的，并且通常通过我们写的代码行数来衡量我们的效率。因此既然你想要结果，那么我们就只做你想要的那部分。当然最终我们还是会写文档的，但质量的好坏就不论了。

有时候，文档虽然很多，但却是几个月或几年前老代码的版本。我们只是还没来得及修改这些旧文档而已，但是，以后我们会同步的——相信我。

编程效率障碍No.8：成为文档的奴隶

虽然我们都经历过没有文档的项目，但是空话太多、编码太少反而导致项目失败也很常见。曾有几个人指着满满一书架的文件夹，向我炫耀说：“我专门请人来写文档。”然而要读完这么多文档需要一年的时间。

程序员通常在处理需求时，会写一些评论和注释，之后充作文档。因此这样的文档，都是一些微小的细节，没有经过认真地总结或没有说到要点上。这在文档中将可能是致命的，当他们没有提供太多的抽象和理解，就只写代码流水账的时候。这样的文档并不具启发性，只是翻译下代码而已。

编程效率障碍No.9：很容易导致分心的环境

虽然销售和营销团队可以在背景噪音的环境下茁壮成长，但程序员通常需要图书馆般安静的背景。闲聊，令人心烦意乱的敲击声，或铃声将驱逐程序员的思维走出抽象的工作区，回到现实中。然后，需要几分钟的时间才能重新沉浸于工作区。

有一位开发人员告诉我，他恨他的新办公桌，因为它靠拢空调出风口，噪音令人难以置信的响，使得他真的很难集中注意力。这可能略有夸张，但的确是一个事实。

虽然许多企业会提供程序员类似乒乓球桌的娱乐活动，但他们往往忘记了开发人员需要在安静的氛围中集中精神。甚至，他们还将程序员转移到大房间，认为这可以促进合作，殊不知却会导致一有风吹草动，整个房间的程序员都受到干扰。

因此很多程序员会选择在夜深人静的时候工作，这并不是说真有这么多工作要加班到晚上。而是，只有在晚上，他们才能全心全意写代码。