转 新程序员职场生存问题实例分析

这其实是《0bug -- C/C++商用工程之道》一书的读者朋友发给我的信件，这位读者显然在公司里面已经是一个技术骨干了，拥有较强的实战经验，也开始带新人了，然后，在新人的工作上，他遇到了一点问题，就来向我咨询。

我本来考虑，直接回复他算了，不过想了一下，还是公开回复比较好，因为我感觉到，他的问题比较有代表性。其实带出了一个很敏感的话题，就是“新人入职以后，该怎么做？”

好，我们先看看原文，再来分析。还是那句话，一家之言，欢迎拍砖哈。

原文：

在chinapub上看了样章，虽然没有代码大全经典（笑，绝对不是砸场子来的），但是我会买一本推荐给新入职的同学阅读，毕竟CC的厚度就够吓人了。
除开前来表示敬仰外，也问点非技术性的问题。
俺是一业内菜鸟，入行一年有余。目前供职的公司开辟了新领域，而老业务也要维持嘛，于是就招了不少人，于是我就成为这一批入职最早的一位，主要工作是维护老产品。
经过大半年的摧残，俺终于明白了其实写程序是在和人打交道的道理，也能够提出一些意见影响技术主管的决定，虽然经常被他说俺的设计太过书生气 =。=，比如俺一直宣扬应该尽可能的使用编译器来约束代码的使用者（或代码本身的特性），只要是你不期望的（不喜欢的）调用方式（或某种特性）就让他编译不过是最好的，防止代码污染。
近期不时去关注下新老同学手上的代码，考虑怎么去做重构，怎么去整理出开发库。
不看不要紧，一看就郁闷了。俺是个懒人，一看见有人可能下一个错误的决定，并且出了错还可能拉上我去耗时间就觉得焦虑。一焦虑就会变得很残暴 T_T
举个典型的代表，入职大半年的小A，现在手上拿着主要模块之一（该模块从来都没正式交付给我维护，但该模块产生过的严重bug，俺都参与过调试）。
在新平台下做测试，发现因为平台差异，在某handle被关闭后的一些看似无关的调用会失败。于是乎，小A就在这些调用前又打开这个handle，写了100行左右的代码，并引入了一个不算严重的bug。
发现bug后，建议他再看看（再测试下），经过1天，bug依旧。于是就指出了bug，然后建议我们是否不应该直接就这样暴力的把bug解决了，而是先去考虑下，这个时侯某Handle被关闭是设计如此？还是一个隐含的bug？以及触发这个bug的原理是否彻底搞清楚了。
过了两天，再一看，还是这么修改的，再一交流，小A表示bug已经解决了，没问题，但bug发生的机理依然不能表达清楚（我也不知道小A是否真的搞懂了）。而事实上这个问题是一个隐含的bug，那些调用就应该在handle关闭前执行。
这个时候如果是老肖会怎么做？
我的做法是直接找到技术主管提出自己的看法，然后请来资深的前代维护者，花了5分钟确认了我的看法，删除掉那100行代码，调整了关闭handle的时机。
事后想起来，我的处理方式是否太粗暴了。是否应该先尝试用更直接的方式与小A沟通，而不仅仅是建议。但是我又感觉对于小A如果建议了，都依然没有改观的话，更直接的方式也不一定有效。与其让自己焦虑，还不如快刀斩乱麻，要是我也忙其他的东西忘记过问了，岂不是又多一颗定时炸弹。
自省后觉得状态不太对啊，想听听老肖的看法。

我的回答：

这位朋友你好，你的信件我仔细看了，也想了差不多一周左右，确实有点难以回答，我只能尽量。如果答得不好，还请见谅。

咱们还是先挑点简单的先说吧，有个铺垫，容我也喘口气，呵呵。

“比如俺一直宣扬应该尽可能的使用编译器来约束代码的使用者（或代码本身的特性），只要是你不期望的（不喜欢的）调用方式（或某种特性）就让他编译不过是最好的，防止代码污染。”

这句话我明确说，我认为你对，应该发扬。我们知道，其实真正做0bug的程序，有点难，主要原因我认为，我们程序员是人，是人就有可能犯错误，有思维惯性啊，思维误区啊，或者根本就是考虑问题不全面，设计时漏想了了一块，这都可能导致bug。

其实有开发经验的朋友应该都知道，bug其实不难，只要发现了bug，程序员总有办法修订，难的是bug的查找和定位，我们无数次因bug导致的加班，其实更多地是在找bug，而不是改bug。

