每个程序员都有自己烦心事，不论这事指的是范围蠕变（scope creep），还是指匈牙利变量命名 （Hungarian notation），我们都明白，这是我们有我们行业里的特定的烦恼。 下面要说的就是让程序员们烦恼的十件事情。
  10. 注释 — 只解释了“how”却没有解释“why”
  入门级的编程课程通常会教育学生们写代码前先写注释、而且要尽量多注释。 这种教育的出发点是“多注释肯定比少注释好、少注释肯定比没注释好”。可不幸的是，很多的程序员把这当成了一种任务，对每一行代码都注释一下。
1. r = n / 2; // 让 r 等于 n 除以 2 
2. 
3. // 当 r - (n/r) 大于 t 时进行循环 
4. while ( abs( r - (n/r) ) > t ) { 
5. r = 0.5 * ( r + (n/r) ); // 设置 r 等于 r + (n/r) 的一半 
6 . }
  经过这样的注释，你否明白了这段代码是干什么的？的确，我也没明白。 问题就在于，虽然有大量的注释，可它们只是描述了代码是干什么了，却没有说明代码为什么要这样写。
  现在，请看一下我们采用另外一种方式对同一段代码进行的注释:
1. // 使用牛顿-Raphson算法求n的平方根近似值 
2. 
3. r = n / 2; 
4. while ( abs( r - (n/r) ) > t ) { 
5. r = 0.5 * ( r + (n/r) ); 
6. }
  这就好多了！也许我们还是不能完全明白这段代码的作用，但至少是有了一点方向了。
  注释是用来帮助读者理解代码的，不是用来解释语法的。 我可以大胆的认为，读者对for循环的工作原理是了解的；所以没必要写这样的注释：“// 对客户列表进行for循环操作”。读者不明白的是你的代码是做什么用的，你为什么要采用这种方式实现它。
  9. 干扰
  很少有程序员能在眨眼之间从一种活动中转换到编程的状态中。通常情况下，我们更类似于需要慢慢启动的火车，而不是能突然加速的 法拉利; 我们需要一定的时间才能进入工作状态，一旦我们进入稳定有效的工作状态，我们的工作效果和产出会很丰硕。 不幸的是，当思路不断的被客户、经理、以及你的同事打断时，你的大脑很难进入编程的状态。
  当我们干一件事情时，有太多的琐事需要我们放在心里，我们需要先放下这个事情，处理那个人事情，回头又干这个事情，还不能有差错。这些干扰会中 断我们的思路，而重新整理清楚思路又要你花费大量的时间，这是让人懊恼的、没有比这更让人泄气、让人有挫折感的过程了。
  8. 范围蠕变（Scope creep）
范围蠕变（Scope creep） (也称作焦点蠕变（focus creep）， 需求蠕变（requirement creep）, 功能蠕变（feature creep），以及其它一些乱七八糟的演变词语)，指在项目管理里项目的需求变更失控。 当一个项目的范围没有明确的定义清楚、没有文档化、不受控时就会出现这种现象。 这通常被认为是一种有负面影响的事情，应该尽力避免。
  范围蠕变通常会把一个简单的需求变成一个复杂惊人的需要大量时间的巨无霸。 那些负责需求调研的家伙们只需要敲几下无辜的键盘就能把事情变成这样：
版本 1: 显示这个地区的地图
版本 2: 显示这个地区的地图，要三维立体的
版本 3: 显示这个地区的地图，要三维立体的，而且能够使用它作为飞行导航图
  一个本来30分钟能完成的任务变成了一项要几百人/天才能完成的超级复杂的系统。更糟糕的是，大多数情况下，需求变更是发生在开发阶段 的，这样一来你需要重写代码，重新回归，有时要把前几天才开发的代码删除。
  7. 管理者 — 完全不懂编程
  管理工作不是一种简单的工作。人是一种让人很讨厌的动物; 我们善变、喜怒无常，我们都自以为天下第一。想让这样的一群人都感到满意和团结，你需要付出像山一样大的努力。 然而，这并不意味着管理者就可以在对下属的工作毫不理解的情况下进行管理。 当管理者对我们的工作没有一点知识概念时，后果只会是需求频繁变动，不现实的工期，普遍的挫折感（管理者和开发人员）。程序员们对此的抱怨相当普遍，这也是产生争执不合的根源。
  6. 写文档
  在说这个条目之前我先承认，我们确实有很多的文档生成工具，但据我的经验，这些工具都是只适合生成API文档，以供其他程序员参考。如果你开发 的软件是平时人们每天都要用的，你必须要写一些外行人(例如你的实施，客服等)都能理解的文档手册。
我们可以很容易的看出，有些事情程序员们极不愿意去做。 你可以简单的回顾一下所有的开源项目。 人们百折不挠的对这些项目的一个索求是什么：文档。
  我敢打保票的说，不管在哪里，至少会有一半的程序员当要求写文档时会说：“不能让其他人去写吗？“。
  5. 程序 — 缺少文档
  我可从来没说过我们程序员是说一套做一套的人。 程序员们经常会在他们的项目里用到第三方的类库和应用。 于是，我们需要文档。 很不幸呀，就像我在第6条里说的那样，程序员们痛恨写文档。这戏剧性的事情发生在我们自己身上。
   当你需要使用一个第三方类库时发现，至少有一半的API无从知道是干什么好用的，没有任何事情比这个更打击人的了。 函数   poorlyNamedFunctionA() 和函数 poorlyButSimilarlyNamedFunctionB() 有什么区别？ 在我使用 PropertyX 属性前是否需要测试一下它是不是 null 值？我估计只有通过自己的测试和报错才能弄清楚!。
  4. 硬件
  任何一个曾经被叫去调试一个数据库服务器上奇怪的宕机现象，或是被叫去解决RAID驱动器不能正确的工作的问题的程序员，当发现是硬件问题时， 都会痛苦不已。 人们有一种普遍的误解，认为程序员就是搞电脑的，他们肯定知道如何修理电脑。 不可否认，有些程序员确实是个全才，但我估计，绝大部分程序员都不知道，或者根本不关心当程序被编译成机器码后如何工作的。我们只关心做出来的东西是否符 合需求文档，这样我们才能集中精力去解决这上层的任务。
  3. 含糊不清