10. 糟糕的文档说明

　　我承认编写文档说明很耗时间，但同志们，这也是有工资可领的啊。很多企业都会以代码行数为依据核算程序员薪酬，而编写文档说明正是赚钱的好机会。别担心，领导会把这些记入绩效并按量发工资的。

　　有时候文档说明量实在太大，但这是为了能让人们在几个月甚至几年之后都能顺利用上当前版本的代码。哦，我提到这些说明数据会被保存在Footable里吗?这已经是前数两代的开发方式了，而且我也没时间重新捋顺这些代码并对陈旧说明加以修正。不过这只是迟早的事情，躲不掉的。

　　11. 盲目提交说明文档

　　虽然缺少文档说明的项目让人血压上升，但那些空话太多而代码太少的项目同样无法获得成功。在调查中，确实有受访者拿出一大堆说明资料并表示“他们就靠这些文档获取报酬。”光是读这些说明就得花上一年。

　　程序员常常被要求就项目本身撰写评论，就像是根据《太空堡垒卡拉狄加》或者《神秘博士》编写观后感。这类资料往往缺乏总结或者根本没能抓住要点，而只是没完没了地罗列微不足道的细节信息。如果文档不能以抽象形式概括项目作用或者帮助阅读者理解，那么单纯陈述代码作用只会让人心生反感。我只能说这么干的家伙根本没开窍：写说明不是让你把代码翻译成英文。

　　12. 噪杂的环境令人分心

　　一位客户坚持让我走进他们的办公室并在里面通过一周时间体验工作状态。事实上，这家公司的技术人员根本没有自己的办公空间，因此我不得不跟屋里的六位实习生打交道，听他们用半天时间讲述头一天晚上发生了哪些新鲜事、再用半天时间展望今天晚上要去哪疯玩。好吧，其实听听这些事情也挺有意思，但结果是我几乎什么正事都没干成。

　　程序员通常需要像图书馆一样的安静环境。喋喋不休的谈话、令人心烦的敲击声或者电话铃都可能把程序员从抽象的思维活动中揪出来，并狠狠地摔在现实冰冷的地面上。我们往往需要再花几分钟让自己重新进入状态，这对生产力绝对是种毁灭性打击。

　　我的许多企业希望能用乒乓球桌这样的娱乐设施装点程序员的工作环境——但他们忘了这种噼噼啪啪的声音跟开发者所需要的安静与集中严重冲突。

　　13. “文化契合”

　　如果每一位成员都拥有类似的工作风格，那么整个团队就能运作得更好。而无法快速求同存异的团队则会很快陷入失败局面。如果成员之间无法有效沟通，那么各自向目标迈进的状况将把整个部门五马分尸。

　　人们往往能够轻松勾勒出自己心目中的良好工作环境，但这其实还是得与团队本身结合起来才能发挥效果。在处理底层维护以及基础设施建设时，即使受到其他人的干扰也没什么大碍——毕竟这不算什么需要高度集中的工作。当我们等待某项建设工作完成的时候，即使有人在喊大叫也不至于引发太严重的进度中断。毕竟我们同处一个团队之下，互相喊一喊既能提高效率又能缓和气氛。

　　不过如果大家正在创建一套复杂的算法，而其中的组件又处于不断变化当中，那么任何谈话、走动乃至键盘敲击都可能让我们偏离思路轨道。在这种情况下，拥有自己的办公室是最好的办法。

　　14. 执着于传统技术

　　如果大家在Dice.com网站上查找与Cobol相关的岗位，会发现列表中竟然拥有680个结果——相较于网站上的七万多个招聘岗位总量，其比例接近1%。拥护者们坚持认为这是一项卓越的技术，完全能够胜任目前的工作需要。为什么要重新改写已经成熟的解决方案?

　　这样的说法虽然不是毫无道理，但他们忽略了一大事实——沿用陈旧代码是会带来额外成本的。其中所有内容都需要经过翻译，而翻译过程往往需要借助定制代码。其中一部分代码甚至写于ASCII诞生之前，这意味着连输入与输出内容都可能需要转换。陈旧系统在检查数据库内容时通常会把空格计算进来，要排除这些干扰需要更多转换过程。

　　程序员们在屏幕截取、重新格式化以及临时性系统对接方面表现出色，但在一段时间之后，他们往往会把主要精力放在更新胶合逻辑而非编写新逻辑方面。

　　15. 过分追求最新最好的技术

　　我们都跟某位仁兄打过交道，在他眼中Java就是“我爷爷才爱用的编程语言”。而Node.js——这才是201x年的风格。

　　最新的工具用起来当然很有乐趣，但如果不认真对之前一段时间的工作进行备份、我们根本不敢把它们直接引入工作环境。走在技术前沿的人们总爱全盘否定API整体并加以重写，这就迫使下游开发者不得不随之重写自己的代码。

　　在很多情况下，新型工具并没有经过时间的检验。Node.js确实能带来令人惊讶的速度表现，但前提是我们得重新了解死锁机制，这将迫使人们首先创建新的线程。通常来说，前沿方案相当于以偷工减料的方式为使用者带来看似很美的结果——也许不会出问题、但也有可能让之前的心血付之一炬。