我在《0bug -- C/C++商用工程之道》一书中，提出无错化程序设计方法，其实主要就是针对这个问题在解决。首先我的基调就是，不相信人，包括我自己，因为我也是人，呵呵。因此，我在书中强调编程规范，强调程序易读性，强调严禁变量转义和一语多义，不但从思想上预防bug，更多的我是在讲方法和习惯。即很多实用，用一个规范，用一个习惯解决整整一个方面的bug。

比如说判断语句，常量写左边，if(i==0)，如果写成if(i=0)表达式恒定为假，就错了，但是，如果我们养成常量写左边的习惯，永远一写就是if(0==i)，当此时我们少写一个=号时，编译器立即报错，因为常量在语法上不可被赋值。类似的例子还有很多，我的内存池注册机制，就是利用程序自己来统计指针变量的使用情况，一旦发现未释放指针，立即报警，预防内存泄漏。

大家注意没有，所有这些规范，方法和习惯，我都是想尽办法，争取向C的语法规约，或者说编译器的报错边界在靠拢，力图使错误在编译的第一时间，在程序第一次被运行，就被报出来，并顺便帮助程序员定位到错误处，请问，这种bug还可怕吗？

还有，我在书中强调匈牙利命名法，就是喜欢它有个严格的约定，当把一个成员变量改为全局变量时，根据命名要求，变量必须要改名，由m_xxx改成g_xxx，这一改，编译器会找出一堆调用错误，那么，是不是在帮助我们，仔细检查每一个调用点，让我们来判断，这次改变变量的作用域，是不是合理，以及是不是有隐患。

因此，我这里明确提示一下年轻的朋友们，请尽量利用好编译器，它找bug比你准确得多。好的程序，不是一写出来就没有bug，而是写出来第一次编译一大堆bug，然后我们改，当什么时候改到编译器不报错，我们的程序就彻底没有bug，那么，我认为，这就是最理想的0bug程序，同时，这个程序员，可以称之为0bug程序员。

好，现在我们来讨论第二个问题。

第二个问题，我归纳一下，你看了那位小A的代码里面有明显的bug，于是有点焦急，沟通效果不好，小A虽然改了，但是没有改到根子上，bug依旧。这件事情，我直说啊，你做得不到位。

为什么说你不说小A呢，原因很简单，你比他资深。我们以前带团队，有个原则，同样的错误，如果是团队犯了，年轻的，刚入职的，不但不骂，还要安慰几句，资深的就骂，特别是级别高的，越是狠人、牛人骂得越凶，因为这里面有个原则，“资格=责任”。

比如说火车站候车室，一个人心脏病突发，大家都没辙，只有一个人是医生，但是他没有出手，这个人最后死了。想想看，大家是骂所有人，还是骂那个医生？肯定是医生啦，因为他有这个治病的能力和资格，但是他不治，就是不负责任，其他人由于不懂，就没有责任。

因此，这件事情上，虽然我不是很清楚你们公司的行政职务定位，但只要你比他早来一天，你就有责任。

当然，也不是说这件事情上你有多大的错误，但是，我个人建议，你的沟通方法需要改进一点，一般说来，我们做事有个原则，“重大问题，立即开会”。

要知道，在公司里面，不管是哪个级别的员工，其实都有权利开会的，开会并不是很复杂的事情，不是说只有主管才能开会。哪怕一个才入职1天的小弟，发现问题，我教他们的方法就是，先找我，讨论，一旦发现问题很严重，通常就是立即开会。我负责去请比我职务更高的主管，一起参与。

开会不是目的，目的是提醒所有人，我们有个问题，重要问题，如果不解决，会影响后续很多工作，因此，这是重要事件，请大家知晓。另外，我们要讨论一下，该怎么做，同时，还要对新员工做出表彰，因为他的这个发现，帮助我们预防了bug，节约了成本。

因此，我觉得你的第二个问题，其实就是一个会议的问题，你可以主动请求你的主管或经理，召开一次专题讨论会，就这个问题的根源，解法，做个分析和结论，拿出正确的解决方案，再委托这个小A去实施即可。

正如你举的例子，这个问题根源是小A没有理解程序设计的原意，打开了一个已经关闭的Handle，导致新的bug，那么，开会时，自然大家可以分析清楚，这个Handle原来为什么会被设计为关闭，来龙去脉如何，如果要再利用，该怎么做，其实在会上只要摊开来一说，应该不难的，那么，知道了来龙去脉，知道了原理，我想，小A的实施，应该不会再有bug了。

之所以采用开会形式，其实是有很多好处的。人都是要脸的，当一个人自己做事时，很容易忽视自己的bug，对自己有点放任自流，即使出现一点问题，也不会仔细思考，但是，当问题一旦暴露在大家面前时，人往往就会打起精神，负起责任来，认真对待，其实这也是帮助小A养成良好的职业操守。

