会议，什么都不懂的经理，生产效率指标——这就是你和下一个伟大软件之间的天堑。
昨天必须得发布产品。用户争闹和咆哮某个缺失的功能。老板的老板说，我们最好迅速行动起来否则就炒我们的鱿鱼。感觉一切都有心无力。
没有人满意开发人员这种已经“竭尽全力”改变世界的速度，每个人都希望代码像消防水管里的水一样能够源源不断地流出来，但没有人愿意提供给开发人员更好地完成工作的条件。正如那个想要我们昨天就完成工作的老板，他不愿意雇佣更多的人，不愿意购买速度更快的机器，也不愿意做任何其他可以让程序员专注于编程的事情，又想马儿跑，又不给马儿吃草。
下面就是现实世界中的15个编程障碍。
编程效率障碍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：妄自尊大的开发人员
对于程序员而言，有这样一个同事比Boss更难以忍受：创建了代码的最后一次迭代，却不再工作于这个项目。正如每个房屋装修承包商会贬低上一个木匠的技能，每个程序员也会快速指出可怕的，不可原谅的，完全是死脑筋的上一代的行为。
当然，这可能是事实，但它很少像程序员说得那么糟糕。如果有什么区别的话，问题通常也不是由于技能匮乏而引起的。主要还是风格的不同，并且风格还会随着时间而改变。上一代和我们今天访问的库不同。他们也不曾阅读过有关最佳做法的最新著作。
妄自尊大的编程态度往往会减缓项目。骄傲和利己主义的混合发酵会导致程序员抛弃完全能够胜任的代码，只为了按照他们认为的“正确方式”重建。
编程效率障碍No.5：“以后修复”的思维定式，又名“技术债”
我们总感觉不够时间在项目中按计划构建我们想要构建的东西。于是，我们偷工减料，给代码打补丁，缠满了虚拟胶带。曾有明智的经理将此称为是“技术债”，因为“债”是以后必须要还的。即使他们不理解代码，也知道“债”的含义。
每个项目都有一定的技术债务。有时它会快速见效，但通常直到下一代才会发现这已经成为了一个坑。他们需要构建上一代没有做到的东西。就像滚雪球一样，越滚越大。
编程效率障碍No.6：非程序员经理
总会有那些面带微笑，西装笔挺，却不是主修计算机科学，也不懂编程项目的家伙成为了经理。也许他们娶了老板的女儿；也许他们正好在“正确”的时间出现在了“正确”的地方。但是，老板让他们担任了经理，即使他们一窍不通。更糟的是，他们会用外行人的眼光来看待问题，哪怕不伦不类，文不对题。
有一些程序员表示很欢迎这样的经理，因为愚弄他们很容易。而且他们还承担了来自于更高管理层的炮火。但也有人承认，这些人只会不断地开会，只会妨碍编程。他们几乎给不了任何有用的指导，他们可以提供的只是那么一点质量检测。
编程效率障碍No.7：程序员经理
虽然程序员可能会因为不得不与非程序员经理打交道而抱怨，但他们经常悄悄地表示，编程人员去做管理人员更糟糕——有时甚至更糟糕得多。
他们是前任的天才，可能会决定微观管理项目，然后果决地撕裂大片的代码，因为他们有了一个新的展望。或者，也许他们会闲谈，对于同样的事情，他们是 如何用8080汇编或C或Java编程写了一半的代码。在任何情况下，他们更痴迷于技术细节而不是大局，虽然他们被雇来的目的是盯牢后者。
编程效率障碍No.8：善于社交的程序员，又名“brogrammer”
虽然程序员可以将每个问题和任何中断的责任归咎于巧言令色的销售团队，但编程人员也必须承认，有一些问题在于他们自己。程序员被聘请的目的在于他们的计算机技术，而不是他们的人际交往能力。
程序员通常不善于沟通，不知道如何表达他们的感受和思维。他们可以准确抓住技术参数，就像庖丁解牛一样迎刃有余。无论客户想要改变什么都不要紧：程序员总是时刻思索着技术参数，即使是在公司野餐上也不外如是。
尽管程序员通常可以过滤掉对方的特质，但当程序员之间发生磕磕绊绊时也会让团队失败。当同一个团队中两个人有着不同的政治观点，比方说，动态语言或NoSQL，那么团队就会永无宁日。一切都像是在战场一样，战火纷飞，硝烟弥漫。
编程效率障碍No.9：自私或牛仔程序员
你从他的代码里发现一个空指针？捕捉空指针于是成为了你的工作。你最好多想一遍要不要传递一个零，因为自私的程序员不会检查除以零错误。这也成为了你的工作。
牛仔程序员的工作又酷又快，但这是因为他的代码中遗留了许多漏洞，并且没有经过测试。于是这也成为了你的工作，因为如果你不处理这些琐事的话，代码就会崩溃。
很多团队在最终认识到这一点的时候已经为时已晚。代码块在早期测试中运行良好，但当输入真正的数据之后，各种问题就开始暴露出来。真是一场灾难。
编程效率障碍No.10：可怜的文档
写文档需要时间。但由于老板雇我们来是来写代码的，并且通常通过我们写的代码行数来衡量我们的效率。因此既然你想要结果，那么我们就只做你想要的那部分。当然最终我们还是会写文档的，但质量的好坏就不论了。
有时候，文档虽然很多，但却是几个月或几年前老代码的版本。我们只是还没来得及修改这些旧文档而已，但是，以后我们会同步的——相信我。
编程效率障碍No.11：成为文档的奴隶
虽然我们都经历过没有文档的项目，但是空话太多、编码太少反而导致项目失败也很常见。曾有几个人指着满满一书架的文件夹，向我炫耀说：“我专门请人来写文档。”然而要读完这么多文档需要一年的时间。
程序员通常在处理需求时，会写一些评论和注释，之后充作文档。因此这样的文档，都是一些微小的细节，没有经过认真地总结或没有说到要点上。这在文档中将可能是致命的，当他们没有提供太多的抽象和理解，就只写代码流水账的时候。这样的文档并不具启发性，只是翻译下代码而已。
编程效率障碍No.12：很容易导致分心的环境
有一个客户坚持要我每天去他们的办公室，坚持要我使用他们的电脑。然后，他们没有提供任何的办公空间，所以我只能和六个实习生在会议室写代码，此外，这些实习生还需要我用半天的时间回答他们前一天晚上碰到的问题。另外半天的时间则用来指示今天晚上做什么。于是，我基本上做不来自己的工作。
虽然销售和营销团队可以在背景噪音的环境下茁壮成长，但程序员通常需要图书馆般安静的背景。闲聊，令人心烦意乱的敲击声，或铃声将驱逐程序员的思维走出抽象的工作区，回到现实中。然后，需要几分钟的时间才能重新沉浸于工作区。
有一位开发人员告诉我，他恨他的新办公桌，因为它靠拢空调出风口，噪音令人难以置信的响，使得他真的很难集中注意力。这可能略有夸张，但的确是一个事实。
虽然许多企业会提供程序员类似乒乓球桌的娱乐活动，但他们往往忘记了开发人员需要在安静的氛围中集中精神。甚至，他们还将程序员转移到大房间，认为这可以促进合作，殊不知却会导致一有风吹草动，整个房间的程序员都受到干扰。
编程效率障碍No.13：“文化契合”
你想拥有自己的办公室？或者你更喜欢团队化的办公室，这样你就可以直接喊出你的问题？你喜欢在清晨开始工作，亦或是你更喜欢熬夜？
如果团队成员之间的风格相似。那么这支团队往往才能更好地工作。无法找到共同点的团队很快就会失败。没有沟通，最后只会南辕北辙，不知所谓。
编程效率障碍No.14：死守传统技术
很多捍卫者认为古老的技术依然很伟大，依然能够完成任务。因此对于为什么要重写代码表示疑虑重重。
他们想得没错，但他们忘记了保持这些古老代码的成本。所有一切通常都需要用自定义代码进行翻译。某些代码甚至写在ASCII之前，这意味着需要转换输入和输出。旧系统经常会计数空格字符只是为了在数据库中指出这是什么。这就更加需要转换了。
当然程序员可以通过屏幕抓取，重新格式化，临时构建系统来做大量的工作，但一段时间以后，他们往往需要花费更多的工作来清理混沌的逻辑，以致于腾不出时间来写新的逻辑。
编程效率障碍No.15：对最新的渴望
最新的工具自然有意思，但却在没有经过大量时间再次编码以往的工作之前，是不会被开发工作室采用的。走在时代尖端的人总是会扔掉API的整个部分，并重新编写，从而迫使我们这些下游的程序员不得不跟着一起改写代码。我厌烦过，当我不得尽力用Python 2.7的代码对付Python 3.0的代码时，因为依现在的情况，Python已经是一种相对稳定的代码库。
在许多情况下，新的工具并没有战斗化。例如，Node.js，虽然说相当快，但是只有当你重新学习所有关于死锁的经验教训之后，知道线程优先的时候才能发挥作用。世上没有免费的午餐，工具虽好但都是有代价的。
