Bug 一词的原意是“臭虫”或“虫子”。现在，在电脑系统或程序中，如果隐藏着的一些未被发现的缺陷或问题，也称之为“Bug”，这是怎么回事呢？

第一个有记载的 Bug 是美国海军编程员、编译器的发明者格蕾斯·哈珀（GraceHopper）发现的。哈珀后来成为了美国海军的一位将军，还领导了著名计算机语言 Cobol 的开发。

1945年 9 月 9 日，下午三点。哈珀中尉正领着她的小组构造一个称为“马克二型”的计算机。这还不是一个真正的电子计算机，它使用了大量的继电器，一种电子机械装置。第二次世界大战还没有结束。哈珀的小组日以继夜地工作。机房是一间第一次世界大战时建造的老建筑。那是一个炎热的夏天，房间没有空调，所有窗户都敞开散热。

突然，马克二型死机了。技术人员试了很多办法，最后定位到第 70 号继电器出错。哈珀观察这个出错的继电器，发现一只飞蛾躺在中间，已经被继电器打死。她小心地用摄子将蛾子夹出来，用透明胶布帖到“事件记录本”中，并注明“第一个发现虫子的实例”。

从此以后，人们将计算机错误戏称为 Bug，与之相对应，人们将发现 Bug 并加以纠正的过程叫做“Debug”，意即“捉虫子”或“杀虫子”。遗憾的是，在中文里面，至今仍没有与“Bug”准确对应的词汇，于是只能直接引用“Bug”一词。

1.见鬼了….

2.以前重来没出过问题。

3.昨天还好好的。

4.这怎么可能？

5.一定是机器出了问题。

6.你究竟输入什么了导致它崩溃？

7.应该是数据有问题。

8.我好几个星期都没碰这块代码了！

9.你一定弄错了版本。

10.怎么会就这么巧。

11.我不可能把所有的问题都测到。

12.这不可能是因为它引起的。

13.本来好用的，只是没测试过。

14.肯定是有人改了我的代码。

15.查查你机器上有没有病毒。

16.even though it doesn’t work, how does it feel?

17.你的机器上不能使用这个版本。

18.为什么你会觉得应该出那个结果才是正确的？

19.程序出问题时你在干什么了？

20.这问题我改了呀！

原文链接：程序员最常说的20句话

中国有句老话，铁打的营盘流水的兵。说的很有道理，但是对于一个高速增长的企业，部门来说这个就成了问题，人员不稳定就会造成很多问题。

1.再培养

新招来的员工，需要熟悉很多东西，环境，人事，代码风格，框架代码，旧有代码阅读等等。这其中的浪费往往需要很多时间来弥补，可是任务不等人，事情还要做，只能靠人堆。以前可能一个人一个小时可以搞定的事情，变成了3个人一个星期的事。

2.知识断层

新员工到岗后，因为不熟悉原来的业务模型以及框架模型。导致设计，实现走的可能是复杂的路线，而不是最优的路线，并且由于新的设计可能导致模型的不匹配，导致返工或者桥接方式进行适配。这样平端增加出来的工作量可能是原来的2倍或者数倍以上，从而导致人手上的不足。每个行业后者领域都需要浸淫多年之后才能体会到其中的深奥之处，而这些都是无形的知识和经验，新员工到来后，这层知识就已经消失，只能从新来过。知识没有通过新老交接，逐步沉淀下来。

3.无人可用

老员工的频繁流失，当有新的业务或者领域开展之时，手下无人可用，手下皆是一年及以下左右的新手，现有的业务还未完全熟悉，此时委与重任又不放心，可是又无可用之才，缺人之感倍增。只能矬子里面拔将军，而此人的能力又将决定实现的难易以及复杂程度，往往又是造成劳动密集型的局面。

4.恶性循环

劳动密集型的局面，造成员工没有时间进行思考和进修学习，导致大家每天都是在疲劳工作，效率下降。效率变低之后，就会产生工作量过大的局面，从而又导致缺人的局面产生。当人员没有补充上来，大家继续疲劳工作，效率继续下降，工作量也就越显越大。即使新员工入岗，又会面临上面的问题。同时又因为疲劳工作，并且没有提升空间等原因，很多员工可能选择离职，而这些员工往往都是骨干员工。从而使缺人的现象产生了一种恶性循环。

5.招聘质量

因为对于招聘的漠视和一些种种限制导致了招聘进来的人员素质水平不是理想状态，大家往往只追求了量上的满足，而不是质上的满足。人员也没有呈现梯队化，导致培训成本的升高和后期提升速度较慢。这样也造成了工作效率不高的一个方面，从而导致工作在一段时间内产生积压。