当然，开会有开会的方法，我们曾经规定，两个人以上在一起讨论工作，就叫开会，我们不建议开长会，大会，不允许开无结果的会，每一次开会都要有结论，每一次结论都要有记录，并且，纳入工作日记管理，主管下面要查实施效果的。你能明白吗？

嗯，我们再来谈谈第三个问题。

第三个就是你直接向我咨询，你找主管的做法好不好？

我的回答是，也好也不好，好的是，你找主管，开始争取团队的支持，找来前代开发者，并解决了问题。从工作效果上，好。

但是，也有很不好的一面，你发现没，在这中间，没小A什么事，那你想想，他会怎么想？是不是很没有面子？他会不会因此感到自卑，或者受到伤害，并因此而消沉，离职？

我们经常说新人离职率高，老板就骂，现在的年轻人怎么啦？养不家的猪，主管也跟着骂。其实有时候，反过来想，我们这些主管，自己有没有责任？是不是我们很多时候没做好，导致了不可挽回的结果？新人好不好，我的建议是，老板可以骂，但是，主管最好别骂，因为往往会骂到自己头上的。

我的建议，最好的做法，你和小A先开小会，讨论一下这个设计有没有潜在的bug，当你们能达成共识，再一起找主管，让前代作者和小A交代，这个东东的原理是什么，你和主管旁听，在中间你适当参与讨论，引导小A自己总结问题根源，以及解决方案，让他自己说出来，大家评判他的解决方案是不是对，当最后他自己都能说对的时候，你认为这个问题的解决，还难吗？

这样的好处显而易见，你们没有责怪小A，更多的是针对他知识和经验的不足，在帮他提高，提高到他自己拥有解决问题的实力，并且自己拿出解决方案，最终解决掉这个问题，你说，他是不是很有面子？

一个新人，到了新公司，主管悉心教导，不批评，只培训，自己不断提升，并且，能解决很多公司的关键问题，自己觉得自己逐渐成长为公司的重要人物和骨干员工，请问，这个新人会没事跑路吗？

这里提示一点管理方法，“上情不能下达，开会，下情不能上达，私下讨论”。这也是我自己总结的一点管理经验，你这个问题，既有上情不能下达问题，又有下情不能上达问题，建议可以参考我的这个原则，一般说来，你做到这一步，方方面面的顾虑就都考虑差不多了，最后，小A受表扬，你的评价也不会错。

当然，在这期间，必要的沟通技巧必不可少，沟通技巧，可不是说话客气就算完，是很多素质的综合，包括换位思考，包括耐心倾听，包括引导思维，等等，建议以后可以学习一点沟通方面的知识，会对你的工作很有帮助的。

嗯，从这个问题，我再引申第四个问题，就是站在小A的角度，该怎么看待这件事。

这其实是换位思考了，我们说完了你这位资深员工，或者说主管朋友，那么，我们来说说，作为新员工的小A，应该怎么做，才能更加符合公司的需求。

我在《0 bug ---- C/C++商用工程之道》里面，其实这个问题多次涉及并讲解，这里我再多说一次。

在书中，我讲过一个故事，就是以前一个团队成员，独立完成一个项目，但是显然没有做好，他做的算法没有和我们商量，或者是没有重视我们开会时给他提示的重要算法关键点，自己一个人闷着头做，一个简单的数据库树形目录体系解析模块，他做了接近4个月。最后，我们全体同事的模块都完成了，单独等他等了两个月。

我没有办法，最后在项目Died Line之前两天，正式接手他的工作，我发现他把问题做得太复杂了，写了整整15000行代码，中间绕来绕去，造成了无数的bug，最后无法交工，并不是程序没有写完，而是bug太多，无法稳定运行。

我没有办法，重构了他的代码，中间我引入了一个我发明的“工具类”方法，1200行代码，两天做出来，一次过，0bug。他当时都惊呆了。最后，由于他表现不好，被公司请去喝茶，到另外的公司上班去了。

这个故事我记录在《0 bug ---- C/C++商用工程之道》工具类这一小节中，有兴趣的读者，可以看看。

那我们来看看他的问题是什么？

这么多年的程序实战经验，我发现新程序员入职场，往往会犯两种错误：

1、不喜欢求助，新人并没有把团队视为自己的资源，更多的是想表现自己，因此遇到问题，喜欢自己钻牛角尖，尤其是还有一点面子观念，怕自己问很傻的问题被人笑话，结果呢，导致自己死K不出来，大家想帮忙帮不上，干着急，最后事情还没办好。

