领导打算辞退我组里的一名员工了，程序员写代码时多沟通真的很重要

[itechnology]

这个员工身上有几个问题让领导不得不辞退他：

1 、技术属于中上，前沿的技术（比如 k8s 什么的）都比较清楚，但业务代码写的比较差，写的代码出现过好几次 oom ，无一例外都是有些地方没有判断，导致查了一张表的所有数据。

2 、遇到问题非常不喜欢问其他人，老是喜欢自己瞎琢磨，有时候自己琢磨一整天真的不如其他同事的一句话。

3 、还是第二点的问题，产品下发需求给他做，他有不明白的地方也不找产品确认，就自顾自的认为应该是这样做，结果并不是，搞得还要返工。

4 、老是喜欢自己造轮子，非常浪费时间。比如说用了 mybatis-plus 会默认在持久层实现查询列表的方法，查询列表没有特殊情况都直接用这个方法就可以了，他就不，非得自己在 mapper 文件中新写一个。还有，调用其他微服务查列表时，明明已经有这个接口了，他也不问，非得自己重新在那个微服务里重新写一个。

上面这些情况我都跟他说了好几次了，他依然不改。。。

他现在还不知道这件事，我都不知道该怎么开口。

[2bad4u]

之前遇到一个网易跳过来的，上班第一天把公司研发共用的服务器给 rm -rf /* 了，当天就让他走人了，哇哈哈哈

[a4854857]

@wurenzhidi 你说的是他的彻底反面吧...

[weijancc]

不过 mybatis-plus 自带的查询不美观, 在 mapper 上写比 mybaits-plus 的好看多了, 前提是有用插件

[liuxu]

他的技术应该只算中等，先把上去掉

1. oom 属于测试问题，我觉得你们公司测试部门的实力有待考证，责任他和测试 55 分。建议他自己学习一下自动化测试，开发、运维加测试，三位一体才算能力中上
2. 不问是好事，如果能力真的在中上，能遇到的问题放在任何人身上，基本也是需要琢磨一整天
3. 这个要问下产品的原型图和说明给清楚没，还是只言片语，几句话说了就扔那不管了，如果都给清楚了，是他的问题
4. 你只举了 1 例，可能是他的问题，如果他造了很多轮子，每个得分析看看是不是有其他考量，是原组件性能问题还是设计有问题，还是只是他喜欢造轮子

最后欢迎他来写 golang 或者 rust ，需要他这种造轮子的人来写基础组件贡献代码

[Dogtler]

同为打工人看别人的过失想自身吧：
1. 这个是业务熟练度的问题，如果入职不久这种问题还是挺正常的
4. 重写轮子的话，如果对业务和性能不造成影响，其实也没啥，可能自己写的对需求灵活性上改的更没包袱。
2. 问别人一次两次倒没啥，问多了也烦，如果有信心自己琢磨能解决问题，即最终导向是良性且不耽误进度的，那么这点上倒也没啥。

[echoless]

@plutome 人家面试涨薪水 从此 crud boy 是路人

[nicebird]

技术挺烂的水平

[BillyGao]

代码经常能 OOM ，k8s 这种比较熟不会是背的吧

[echoless]

@itechnology 没有代码 review 么

[sparklee]

同

[hahaayaoyaoyao]

@yagamil 像是在说我。这个我也干过 “逆向某个竞品的数据协议包，直接对着二进制逆向” 不过不是竞品的，是合作方也忘了的内容。

[Dogtler]

而且这些问题试用期三个多月大概率应该会暴露出来的，如果领导决意裁人应该自己跟他说。一点看法

[openmm]

脑子一根筋，去哪都吃不开了，你提到的这些问题是应届生或者经验年限低的会比较多点，这种有经验的确实不应该存在

[cp19890714]

很多人不自知，所以要提前进行心理建设。每半年进行一次绩效评定，对每位成员进行优点鼓励和不足建议。你该做的都做了，该帮的都帮了，能不能行那就看他自己了。当公司要辞退他的时候，他的心里应该提前感觉到了。

[echoless]

@Dogtler 其实管理层和员工沟通交流一下也能解决这个问题 oom 这种 很多人不小心就会碰到

[shijingshijing]

@itechnology

我这里说的技术中上是指技术知道的比较多，面试时也能比较清楚的回答出来，但写业务时就不行
--------------------------------------

就怕这种问啥都懂，让自己写也能凑合写个能跑，然而一旦正式上线就各种问题的。这种不仅自己有问题，还得拖着其他人给他擦屁股，不让他走谁走？

[shijingshijing]

@yagamil 之前公司有个大神级别的，做算法兼各种杂活。 反正干啥都牛 x 的，而且高难度的问题只有他才能搞出来。（比如逆向某个竞品的数据协议包，直接对着二进制逆向。。。） 反正就是不得不服的那种。

也是不喜欢讨论或者问别人。 但公司 boss 不敢动他，还老怕他跑了。

-------------------------------------------------

这种才是真 nb ，属于安全气囊类型的，可能就用那么一两次，但关键时候能顶上而且逆转结果的。

[xuyang2]

@itechnology
“每次迭代一个版本之后要进行一次代码 review” 也太好笑了

[lesismal]

相比于多数人，有一颗折腾轮子的心，会有更大的几率技术向上突破，能不能突破要看实际情况了，比如遇到牛逼的团队规范的流程、他自己想造事故都比较难有机会，但像一般的中小团队流程没那么严格规范、个人行事权限充足，他就可能惹祸、职场不顺利。

毛躁是他的错，团队不规范也有锅，基于团队水平现状、开除可以减少事故率所以也是正确选择。。。

如果运气好，他找个更好团队继续飞升。

我就认识 90 后小伙子，工作前三年干倒了 6 家公司，并不算是他不靠谱，而是出身比较差去的都是比较破的公司，他自己比较上进、一直折腾轮子、搞群拉了我们好些人、老跑来跟我们问各种 sb 问题，问题从弱智到越来越高级，三年后进了家比较不错的公司，技术远超原来那些 CURD 同事，待遇也高一截

[lipcao]

需求评审，ERD 评审，测试用例评审，code review 啥都不搞的公司幸好走了还有赔偿拿可以了 ，楼主说的这些问题能针对到人典型的 PUA 啊