铁打的营盘流水的兵，当流水的速度超过一定的限度的时候，就会造成很多不良效果，当然流水的速度如果继续上升的话，铁打的营盘也会落入湍急的漩涡之中。拥有知识密集型的人才，就应该做到让人才的知识密集起来，而不是让人密集起来。稳固流水的速度，提升员工的生产力和知识能力这样才能慢慢解决缺人的困局。

原文链接：铁打的营盘流水的兵---为什么总是缺人

静下心来仔细想想，也是，各种大师，讲师，砖家，布道之人很多都是被一门理论进行灌输，深入学习了这种理论，对于理论的细节之处可以侃侃而来，但是这些都是仅限于知识理论之内，因为没有实地操作过，实际经历过，所以落地之事就比较含糊其词，不能讲的很明确和详细。

就这样，理论在天上飘着，下面的人儿看着漂亮的云朵变换着各种美妙的图形，追逐着绚丽的虚幻，而忙来忙去总也不能落地，或者迷失方向，或是望而兴叹。云朵和大地之间需要建立一座桥梁，这座桥梁就是【最佳实践】，这些最佳实践可能来源于两个方向。第一个方向就是那些大师沉淀下来，真的走进现场，拿着理论指导实践，从而总结出最佳实践。另外的一个方向就是底层人员提升上来，努力的够着那些漂浮的云，升华着自身实践。

只有这些能上天入地的实践才是最有意义，这有这些人走出来的路才是我们最需要的指引，期待着更多的最佳实践，期待着下里巴人的提升，也期待着阳春白雪的落地。

有些时候转眼想想，感觉到很是悲哀，多少的专业人士不是来自现场，多少无知顾问对于现场指手画脚，多少的培训讲师在上面侃侃而谈，说着正确的废话，多少的辛苦劳作者被一群砖家教育着，被那些吹的天花乱坠的理论所迷惑。

为什么？为什么我们做的程序这样普通，为什么我们做不出精彩的产品，令人激动过程为啥我们没有体验到呢？想想我们的牛人们都在干啥！那句伟大的话道出了这句玄机，“你们稍微牛一点的人都去做管理了。”

我们现在的组织结构是这样的

牛人或者类牛人做了几年可能就转到了管理岗位上了，编程工作就移交给了新来的小弟弟，小妹妹们，之前的业务经验，技术经验就直接出现了断层，负责的人呢，就慢慢的把经验向下渗透，但是渗透的时间往往需要1~2年，而这几年的时光里，下面的人或者也挤进了管理岗位，或者流失走了。

我们大多数的时候，或者企业。会把管理职位当做一种奖励机制，经常会鼓励某些潜力份子，“好好干，年底的时候提拔你做研发经理。”，“恩，你会成为部门经理的候选人”等等，这样导致了大量的研发经验好的牛人走上了并不熟悉的管理岗位，而把那些空缺留给了实习生，应届生。做了2年就当上项目经理，当上研发经理的比比皆是，表面上风光无限，实际上就不得而知。

当然有些时候也是无奈的选择，不走管理岗位，那么就不要想着加薪，或者不要想着大幅加薪。一个干活的拿到了1~2W的薪水，有人会惊呼，“这么多。”，一个管理职位的拿到1~2W的薪水，也会有人惊呼，“才这么点，不可能吧。”，是啊，世俗的一些观点或者HR的观点导致了干活人员拿不到对应的薪水，被逼上了管理之路。还有就是，“那家伙这么大岁数了还在编程”等等，依然困惑着那些徘徊的人，或者那些准备走另类路线的人们。

对于公司而言，真正工作的，都是那些苦逼的应届生，实习生，那些new boy，产品的质量，产品设计，产品的整体水平，研发的效率如何不是normal，如果不能是这样的庸俗，对于这样的现状你还能有多少的期待呢？如果不能制定出对应的研发体系薪金标准，不能提高研发人员的薪水水平，那么我们只能接受这样无奈的结果。每个人做着不是自己喜欢的工作，就这样平庸到老！

原文链接：Why Normal--牛人都干啥去了？

第一重：

在哪本电脑杂志上看见软件工程师这个职业介绍，或者走在大街上看见某某软件培训机构鼓吹培训完就能年薪10万的广告，有些羡慕那些编程序的，自己有些蠢蠢欲动。

第二重：

用控制台或者说SDK之类的东西写了一个“HELLO WORLD!”,感觉编程这个东西，太简单没难度。