这里我建议各位同学，当你们第一次入职场的时候，摆正位置，你们就是新人，新人不懂，是正常的，有问题，自己想出了解法，可以主动找老员工或者主管谈谈，你不是去问他，你把你的解决方案说给他听，让他们参谋，是不是合理，这一般都没有人会拒绝，而且，可以获得很有效的帮助，这比你自己全部去想，效果好的多。

我们不建议新员工事事不动脑子，全部靠别人帮忙，但是，我们强调，新人最好在动脑子的前提下，请主管和资深工程师帮助自己点评一下，帮助自己查漏补缺，这是非常好的习惯，会帮大家少犯很多错误的。

2、喜欢玩技巧耍酷。这也是新员工喜欢犯的错误，很多新人入职，由于在公司没有地位，急于想表现自己，这体现在开发中，特别喜欢玩一些比较精深的算法，以显示自己很牛，并试图通过这些表现，让大家重视，或者尊重自己。这也要不得。

我经常喜欢说一些新员工，“耍酷耍到自残”，呵呵。敲代码，明明有方便的VS2008，不用，非要用vi，好像不用这个，就不能算Linux程序员。就看他打字的时候，两个手像蝴蝶一样在键盘上飞，花枝招展，煞是好看。结果最后一看，他产量最少，笔误最多。

我写了n个Linux服务器了，到现在不用vi，我就是在VS2008里面编辑，然后，VC编译，运行，通过，ftp到Linux，make，运行，通过，就好了，VC的编辑环境很好用，我们敲代码，每个变量名，函数名，只输入一次，这里拷贝一下，那里用点自动弹出，哪来的笔误嘛。

这还好，仅仅是习惯问题，最多影响一点产量。有一些朋友更要不得，一个简单的被动池算法，又是动态内存分配，又是链表，又是树，忙活了半天，最后出来，一堆的bug，好不容易改好bug，QA一测试，程序不可用，重构。原因很简单，没有考虑到内存碎片的影响，无法满足7*24小时运营要求。

像我们老工程师呢，看看数据边界，嗯，最多1024个单元，不多嘛，一个静态数组搞定，然后在数组中做点重用逻辑，根据概率分析，效率不比动态分配的差，程序简单得多，而且没有bug，静态数组，更不可能有什么内存碎片。完了收工。

大家觉得哪个好？

这些，都是我过去碰到的实例，我也share到《0 bug ---- C/C++商用工程之道》一书中，很多时候，不要为了写程序而写程序，要聪明点。

我经常开会时劝小弟，“请你们用脑子写程序，别用手写程序”，大家能明白什么意思吗？

好了，总结一下吧。

目前很多朋友，不好找工作，主要原因是因为学校里面的知识，不是很合用，企业的需求与我们的实力之间有落差。但这个问题其实在我看来，不难解决，目前有很多好的培训班，也有很多优秀的培训机构，我们只要潜心学习一段时间，掌握基本的企业开发技能不难的。

但是，我发现大家讨论时，很少讨论一个问题，那就是：“进去了以后怎么办？”

今天我将就这位朋友的问题，谈谈主管如何管理新人，也谈谈新人如何融入企业开发团队，希望能帮到大家。

其实这些东东并不复杂，说穿了，因为不值几个钱，但是，请大家关注，就这么一点点思路，理念和方法的差异，有的人就能在新公司迅速定位，并不断出成绩，最后成长为公司的业务骨干，获得重用和高新，但有的人，就是没有办法获得稳定的工作，最后变成跳蚤，到处乱跳，始终无法成就自己的事业。大家愿意做哪一种？

其实我写《0 bug ---- C/C++商用工程之道》一书，很多时候我自己都在想，我讲的重点是什么，最开始定位的时候，我是程序员，我当然应该写技术，但是写到一半想法就有点变了，待书出来，面世，我发现其实我真正写的，是怎么做人和做事的原则。

我一直建议大家，代码不值钱，别被代码迷住了，要跳出代码看思想，就是因为我觉得，一个新人走入职场，技术上的问题真的不是什么大问题，最大的问题，是怎么找到正确的工作方法，少犯错误，争取转正和进步。我觉得这才是最重要的。

我可能由于水平有限，写出来的书，这方面说了一点，但是没有重点突出，表现上也不够醒目，只有我这里多发点帖子，请大家关注这个要点了。

欢迎大家以后就这个问题和我多讨论，我希望能帮助尽可能多的朋友，获得满意的工作，并且能够做好，成就自己的一番事业。