工作中令程序员最生气的10件事情

时间：2022-05-25 21:12:02 | 来源：网络营销

时间：2022-05-25 21:12:02 来源：网络营销

程序员可以说是一个比较特殊的群体，他们因为长期和电脑打交道所养成的性格和脾气也是比较相近的，当然了，既然是人，就会有性格的，也是会有脾气的。

下面，让我就借助亿企邦的平台为大家盘点一下令程序员最生气的10件事情，一方面我们可以看看程序员的共性，另一方面我们也可以看看程序员的缺点，无论怎么样，这对于正和程序员相处或工作的你都是一定的帮助。

1、程序员的代码

无论你当时觉得自己的设计和写的代码如何的漂亮和经典，过上一段时间后，再回头看看，你必然会觉得自己的愚蠢。

当然，当你需要去维护他人的代码的时候，你一定要在一边维护中一边臭骂别人的代码。

是否你还记得当初怎么怎么牛气地和别人讨论自己的设计和自己的代码如何如何完美的？可是，用不了两年，一刚从学校毕业的学生在维护你的代码的过程当中就可以对你的代码指指点点，让你的颜面完全扫地。

当然，也有的人始终觉得自己的设计和代码就是最好的，不过这是用一种比较静止的眼光来看问题，编程这个世界变化总是很快的的，很多事情，只有当我们做过，我们才熟悉他，熟悉了后才知道什么是更好的方法，这是循序渐进的。

所以，当你对事情越来越熟悉的时候，再回头看自己以前做的设计和代码的时候，必然会觉得自己的肤浅和愚蠢，当然看别人的设计和代码时，可能也会开始骂人了（这种情况我也曾在亿企邦的《一名程序员的自白：其实我并不是一位天赋卓越的编程大师》一文中跟大家介绍过的）。

2、思路被打断

正当程序沉浸于编程算法的思考，或是灵感突现正在书写程序的时候，但却遭到别人的打断，那是一件非常痛苦的事情，如果被持续打断，那可能会让人一下子就烦躁起来。

打断别人的人在这种情况下是非常不礼貌的，被打断的人就像函数调用一下，当其返回时，需要重新恢复断点时的现场，当然，人不是电脑，恢复现场通常是一个很痛苦的过程，极端的情况下可能需要从头开始寻找思绪，然后一点一点地回到断点。

因此，我看到一些程序员在需要安静不被打扰的时候，要么会选择去一个没人找得到的地方，要么会在自己的桌子上方高挂一个条幅以示众人——“本人正执行内核程序，无法中断，请勿骚扰，谢谢!”，可能正在沉浸于工作的程序被打断是多么大的开销，自然，被打断所惹毛了的人也不在少数了。

3、程序员自己

惹毛程序员的可能还是程序员自己，程序员是“相轻”的，他们基本上都是持才傲物的，总是觉得自己才是最牛的，在程序员间，他们几乎每天都要吵架，而且一吵就吵得脸红脖子粗，在他们之间，总是被自己惹毛。

（1）、技术上的不同见解

比如：Linux和Win，VC++和VB，Vi和Emacus，Java和C++，PHP和Ruby等等，不管用哪一种编程语言，总要先吵吵，什么都要吵！

（2）、老手对新手的轻视

总是有一些程序员看不起另一些程序员，说话间都带着一种傲慢和训斥，当新手去问问题的时候，老手们总是爱搭不理（其实还是有很多新手很受老程序员的喜欢的，对此大家可通过亿企邦的《老程序员给初学者的一些建议和忠告》相关介绍来详细了解）。

（3）、在技术上不给对方留面子

不知道为什么，程序员总是不给对方留面子，每当听到有人错误理解某个技术的时候，他们总是喜欢当众大声指证，用别人的“错误”来表明自己的“博学”，并证明他人的“无知”。

（4）、喜好鄙视

他们喜好鄙视，其实，这个世界上没有一件事是完美的，有好就有不好，要挑毛病太容易了，程序员们特别喜欢鄙视别人，无论是什么的东西，他们总是喜欢看人短而不看人长，经常挂在他们嘴上的口头禅是“太差”、“不行”等等。

程序员，长期和电脑打交道，编写出的代码电脑总是认真的运行，长期养成了程序员们目空一切的性格，却不知，这个世界上很多东西并不是能像电脑一样，只要我们输入正确的指令它就正确地运行这么简单。

程序员，什么时候才能变成熟起来呀！

4、问题报告

“我的软件不工作了”，“程序出错了”，每当我们听到这样的问题报告的时候，程序员总是感到很痛苦，因为这样的问题报告等于什么也没有说，但还要程序员去处理这种错误。

没有明确的问题描述，没有说明如何重现问题，在感觉上，当然会显得有点被人质问的感觉，甚至，在某些时候还掺杂着看不起，训斥的语气，当然，程序员基本上都是很有个性的，都是软硬不吃的主儿，所以，每当有这样的语气报告问题的时候，他们一般也会把话给顶回去，当然，后面自己然发生一些不愉快的事情。

所以，咱们还是需要一个客服部门来帮助我们的程序员和用户做好沟通。

5、部署环境

虽然，程序员们开发的是软件，但是我们并不知道我们的程序会被部署或安装在什么样的环境下，比如，网络上的不同，RAID上的不同，BIOS上的不同，操作系统的不同(WinXP和Win2003)，有没有杀毒软件，和其它程序是否兼容，系统中有流氓软件或病毒等等。