第三重：

学会了简单的使用某某工具例如VC，知道怎么利用工具创建对话框之类的东西了，认为自己已经有了“扎实”的基础，出去找工作四面碰壁之后感叹人心不古世态炎凉。

第四重：

以极低的要求找到工作，突然发现自己不会的实在是太多太多，不求甚解是无奈之举。这个阶段写代码写完之后主要是试，试的标准：“能运行就是成功，不能运行就是失败。”一个小模块写完之后被黑盒蹂躏几十次稀松平常。

第五重：

突然意识到不能再瞎干了，于是知道了如何规范的写代码，尽力的把代码写的短小精悍，看一堆关于算法的书，并且会把自己的或者别人的优秀代码分门别类存起来，以便经常参考使用。

第六重：

做的时间越长，发现自己不会的越来越多，每每遇到不太理解的必然刨根问底，写完一段代码，一定仔仔细细把程序研究个透，不让他出现一点泄漏一点警告才罢休，以挑战白盒作为乐趣。

第七重：

把各种工具研究个稀巴烂，即使一个全新的语言或者工具，也能在半个月之内熟练使用，这个时候，仍然认为自己距离高手还有很大差距，遇到新手来公司面试，很惊讶这些人居然连怎么操作内存都不会就敢出来混了?

第八重：

把编程工具用烦了，开始喜欢控制台或者说SDK，纯粹的API编程变成了自己的最大乐趣。

第九重：

在电脑杂志上看见软件工程师的职业介绍，或者走在大街上看见某某软件培训机构鼓吹培训完就能年薪10万的广告，想对后来人说些什么却终究发现无话可说，只好一笑而过。

第一重到第四重，需要努力，第五重到第六重，需要悟性，想到第九重，需要智商和福缘。

让程序员做更多种类的事

为什么有人说小公司锻炼人？在小公司，条件并不那么齐备，很多事情都需要程序员自己做，自己去澄清需求、自己做设计、自己搭建环境、自己测试，甚至自己上线、自己维护（这件事情在我们团队被称为“自己吃自己狗食”）。

然而到了某些公司，在一些正规的流程下，“人”反而显得不那么重要了：一个完、整的流程被切分成若干环节，程序员只能负责那小小的一环，更严重的是，他们显示出消极和片面的情绪，他们称自己码农，自嘲并且觉得在总做一些低级和毫无技术含量的事情。

关于“码农”——这似乎是一件很悲哀的事情，在美国，程序员是一个相当值得尊敬的行业，去年硅谷的技术员工年薪平均已经超过10万美元；在中国，教师的行业起码获得了人们口头上的尊敬（虽然实质上也许并没有获得应有的待遇），而程序员，往往只能看到自己给自己呐喊。

这里没有绝对的对错之分，但我一直在博客中强调软件开发实质是一种创造性的劳动，只是在一个流程严格控制的公司内，这样的创造的火花可能被扼杀，换来的好处是人员的流动中，代价最小化：谁都可以走、谁都可以代替谁，所有问题都被认为只是时间问题……那么，程序员，你的自我价值何在呢？

关于测试

我听到很多真实的声音，都在抱怨测试工作乏味、加班辛苦。我认为，国内大部分的测试，其实完全是程序员扭曲的工作形态导致的。

专职的测试人员去做专项测试、整个系统的集成测试等等，我都能理解，但是绝对不应当深入模块内部去测试开发人员的代码，绝对不应该去考虑所谓的代码覆盖率——因为这些，比如白盒测试，本都是程序员自己该完成的事情。程序员自己开发的程序，当然要自己验证功能，很多软件公司在一些项目流程里就是没有专职测试介入测试执行，原因很简单，难道自己拉了稀，让别人给你擦屁股？

另一方面，测试该掌握哪些技能？

我见过许多测试人员，他们抱怨工作总是被轻视，没有说话的分量，但是每天的工作就是了解开发的流程，根据流程完成用例的编写，然后执行那些用例，发现bug并填写bugreport。如果一名测试只需要做这些事情，那么确实太没有技术含量了、太没有入门门槛了，太单调乏味了。

测试需要成长，既为自己考虑，也为团队中的程序员考虑。

做一名优秀的测试，除了要有分析能力、辨识能力等等软实力以外，基础技能如通信协议、脚本、编译原理、操作系统等等，亦视情况掌握，只有这样，才能和程序员从并不清晰的需求开始，一起去分析、设计、实现和质量保证、去和上上下下的环节做沟通、论证。微软的测试（SDET）都把算法和编码视为基础要求，敢问国内一些公司的测试人员，有几个敢这么说？

