程序员十大尴尬事，你有过吗？
1.不断不断不断升级的技术vs不断落后的自己！
回顾一下自己以前写的代码，是否也会愁眉苦脸？当时怎么会这么愚蠢！怎么能编写成这样的东西！ 烧掉!丢到火里！
哈，好消息。你并不孤单。
现实是，软件技术界是一个不断变化的世界。 今天被看成是最好的方式，明天也许就会过时。 我们不可能写出完美的代码，因为判断我们的程序好坏的标准日新月异。 这令人很不爽，你的作品，今天看来是那么的完美，但也许不久之后就会变成被人嘲笑的对象了。 真是让人沮丧，因为不论我们如何努力的学习最新最棒的开发工具，设计，框架，以及开发方法，我们总是比最新的技术发展趋势慢了一拍。 对于我来说，这是做一个程序员最苦恼的事情了。我们不断的升级技术，是为了让软件更好，但却禁不住感到，我就像一个做沙毯（sand-painting）的和尚。
2.和其他程序员的沟通堪比谈判！
程序员经常和其他程序员合不来。诧异吗，但这是真的。 这方面的事情我可以轻松的列出十大条，讲细点甚至可以单独写篇博客，所以这里我只列出几个常见的、让其他同事感到懊恼的程序员的特征：
脾气暴躁以至态度极不友好。
不能明白什么时候该去讨论系统的架构，什么时候是应该去动手去做。
无法进行有效的沟通，使用易于误解的专业术语。
自己的事情处理不好。
对要做的程序和项目缺乏兴趣。
那么，这最后的，但不是最糟糕的，序号为1的让程序员们烦恼的…
老板把自己当成超人，什么都应该会！
任何一个曾经被叫去调试一个数据库服务器上奇怪的宕机现象，或是被叫去解决RAID驱动器不能正确的工作的问题的程序员，当发现是硬件问题时， 都会痛苦不已。 人们有一种普遍的误解，认为程序员就是搞电脑的，他们肯定知道如何修理电脑。 不可否认，有些程序员确实是个全才，但我估计，绝大部分程序员都不知道，或者根本不关心当程序被编译成机器码后如何工作的。我们只关心做出来的东西是否符 合需求文档，这样我们才能集中精力去解决这上层的任务。
4.程序——缺少文档
我可从来没说过我们程序员是说一套做一套的人。 程序员们经常会在他们的项目里用到第三方的类库和应用。 于是，我们需要文档。 很不幸呀，就像我在第6条里说的那样，程序员们痛恨写文档。这戏剧性的事情发生在我们自己身上。
当你需要使用一个第三方类库时发现，至少有一半的API无从知道是干什么好用的，没有任何事情比这个更打击人的了。 函数poorlyNamedFunctionA()和函数poorlyButSimilarlyNamedFunctionB()有什么区别？ 在我使用PropertyX属性前是否需要测试一下它是不是null值？我估计只有通过自己的测试和报错才能弄清楚!可恶。
5..注释—只解释了“how”却没有解释“why”
入门级的编程课程通常会教育学生们写代码前先写注释、而且要尽量多注释。 这种教育的出发点是“多注释肯定比少注释好、少注释肯定比没注释好”。 可不幸的是，很多的程序员把这当成了一种任务，对每一行代码都注释一下。 这就是为什么会经常看到像Jeff Atwood在他的博客文章Coding Without Comments提到的代码：
r = n / 2; // 让 r 等于 n 除以 2
// 当 r - (n/r) 大于 t 时进行循环
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // 设置 r 等于 r + (n/r) 的一半
}
经过这样的注释，你否明白了这段代码是干什么的？的确，我也没明白。问题就在于，虽然有大量的注释，可它们只是描述了代码是干什么了，却没有说明代码为什么要这样写。
现在，请看一下我们采用另外一种方式对同一段代码进行的注释:
// 使用牛顿-Raphson算法求n的平方根近似值
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
这就好多了！也许我们还是不能完全明白这段代码的作用，但至少是有了一点方向了。
注释是用来帮助读者理解代码的，不是用来解释语法的。 我可以大胆的认为，读者对for循环的工作原理是了解的；所以没必要写这样的注释：“// 对客户列表进行for循环操作”。 读者不明白的是你的代码是做什么用的，你为什么要采用这种方式实现它。
6. 上司不懂编程，外行指导内行！
管理工作不是一种简单的工作。人是一种让人很讨厌的动物; 我们善变、喜怒无常，我们都自以为天下第一。 想让这样的一群人都感到满意和团结，你需要付出像山一样大的努力。 然而，这并不意味着管理者就可以在对下属的工作毫不理解的情况下进行管理。 当管理者对我们的工作没有一点知识概念时，后果只会是需求频繁变动，不现实的工期，普遍的挫折感（管理者和开发人员）。 程序员们对此的抱怨相当普遍，这也是产生争执不合的根源(就像一个欢闹的卡通片)。
7.加班加班加班....
8.没有加班费....(可以和第七条相辅相成）！
9.领导交代的问题含糊不清，又不方便多问！！
10.....（此处省略一万字！）你懂得的
回顾一下自己以前写的代码，是否也会愁眉苦脸？当时怎么会这么愚蠢！怎么能编写成这样的东西！ 烧掉!丢到火里！
哈，好消息。你并不孤单。
现实是，软件技术界是一个不断变化的世界。 今天被看成是最好的方式，明天也许就会过时。 我们不可能写出完美的代码，因为判断我们的程序好坏的标准日新月异。 这令人很不爽，你的作品，今天看来是那么的完美，但也许不久之后就会变成被人嘲笑的对象了。 真是让人沮丧，因为不论我们如何努力的学习最新最棒的开发工具，设计，框架，以及开发方法，我们总是比最新的技术发展趋势慢了一拍。 对于我来说，这是做一个程序员最苦恼的事情了。我们不断的升级技术，是为了让软件更好，但却禁不住感到，我就像一个做沙毯（sand-painting）的和尚。
2.和其他程序员的沟通堪比谈判！
程序员经常和其他程序员合不来。诧异吗，但这是真的。 这方面的事情我可以轻松的列出十大条，讲细点甚至可以单独写篇博客，所以这里我只列出几个常见的、让其他同事感到懊恼的程序员的特征：
脾气暴躁以至态度极不友好。
不能明白什么时候该去讨论系统的架构，什么时候是应该去动手去做。
无法进行有效的沟通，使用易于误解的专业术语。
自己的事情处理不好。
对要做的程序和项目缺乏兴趣。
那么，这最后的，但不是最糟糕的，序号为1的让程序员们烦恼的…
老板把自己当成超人，什么都应该会！
任何一个曾经被叫去调试一个数据库服务器上奇怪的宕机现象，或是被叫去解决RAID驱动器不能正确的工作的问题的程序员，当发现是硬件问题时， 都会痛苦不已。 人们有一种普遍的误解，认为程序员就是搞电脑的，他们肯定知道如何修理电脑。 不可否认，有些程序员确实是个全才，但我估计，绝大部分程序员都不知道，或者根本不关心当程序被编译成机器码后如何工作的。我们只关心做出来的东西是否符 合需求文档，这样我们才能集中精力去解决这上层的任务。
4.程序——缺少文档
我可从来没说过我们程序员是说一套做一套的人。 程序员们经常会在他们的项目里用到第三方的类库和应用。 于是，我们需要文档。 很不幸呀，就像我在第6条里说的那样，程序员们痛恨写文档。这戏剧性的事情发生在我们自己身上。
当你需要使用一个第三方类库时发现，至少有一半的API无从知道是干什么好用的，没有任何事情比这个更打击人的了。 函数poorlyNamedFunctionA()和函数poorlyButSimilarlyNamedFunctionB()有什么区别？ 在我使用PropertyX属性前是否需要测试一下它是不是null值？我估计只有通过自己的测试和报错才能弄清楚!可恶。
5..注释—只解释了“how”却没有解释“why”
入门级的编程课程通常会教育学生们写代码前先写注释、而且要尽量多注释。 这种教育的出发点是“多注释肯定比少注释好、少注释肯定比没注释好”。 可不幸的是，很多的程序员把这当成了一种任务，对每一行代码都注释一下。 这就是为什么会经常看到像Jeff Atwood在他的博客文章Coding Without Comments提到的代码：
r = n / 2; // 让 r 等于 n 除以 2
// 当 r - (n/r) 大于 t 时进行循环
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // 设置 r 等于 r + (n/r) 的一半
}
经过这样的注释，你否明白了这段代码是干什么的？的确，我也没明白。问题就在于，虽然有大量的注释，可它们只是描述了代码是干什么了，却没有说明代码为什么要这样写。
现在，请看一下我们采用另外一种方式对同一段代码进行的注释:
// 使用牛顿-Raphson算法求n的平方根近似值
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
这就好多了！也许我们还是不能完全明白这段代码的作用，但至少是有了一点方向了。
注释是用来帮助读者理解代码的，不是用来解释语法的。 我可以大胆的认为，读者对for循环的工作原理是了解的；所以没必要写这样的注释：“// 对客户列表进行for循环操作”。 读者不明白的是你的代码是做什么用的，你为什么要采用这种方式实现它。
6. 上司不懂编程，外行指导内行！
管理工作不是一种简单的工作。人是一种让人很讨厌的动物; 我们善变、喜怒无常，我们都自以为天下第一。 想让这样的一群人都感到满意和团结，你需要付出像山一样大的努力。 然而，这并不意味着管理者就可以在对下属的工作毫不理解的情况下进行管理。 当管理者对我们的工作没有一点知识概念时，后果只会是需求频繁变动，不现实的工期，普遍的挫折感（管理者和开发人员）。 程序员们对此的抱怨相当普遍，这也是产生争执不合的根源(就像一个欢闹的卡通片)。
7.加班加班加班....
8.没有加班费....(可以和第七条相辅相成）！
9.领导交代的问题含糊不清，又不方便多问！！
10.....（此处省略一万字！）你懂得的