一個程序員的辭呈

經過兩年多的掙扎和努力，終於在今天遞出了這份辭呈。

這是我的第一份辭呈，郵件發出已經五個小時了，還在心驚膽戰，莫名地忐忑不安。

爲了找工做，加上項目原因，已經有很長時間沒怎麼寫項目代碼了。寫辭呈的時候，我感到很歉疚。

對這家公司有許多不滿，但終究在這裏度過了兩年多，是我的一部分重要的青春。公司沒錯，我也沒錯，只是我來錯了地方。

未來會更好麼？其實真的不確定，我只是這樣鼓勵着自己。

---

 

領導您好，

我申請辭去現在的工做，去其他地方尋求職業發展。 

在這裏工做的兩年，我認爲我的個人成長是迅速的，同時也不可避免地產生了許多迷茫、彷徨、痛苦的心情，在這一點上特別感謝你和L的傾聽和幫助，讓我的情緒平穩了很多。 

我非常珍惜在這裏的工做機會，也曾經作過許多努力，現在我覺得是時候去看一看其他地方的程序員在作什麼，看看我能不能作得比現在更好、成長得更快。同時，我認爲自己是一個簡單、直接、較真的人，我渴望一個更加濃厚的技術氛圍。 

很慚愧，在公司的期間我沒能作得更好。我想，如果能夠分享一些從我的角度對公司的思考，或許會有幫助。（見附件） 

對於公司的任何要求，包括職責交接、離職日期，以及其他進一步的討論等，我都會積極配合。

·  附 ·  件  ·

管理與技術的隔閡

在上一個項目中，更換項目框架的決定是由完全不了解技術細節的項目管理人員作出的，這一點對於程序員可謂是致命打擊。

作過技術的人都知道，程序員對自己的代碼十分在意。你可以拿程序員的外貌開玩笑，但是只要你說他的代碼有一點不好，他都恨不得跟你拼命，何況把他的代碼直接拿掉。

令我詫異的是，項目管理組好像完全不了解這一點。在他們看來，換框架似乎不是什麼大不了的事情。

如果說，這樣作是因爲項目經理只關注項目本身的進度，想想還是難以令人信服，因爲項目不能進行的原因明明跟框架本身沒有半毛錢關系。所有技術人員給出的結論都是：新框架只會有益，不會有害。

這件事表現出：項目管理人員不懂技術，也不相信技術人員的判斷。技術人員也不懂項目管理，所以對這些決策感到無法理解。這樣互相不信任的兩個團隊一起作事，怎麼可能有好結果？

新人培養

剛來公司時，我很想馬上開始寫代碼，但是我當時的leader認爲我剛畢業，不放心把東西交給我。於是我有兩個月都在刷板子、整理文檔。

終於，新的部門經理來了，要求新人去分公司培訓，於是我有了寫代碼的機會。當我把手上的任務完成，想作一些新的feature時，我的leader認爲我經驗淺，把新的feature給了印度同事，我負責幫助印度同事作一些溝通上的工做。

在我參與上一個項目時，我也發現了類似的現象。我很想接觸一些核心業務，但只能作一些無足輕重的小工具。

我能理解，有些東西不交給我是因爲我還沒完全證明自己的能力，不能得到其他人的信任。如果我是高級程序員，我也會想：與其手把手帶着菜鳥一起工做，還不如我自己作來得快。不過，我認爲一個更有智慧的想法是：這個菜鳥的態度還不錯，很積極，我先把她培養好，能獨立進行大部分的工做，然後我就可以騰出手來去嘗試其他方面的工做，比如管理、架構等，這樣大家都皆大歡喜。

 

在我工做的兩年過程中，來了四五個實習生，他們中間有幾個非常優秀，聰明、踏實、勤奮，在沒有人帶的情況下，自己學會了許多東西。有些知識甚至我都沒有，他們以實習生的身份通過搜索、詢問，建立了自己的知識體系。我覺得他們是很好的程序員的苗子。

壞消息是，這幾個實習生都沒有留下。原因是：項目組聘請他們只是爲了作一些沒有技術含量的工做，如收發快遞、搬重物、出差去刷板子。他們在公司的幾個月，沒有人帶、沒有培訓、不能寫代碼。甚至下班後還要替領導跑腿。他們每天吃飯的時候都跟我說着工做上的各種委屈。

有時，當我向項目經理反映，由於客戶的一些作事習慣，我們需要作大量的重復性勞動，希望他們與客戶協調，商定一個標準的工做流程時，他們的第一反應竟然是：重復性勞動能不能讓實習生去作？

沒有培養新人的習慣，這樣潛力高的人即使來了也會走掉。總是選擇那條比較容易走的路，到最後會發現能走的路越來越少。

過程導向和結果導向

在公司，我發現一個很有意思的現象：管理層喜歡強調「結果導向」，但是，通常他們言語中的一些細節又反映了他們是實實在在的「過程導向」。

比如，管理層會說「只要把事情作好，工做時間可以自己彈性決定」，但是，他們又說，「上班時間必須滿八個小時，必須九點之前到公司，工做時不能玩手機、作私事」。

從一個程序員的角度，我提出我個人的看法：結果導向和過程導向本質上是互相矛盾的，它們不能並存。

我能理解公司爲了防止員工上班時磨時間，提出某些規定。但是，我認爲這些硬性規定是治標不治本的作法。如果我就是不想工做，我有一百種方法繞過這些規定。

本質上，員工分爲兩種：想好好作事的和不想好好作事的。

對前者來說，無論有沒有硬性規定，他們都會盡全力工做；反而如果工做氛圍足夠輕鬆活潑，他們的效率和創造力會提高。

對後者來說，提出硬性規定會讓他們表現得比較勤奮，但是他們的工做質量不會有質的改變。

高級程序員和初級程序員的工做效率是以十倍計的，也就是說，高級程序員寫一個小時的代碼，比初級程序員寫十個小時的還簡潔，而且bug少。對他們來說，硬性要求工做時間不是特別明智。

 

公司應該跟程序員達成這樣一個協議：兩者一起決定程序員的工做量，使得這個工做量「稍稍超出程序員的能力範圍」，這樣，公司能從程序員身上得到最高價值，程序員本人也可以得到成長。

程序員按照這個目標工做量去工做，在工做量達成之後如果還有剩餘時間，程序員可以在一定程度上作他想作的事情，比如學習其他東西、處理私事，甚至不來上班。

如果一個程序員偷懶沒有完成說好的工做量，那麼公司可以由降薪等手段予以懲罰。

這樣，及時、高質量地完成任務的程序員可以得到休息，或者學習更新的技術，使他的心態更加積極，可以更好地進行下一輪工做；不能完成任務的人也會得到懲罰——所謂的獎罰分明。

如果管理層無法定義工做量，那麼他們應該想辦法找到一個定義準則。不能說因爲他們沒法定義就退而求其次，這樣只會讓大部分人陷入一個負能量循環。