让程序员远离浮躁

去看看国内几家知名博客和论坛，多少浮躁的博文和帖子四处乱飞？多少人在骂公司狗血，在自嘲薪水，甚至在人身攻击？

浮躁的心态可能是造成这种现象的罪魁祸首，有一位同事说得好，很多具体的技术都可以学，但是执着的心和对技术的热爱是不容易学得的。

整个社会都在日益浮躁，ITEye本来也是一个有技术深度、氛围浓厚的网站，现在看起来有些鱼龙混杂；微博的流行正验证了社会浮躁的趋势，很多人没有时间和耐心去写完整的文章，但是两三句感慨、甚至一词半句的惊叹却容易得多；程序员像寻找速配男女一样，在这个概念翻飞的时代，茫然地寻找自己应该进入的领域，应该了解的技术，于是，很容易看到许多所谓的架构师和咨询师可以把这些东西讲得海阔天空、天花乱坠，这个概念、那个素语，但是——给他一个具体问题吧，要他写写实际代码吧，你会要了他的命。

给程序员一点宽松和鼓励

都在说国内的IT环境不如欧美，大量劳动力的富余让人力成本变得无比廉价，能让青年付出卖肾代价以购买大部分配件都“MadeIn China”的iPhone，中国却只获得了1.8%的利润，这些都让人感叹，为什么中国做不出苹果系列这样的产品？为什么中国始终要给别人套上“廉价劳动力”的帽子？中国的程序员，你们的创造力呢？你们精彩的点子呢？

好吧，我听到有人在说是教育体制的问题。对于程序员的地位的思考有很多，可惜我们不是教育工作者，我们也没有那么大的影响力，不过，在团队中间，我们应当多给予这些脆弱的程序员们一点鼓励，让他们表达出自己的想法，特别是在设计上、实现上的想法，不要嘲笑任何人弱智，不要咒骂评审的代码狗屁，多一点沟通，把眼光放长远一些。

这些能表达出想法的人起码可以证明两点：有思考、有勇气，仅这两点，仅足以让旁观的人鼓掌。

一名优秀的TeamLeader，不应该整天陶醉在跟踪项目进度和获取程序员工作反馈上。我们都明白，所谓一张一弛，在工作压力恰当的时候，是最适宜工作的，程序员的工作本来就需要创造性，没有适度宽松的环境，就没有思维的火花。

让程序员自己去布置工作台，给他们创造机会聊聊天，把各个团队、各个角色放到一起说说话，组织分享一些有趣的话题，做一些有意思的研究（最初程序员都很腼腆，得劳烦您多牵线搭桥了），TeamLeader的工作，绝不仅仅是说“行”或“不行”。

程序员的理想

1983年，乔布斯对百事可乐的CEOJohn Sculley说：“Do you want to sell sugar water for the rest of your life, or do you want to change the world?”（你想卖一辈子糖水，还是改变世界？）。

我们已经不在战火纷飞的年代，有多少程序员还愿意怀抱那些原始的理想，还能说出“做互联网的弄潮儿”、“用技术改变世界”这样的话来？

这个世界执着的人并不多，用这样的理念去吸引程序员的公司，则更少。

关于技术

我始终觉得，做软件的公司是需要依赖于技术的，当然国内可以称得上是“技术公司”的并不多，但是，优秀的技术能让程序员脱颖而出，也作为一种谋生的手段，为其觅得不错的回报。

做技术能不能一直有饭吃？我想答案是肯定的，有许多公司声称技术路线可以一直有发展的可行性，但是技术牛人还是转了管理或者一走了之，有一种粗暴但是易行的鉴别技术公司的办法，就是寻找里面又没有40岁，甚至50岁以上还在做实际设计和编码的人（不是那些脱离了具体实现向客户吹嘘的角色）。

世界上有两种最赚钱的人，一种是真正的生产者，他们用自己独一无二的聪慧、灵感和劳动创造了价值；一种是极其老道的投机者，专门从别人口袋里把钱掏出来放到自己口袋里。他们都受人尊敬、受人瞩目，后一种让自己的生活变得更美好，但是前一种，让整个世界更美好。

如果你不能在技术的道路上坚决地走下去，在大部分公司做市场、做管理、做咨询，顺便鄙视一下别的辛苦工作的程序员，那么也可以混得很好——毕竟，生活的解总是有很多种。

原文链接：谈谈对程序员的培养