一个程序员的辞呈

经过两年多的挣扎和努力，终于在今天递出了这份辞呈。

这是我的第一份辞呈，邮件发出已经五个小时了，还在心惊胆战，莫名地忐忑不安。

为了找工做，加上项目原因，已经有很长时间没怎么写项目代码了。写辞呈的时候，我感到很歉疚。

对这家公司有许多不满，但终究在这里度过了两年多，是我的一部分重要的青春。公司没错，我也没错，只是我来错了地方。

未来会更好么？其实真的不确定，我只是这样鼓励着自己。

---

 

领导您好，

我申请辞去现在的工做，去其他地方寻求职业发展。 

在这里工做的两年，我认为我的个人成长是迅速的，同时也不可避免地产生了许多迷茫、彷徨、痛苦的心情，在这一点上特别感谢你和L的倾听和帮助，让我的情绪平稳了很多。 

我非常珍惜在这里的工做机会，也曾经作过许多努力，现在我觉得是时候去看一看其他地方的程序员在作什么，看看我能不能作得比现在更好、成长得更快。同时，我认为自己是一个简单、直接、较真的人，我渴望一个更加浓厚的技术氛围。 

很惭愧，在公司的期间我没能作得更好。我想，如果能够分享一些从我的角度对公司的思考，或许会有帮助。（见附件） 

对于公司的任何要求，包括职责交接、离职日期，以及其他进一步的讨论等，我都会积极配合。

·  附 ·  件  ·

管理与技术的隔阂

在上一个项目中，更换项目框架的决定是由完全不了解技术细节的项目管理人员作出的，这一点对于程序员可谓是致命打击。

作过技术的人都知道，程序员对自己的代码十分在意。你可以拿程序员的外貌开玩笑，但是只要你说他的代码有一点不好，他都恨不得跟你拼命，何况把他的代码直接拿掉。

令我诧异的是，项目管理组好像完全不了解这一点。在他们看来，换框架似乎不是什么大不了的事情。

如果说，这样作是因为项目经理只关注项目本身的进度，想想还是难以令人信服，因为项目不能进行的原因明明跟框架本身没有半毛钱关系。所有技术人员给出的结论都是：新框架只会有益，不会有害。

这件事表现出：项目管理人员不懂技术，也不相信技术人员的判断。技术人员也不懂项目管理，所以对这些决策感到无法理解。这样互相不信任的两个团队一起作事，怎么可能有好结果？

新人培养

刚来公司时，我很想马上开始写代码，但是我当时的leader认为我刚毕业，不放心把东西交给我。于是我有两个月都在刷板子、整理文档。

终于，新的部门经理来了，要求新人去分公司培训，于是我有了写代码的机会。当我把手上的任务完成，想作一些新的feature时，我的leader认为我经验浅，把新的feature给了印度同事，我负责帮助印度同事作一些沟通上的工做。

在我参与上一个项目时，我也发现了类似的现象。我很想接触一些核心业务，但只能作一些无足轻重的小工具。

我能理解，有些东西不交给我是因为我还没完全证明自己的能力，不能得到其他人的信任。如果我是高级程序员，我也会想：与其手把手带着菜鸟一起工做，还不如我自己作来得快。不过，我认为一个更有智慧的想法是：这个菜鸟的态度还不错，很积极，我先把她培养好，能独立进行大部分的工做，然后我就可以腾出手来去尝试其他方面的工做，比如管理、架构等，这样大家都皆大欢喜。

 

在我工做的两年过程中，来了四五个实习生，他们中间有几个非常优秀，聪明、踏实、勤奋，在没有人带的情况下，自己学会了许多东西。有些知识甚至我都没有，他们以实习生的身份通过搜索、询问，建立了自己的知识体系。我觉得他们是很好的程序员的苗子。

坏消息是，这几个实习生都没有留下。原因是：项目组聘请他们只是为了作一些没有技术含量的工做，如收发快递、搬重物、出差去刷板子。他们在公司的几个月，没有人带、没有培训、不能写代码。甚至下班后还要替领导跑腿。他们每天吃饭的时候都跟我说着工做上的各种委屈。

有时，当我向项目经理反映，由于客户的一些作事习惯，我们需要作大量的重复性劳动，希望他们与客户协调，商定一个标准的工做流程时，他们的第一反应竟然是：重复性劳动能不能让实习生去作？

没有培养新人的习惯，这样潜力高的人即使来了也会走掉。总是选择那条比较容易走的路，到最后会发现能走的路越来越少。

过程导向和结果导向

在公司，我发现一个很有意思的现象：管理层喜欢强调“结果导向”，但是，通常他们言语中的一些细节又反映了他们是实实在在的“过程导向”。

比如，管理层会说“只要把事情作好，工做时间可以自己弹性决定”，但是，他们又说，“上班时间必须满八个小时，必须九点之前到公司，工做时不能玩手机、作私事”。

从一个程序员的角度，我提出我个人的看法：结果导向和过程导向本质上是互相矛盾的，它们不能并存。

我能理解公司为了防止员工上班时磨时间，提出某些规定。但是，我认为这些硬性规定是治标不治本的作法。如果我就是不想工做，我有一百种方法绕过这些规定。

本质上，员工分为两种：想好好作事的和不想好好作事的。

对前者来说，无论有没有硬性规定，他们都会尽全力工做；反而如果工做氛围足够轻松活泼，他们的效率和创造力会提高。

对后者来说，提出硬性规定会让他们表现得比较勤奋，但是他们的工做质量不会有质的改变。

高级程序员和初级程序员的工做效率是以十倍计的，也就是说，高级程序员写一个小时的代码，比初级程序员写十个小时的还简洁，而且bug少。对他们来说，硬性要求工做时间不是特别明智。

 

公司应该跟程序员达成这样一个协议：两者一起决定程序员的工做量，使得这个工做量“稍稍超出程序员的能力范围”，这样，公司能从程序员身上得到最高价值，程序员本人也可以得到成长。

程序员按照这个目标工做量去工做，在工做量达成之后如果还有剩余时间，程序员可以在一定程度上作他想作的事情，比如学习其他东西、处理私事，甚至不来上班。

如果一个程序员偷懒没有完成说好的工做量，那么公司可以由降薪等手段予以惩罚。

这样，及时、高质量地完成任务的程序员可以得到休息，或者学习更新的技术，使他的心态更加积极，可以更好地进行下一轮工做；不能完成任务的人也会得到惩罚——所谓的奖罚分明。

如果管理层无法定义工做量，那么他们应该想办法找到一个定义准则。不能说因为他们没法定义就退而求其次，这样只会让大部分人陷入一个负能量循环。