程序员惨遭辞退竟只因提了些代码修改意见？
点击上方“CSDN”，选择“置顶公众号”
关键时刻，第一时间送达！
【CSDN编者按】技术人在职场中，是该做“正确的事”，还是该做“正确的人”？如果想做一番实事，就应该大刀阔斧、扫除一切破旧技术。但如果想在职场中如鱼得水、混得更好，随波逐流或许才是最好的选择。本文的作者Renato Athaydes将将试用了五个月，就惨遭辞退了——不是技术不好，而是技术太好从而引发了“众怒”。原因如何，我们来一探究竟。
以下为译文：
在工作了5个月后，我被老板辞退了。一般来说在我们国家，我签的合同包括6个月的试用期，在此期间内任何一方（员工或者老板）都可以终止合同，基本上不用提前通知。
我很惊讶……不是因为我以为自己做得非常出色，很长一段时间里我自己很不开心，我知道一些同事也不是很喜欢我……我觉得惊讶是因为几周前我们进行了“业绩考核”，当时我大多数同事都恭喜我，说我的工作做得很好，只有一个人不太满意我的工作，在和别人一样夸奖了我一番后，给我了一个暴长的列表，上面写着他认为我需要改进的地方。
在讨论这个列表之前，先让我从头给你讲讲我的故事。
我的这份工作的薪资和福利非常好，虽然没有很响亮的头衔，就是个简单的后台开发，我曾要求他们改成软件开发，以准确地表述我的能力，而不仅仅是片面的技术力。我的技术总监对我的技术测试非常满意，而且非常幸运的是：他在面试我的时候，知道我做过Kotlin，就在讨论过程中问我怎么看Kotlin（我个人认为Kotlin是非常好的语言） ，他说他读过一篇文章说Kotlin的性能非常具有竞争力……结果发现，我就是那篇文章的作者！
这个开头看似好极了，所以我决定辞掉Curity（很有前途的授权与认证的服务商）舒服的工作，并加入了这家做支付系统的公司。
我希望自己学习新技术，并有机会接触Cassandra、亚马逊ECS和Kubernetes等高访问量以及可伸缩的系统。我已经在产品开发公司工作了多年，一方面能够了解整个代码库是一件好事，在Curity的时候，因为我们做的产品相对较新，所以有很多未开发的领域。但是，另一方面，你所接触的技术非常有限，比如我，过来过去就是Java虚拟机的东西，包括Java及其语言、Kotlin、Groovy、Jetty等等。
新上任的第一周，我被分到了一个临时的队伍，负责修复非常紧急的安全问题。在我第一次接触新同事的时候，就感觉到一丝异样：尽管与我之前的工作相比，此次修改非常的简单，但是其他开发看似对当时的情况倍感压力，他们还说需要几个月的时间才能解决问题。可是，我觉得几天应该就够了！
作为公司的新人，有可能我不清楚一些他们没跟我说的具体细节，但是无论如何，情况非常紧急，经理要求我们在两周内改好，但据我的理解，两周不是硬性规定。
然而，开始着手工作后，我发现根本就没有什么复杂的东西是我没有预见的，实际上问题非常小，我们几乎只用了一周就做完了，尽管之后我们还花了很多时间讨论可能的替代方案。因为我有这方面的经验，所以我带头实装了解决方案，并写了大部分代码（不幸的是，这个项目不是开源的，所以我不能确认，但是我可能写了超过70%的代码）。第二周我们大多时候都在做测试，并与其他相关团队沟通我们的解决方案。
有人似乎很担心将这些代码部署到产品中去……很明显，他们不相信测试系统能在上线之前找到所有的问题。对我来说，这其实是第二个警告，我以前都是尽可能建立一个可以可靠地重现生产环境的模拟环境，这样在代码通过单元测试、系统测试和一些最终的手工测试之后，我可以很自信产品不会出什么严重或明显的问题。即便有问题，也只能说明测试没有覆盖到所有的边缘用例，并不关乎产品和模拟环境的差异。
无论如何，我们将此次修改部署到生产环境，就是很大的胜利，尤其是对我来说，我才在这个公司干了一周，就可以在修改严重问题的工作中担任重要的角色。
但是从这次最初的经历中，我发现了这个公司的开发流程中的很多东西还差得比较远，所以我决定指出我们需要改进的地方。
我注意到，每当我指出什么东西不对时，技术组长就非常不高兴，很明显他个人以为我指出的这些错误是针对他的：没有输入验证，很多半途而废的修改，缺乏单元测试，生产环境与模拟环境之间显著的差异，开发人员从自己的机器上发行代码而不是从CI服务器上……等等问题导致了代码质量的低下，在我看来，这些都是不可忽略的。他们给我的答复总是千篇一律：他们不得不考虑时间限制，或人手不够……都是常见的，惯用的（即便无法令人满意）借口。
但是，我不能只指责别人，而不提出更好的方法，所以我马上开始修改最明显的问题，那些当我刚开始接触微服务时注意到的问题。这些问题需要很大范围的修改，并需要写很多单元测试。我将写的代码分成几次提交，希望有人能帮我确认测试的用例是有效的。
就在此时，我和我们队伍的关系开始恶化。我经常发现我提交的PR闲置好几天也无人问津。我不厌其烦地找他们，求他们审核我的修改，但是很显然我做了太多改动，即便我事先将PR分成了几次提交，也没人愿意审核我的代码。这种情况一直持续发生，也可能是导致我们之间出现问题的根本原因。
我注意到不仅是我……其他人的PR也会被搁置好几天，甚至几个月都是常见的：我甚至发现别的项目中有的PR甚至整整一年都没人审核。
如果我有一个搁置的PR，那么我会从PR分支上创建一个新的分支，然后继续我的工作，直到我准备提交下一个PR，所以PR审核不够快的话，会导致PR堆积成山。请注意我们说的是几天，而不是几个小时！
我跟组长讲了这个问题，结果他说他们不能花整天的时间审核我的代码！我感觉是因为自己工作太快而惨遭人指责。
队伍中的另一个人开始指责我，说我的PR太乱。一些人抱怨我去帮助别的队伍的工作，就好似他们可以做主我可以干什么不可以干什么，可是对我来说那都是很简单的工作，而且我绝对没有影响到我们的进度。所以，很显然每个人都不满我拿着白菜的钱，却做着太多的工作。
不止一个人跟我说，工作慢一点，别着急。
为了给大家做个榜样，我很快地审核了别人提交的PR，结果有人抱怨我说，他的PR还没准备好我就给审核掉了……但是我觉得吧，如果你没有准备好让别人审核你的PR，那你为什么要提交PR呢？！你压根不应该提交PR呀！！
这个时候，我感觉自己所做的一切都受人指责（除了代码，尽管我倒是很希望有人能指出我代码上的不足），这种氛围太浓烈，我有点难以承受……所以我开始越来越有戒心，这让情况愈演愈遭！我想着干脆重回我之前的工作（原来的同事很欢迎我回去），但是我有点担心我的简历看起来似乎我是一个喜欢跳来跳去的人。而且，我天生不喜欢放弃，如果事情进展不顺利，那我更要倾尽全力。
一两个月后……直到现在我们都在做Cassandra数据库的迁移，这项工作不仅涉及代码，还需要数据的变更，包括数据结构。这类的工作如果是发生在Postgres等SQL数据库上那很简单，但是Cassandra不一样，这基本上可以让我们的数据分崩离析。
一个自称Cassandra专家的家伙写了一些代码进行数据转移。但是很显然他遇到了麻烦，每次他尝试在较大的数据卷上运行数据转移时都会报错。他说数据配置源已经崩了，因为内存中的数据太多了（或者其他这方面的问题）……我调查后发现这个错与内存一点关系都没有，只是Java的classpath中出现了冲突，从而引发了代码中的一个路径抛出了NoSuchMethodError的错误。我试图跟他解释，但是貌似他根本听不懂我在说什么，很显然他对Java运行时的知识非常有限。这让我对他的技术信心大打折扣。后来与他争论技术问题的时候都很困难，因为我知道不能相信他的判断（之后这个人也曾几度在技术上做出了错误的判断），而当我跟他说“你说的不对”，“我不相信你”（当别人大放厥词，比如他说“不能在Cassandra中迭代所有行”时，我只能这么回答他）的时候，别人可能感觉我很不理性。
不管怎样，之后我找到了我们所需的正确的代码库版本，那段代码终于跑通了……但是他争辩说在Cassandra中我的方法行不通。他建议我应该去读一读Cassandra的书，还问我知不知道自己在干什么，即便是我推动了整个进度，解决了问题，而不是他。可能我不是特别了解Cassandra，但是我有CouchDB、MongoDB、MySQL、Postgres等等数据库的经验……我无法想象一个数据库居然不能提供在表内做所有数据分页等基本的功能。
最后不照样好使了嘛。测试显示所有的数据都按照预想的正确地迭代了。但是有一个坏消息：在不了解情况的人看来，我是个愚昧的人，不懂Cassandra，有人给出专家建议，我还不听（如果他真的是专家，就该由他来写代码，但是他忙着玩Terraform，试图自动部署新的数据库集群，我们都明确说了这根本没必要。）还有更甚者，另一位同事指出我非常愚蠢，居然用BATCH语句往新的数据表中插入数据，而这个人从来也没有写过一行代码帮助我们的工作！
问题在于：Cassandra书中确实不允许在加载的时候使用BATCH语句，因为会影响到节点的稳定性。所以他没说错……但是我没有直接使用BATCH语句，而是通过类似Java的东西写的，我读过文档，说与这个问题一点关系都没有。无论怎样，我在大家心目中的形象已经毁了，因为我在批处理中使用了BATCH语句这样大的错误。
我不喜欢大家这样看我，所以我决定用数据验证这个问题。我测量了一下在使用BATCH语句和独立的语句时节点产生的负载状况。我完全无法理解为什么应该发送成千上万的独立语句到DB上执行，而不是像任何正常的数据库客户端那样利用BATCH将它们打包到一起。我的测试很全面，所有测试都表明，无论在JVM还是OS上，BATCH导致的负载都显著低于独立语句，其结果与书上完全相反。有可能BATCH在拥有大量节点的情况下会过于昂贵，但我们只有几个节点而已！所以这个问题完全不会影响到我们。我还给团队做了次演说来展示我的发现。
最后有人认同我的努力并同意使用BATCH吗？没有！相反，他们认为我太固执，从来不肯听取意见。
没错，我确实很固执！但如果测试结果表明BATCH性能更差，那我肯定会第一个改变看法。这个偏见还导致另一个结果，他们认为我太强势（有人对我人身攻击），估计这是压垮他们的最后一根稻草。
最后我们决定不用BATCH。但是，他们让我负责数据库转移过程中的流量控制。在我看来这十分荒谬，而且透露了他们对技术的无知：我已经采用了限流的方式防止INSERT语句冲垮数据库——“生产者”每次只发送一组请求（我们不再用BATCH了）然后等待所有请求结束后才发下一组。在这种情况下，在“批次”之间通过sleep进行流量控制似乎完全没有必要——特别是当“消费者”是Cassandra时，这个数据库的目的就是处理高吞吐量。而且我的测试结果显示这种方式对最终用户完全没有任何影响（我通过在运行脚本的服务器上运行模拟实际情况的负荷测试进行的）。
但无论如何，我的争论似乎完全没有意义。
最后，数据库转移成功了。虽然我们花费的时间比实际所需得要多，但是最后只出现了一些小问题，并没有影响到产品。
技术总监说，我们应该买个蛋糕庆祝一下，一般来说这种情况都值得庆祝。几天后，我离开了公司。
在公司的5个月里，每一个任务我都做得很出色，但是很多方面我做得还不够，最重要的是不讨人喜欢。
在我之前的工作中，我很确定很多人喜欢我（我离职的时候，好几个人挽留我），即便是在现在这份工作中，我也有几个很好的朋友。但是由于不清晰的流程引发的碰撞和技术争论，再加上不同的工作理念，所以导致我目前的情况，我的队友不喜欢我，他们要我走人。
这给了我一个很大的教训，我希望这篇文章可以帮我自己和别人明白，冰冻三尺非一日之寒，小不忍则乱大谋。
那张列表上指出的我需要改进的地方包括：多听别人并接受他们的意见，不要过于有戒心，不要太强势……基本上就是说要更加讨人喜欢。
我知道了我犯了很多错误，但是我相信犯错的不只是我一个人……但是我还在试用期，所以，再见，谢谢所有的人。
以上即为作者Renato Athaydes惨被辞退的经历。对于他的这一遭遇，Hacker News上有很多网友给出了自己的看法。
评论一：
同情楼主，下面是我在“专业”环境中工作时总结的一些教训，希望能帮到你。
在把现有系统扔进垃圾堆之前必须先赢得尊敬，不管那些代码是如何垃圾，或如何缺乏测试。一般来说最好先“老实完成工作”，做功能也好改bug也好，因为你现在处于食物链的最底层。赢得了“尊敬”之后，再做新的东西就容易了。
垃圾代码进入生产环境的借口很可能是正确的借口，一家以SaaS产品为生的公司需要快速上线并快速迭代。产品经理、销售和市场人员可不在乎你的单元测试。用户也不在乎你的单元测试。不幸的是这是个进退两难的局面，因为一旦出了问题就是你的责任。
要明白，你之前的团队为了特定的原因做出了特定的选择，无论选择正确与否，在扔掉他们的垃圾之前必须先接受之。
或者你可以自己开个公司自己制定规则。
评论二：
我认同上面的观点。从楼主的经历中我看到了两点：
显然博主的技术力远远超过了他所在的团队。他有经验，知道最佳实践，还能够改进软件过程。
第二点，却是最关键的一点，他很不擅长在团队合作，也不擅长沟通。在他说的五个月的时间内你没法改变任何东西。那是公司的文化。如果你不是老板，那就只能通过柔和的建议、潜移默化的影响、裙带关系、讨论等……不依靠强制手段（或恐吓），改变行为是完全不可能的。只能慢慢来，而且并不是每个人都能讲道理的。这个就说来话长了。
其实我是在说，我同意他离职是个更好的选择。
评论三：
没错，这个人和这个公司三观不合呀。
有个老笑话，面试之后应该问三件事：第一，她能干活吗？第二，你能和她一起干活吗？第三，她是个杀人狂吗？
博主肯定能满足上面的条件之一，但即使他们能容忍条件三，那么不满足条件二就足够把你扫地出门了。
当你发现所处的环境很垃圾（以你的观点）时你只有两个选择：选择留下来，就必须努力适应环境并与其他人好好相处。
貌似博主选择的处理方式跟他的想法完全不一样。“做正确的事”固然没错，但如果你招人烦，那么干得多好都是错的。
作为一个过来人，这种经历我有过好几次，最后终于在感觉自己换工作太频繁的时候，想通了应该如何在“与人相处”和“做正确的事”之间做出选择。
观念的转变很痛苦，而且我有过多次反复，使得别人都以为我又要回到以前的待人方式了——那种感觉依然在我脑海里回旋呢。但最终我做到了，而且现在我是那种能和人好好相处的高手之一了。
从我的薪水上就能看出我现在很受欢迎。
毕竟，就像老Janis说的，“如果不能和你爱的人在一起，就去爱和你在一起的人。”这样你就能更快乐，压力和血压都会降低，社交也会更广泛，连工资条都会奖励你。
评论四：
我在Coursera上的一门社会心理学课程上学到，受欢迎的孩子和不受欢迎的孩子的重要区别是，不受欢迎的孩子加入圈子后会提议玩个新的游戏，而受欢迎的孩子会和大家一起玩一会儿再提议新的游戏。
显然跟这个故事有点类似……为了“受欢迎”，你得先迎合他们正在做的事儿，再慢慢寻求改变。这并不是正确与否的问题，而是如何才能受欢迎的问题。
原文：https://sites.google.com/a/athaydes.com/renato-athaydes/posts/belikeableorgetfired
作者：Renato Athaydes
译者：弯月，责编：言则
————— 推荐阅读 —————
点击图片即可阅读