当然，只要你的软件出现错误，无论是你的程序的问题，还是环境的问题，反正都是你的问题，你都得全部解决。

所以，亿企邦觉得程序员们并不是简单地在编程，很多时候，还要当好一个不错的系统管理员，每当最后确认问题的原因是环境问题的时候，可能程序员都是会心生怨气。

6、没有文档

正如上一条所说的，程序员本来就不喜欢写文档，而因为技术人员的表达能力和写作能力一般都不是太好，所以，文档写的也很烂，对此，大家看看开源社区的文档可能就知道了，但是我们可爱的程序员另一方面最生气的却是因为没有文档。

当然，上面说是的用户的文档，这里我们说的是开发方面的文档，比如设计文档，功能规格，维护文档等等，不过，基本上都是一样的。

反正，一方面，我们的程序员不喜欢写文档，另一方面，我们的程序又会被抱怨没有文档，文档太少，或者文档看不懂。

呵呵，原来在抱怨方面也有递归啊。

据说可以降低程序开发中的文档，据说他们可以把代码写得跟文档和视图似的，不知道是真是假，不过，亿企邦也听过太多太多的程序员抱怨没文档太少，文档太差了，这个方面要怪还是怪程序员自己。

7、用户文档

用户文档本来不应该那么的令人害怕，这些文档记录了一切和我们所开发的软件有关的一些话题，因为我们并不知道我们所面对的用户的电脑操作基础是什么样的，所以，在写下这样的文档的时候，我们必需假设这个用户什么也不懂。

于是，需要用最清楚，最漂亮的语言写下一个最丰富的文档，那怕一个拷贝粘贴的操作，可能我们都要分成五、六步来完成，那怕是一个配置IP地址的操作，我们也要从开始菜单开始一步一步的描述。

对于程序员来说，他们在开发过程中几乎天天都在使用自己开发的软件，到最后，可能都有得有点吐了，但还得从最简单的部份写这些文档，当然容易令他们烦燥，让程序员来完成这样的文档可能效果会非常不好。

所以，对于这样的用户文档，应该由专门的文档人员来完成和维护。

8、经理不懂技术

领导一句话，无论对不对，都是对的，我们必需照做，那怕是多么愚蠢多么错误的决定，我们也得照做。

在亿企邦看来，程序员其实并不怕经理不懂技术，最怕的就是不懂技术的经理装着很懂技术，最可气的是，当你据理力争的挑战领导权威的时候，领导还把你视为异类。

哎，想起这样的领导别说是骂人了，打人的冲动都有了。

其实，经理只不过是一个团队的支持者，他应该帮助团队，为团队排忧解难，而不是对团队发号施令，其实管理真的很简单，如果懂的话，就帮着做，如果不懂的话，就相信下属，放手让下属做，亿企邦觉得最怕的就是又不懂技术，还不信任下属的经理了。

哎，这真是程序员的痛啊！

9、需求变更

这个事情估计不用多说了，只要是是程序员，面对需求变化的时候可能总是很无奈的，一次两次可能还要吧接受，但也顶不住经常变啊！

据说有一套方法论可以让程序员们享受需求的变化，不知道是真是假，不过，今天让你做一个书桌，明天让你把书桌改成餐桌，后天让你把餐桌改成双人床，大后天让你把床改成小木屋，然后把小木屋再改成高楼大厦，哎，是人都会被惹毛了的。

那些人只用30分钟的会议就可以作出任何决定，但后面那几十个程序员需要搭上几百个小时的辛苦工作，如果是我，可能我也需要神兽草泥马帮助解解气了。

不过，这也正说明了，程序员并不懂得怎么和用户沟通，而用户也不懂得和程序员沟通，如果一个项目没有一个中间人(如：PM)在其中协调的话，那么整个项目可能就是“鸡同鸭讲”，用户和程序员都会被对方所惹毛了。

如果要例举几个用户被惹毛的事情，估计程序员的那种一根筋的只从技术实现上思考问题的方法应该也能排进前5名。

10、程序注释

程序注释本来是一些比较好的习惯，当程序员老手带新手的时候，总是会告诉新手，一定要写程序注释，于是，新手们当然会听从老手的吩咐，只不过，他们可能对程序注释有些误解，于是，我们经常在程序中看到一些如下的注释：

1 r = n/2; //r是n的一半
　　2 //循环，仅当r- n/r不大于t
　　3 while ((r-n/r) <=t){
　　4 //… …
　　5 r = 0.5 * (r-n/r); // 设置r变量
　　6 }

每当看到这样的注释——只注释是什么，而不注释为什么，相信你一定会被惹火，这是谁写的程序注释啊？不找来骂一顿看来是不会解气了。

在亿企邦看来，程序注释应该是告诉别人你的意图和想法，而不是告诉别人程序的语法，这是为了程序的易读性和可维护性，这样的为了注释而注释的注释，分明不是在注释，而是在挑衅，惹毛别人当然毋庸置疑。

亿企邦点评：

作为一个优秀的程序员，他的思想不能局限在当前的工作任务里面，要想想看自己写的模块是否可以脱离当前系统存在，通过简单的封装在其他系统中或其他模块中直接使用，这样做可以使代码能重复利用，减少重复的劳动，也能使系统结构越趋合理。模块化思维能力的提高是一个程序员的技术水平提高的一项重要指标。