經常有很多讀者問我
大公司和小公司的程式設計師差別在哪？程式設計師能去小公司嗎？
大公司、小公司我都待過，今天就和大家說說我的經歷，先從小公司說起。
之前文章說過，我的第一份工作是在一家北京的小公司做程式設計師，全公司一共 6、7 個人，最開始大家都擠在一間十幾平米的屋子裡，到我兩年後離職的時候，條件改善了，搬到了一個兩居室裡。
公司裡算上我一共 3 個程式設計師，其他人都是銷售。銷售出去接專案，程式設計師負責開發專案。
小公司做專案，要求你啥都得幹，我在公司的兩年多裡，我參與的幾個專案都是我一個人完成的。
比如我做的一個專案，是給天津的一個手機銷售連鎖店做個 CRM 系統，這個系統除了 UI 找的外包，剩下的都是我一個人做的。那個年代還沒出現前後端分離這種高階概念，主流用的 Java、Servlet、JSP、JS 我自己現學現用，咬咬牙還能應付。
公司小，也沒有專門的測試，這其實還好，自己開發自己測試唄，系統也沒有多複雜，自己測試細心點就行了。
最頭疼的就是出差去天津客戶那裡，從初期的調研需求，到中期的彙報演示，到最後的部署上線、給客戶培訓，都是我一個人去的，前前後後去了很多趟。
每次客戶問起來“這個專案是不是就是你一個人做的啊？”，我都努力鎮定的說“不是，我們有 3 個人一起做”（這是老闆提前教的回答）。
客戶的疑問我們也能理解，畢竟一個 10 萬塊錢的系統，每次只見到我一個人——畢業剛一年的稚嫩程式設計師，擱誰誰也不放心，生怕給做黃了。當年北京平均房價還不到 1 萬，這 10 萬都夠一套小戶型房子的首付款了。
小公司還一個問題，就是不規範，當時我也不知道規範的流程是啥樣的。做了好幾個專案，幾乎沒寫過文件。遇到有的客戶要設計文件、使用者手冊，那簡直太痛苦了，心想還不如你再給我加幾個需求呢。
可能你們根本想不到，我那時候連 log4j、logback 都沒用過，從頭到尾都是靠 System.out.println 搞定問題。
CodeReview、SVN 這些聽都沒聽過，更別說用過了。
另外，就拿我們公司那幾個人的規模來說，就註定做不了大專案，總做小專案，總是寫 CRUD，寫時間長了就沒啥意思了，技術水平也沒啥長進了。
在小公司那幾年，雖然我乾的事情很雜、不規範，但是現在回過頭來看，那段經歷也挺珍貴：
- 一個人幹多個人的事兒，真的很鍛鍊人。
- 做事高效，有啥事情，一扭頭就可以和老闆商量了。
- 氣氛好，大家經常一起出去吃喝玩。可能也是因為公司人少錢少，根本沒有拉幫結夥去爭的必要。
後來隨著跳槽，我經歷過幾百人、幾千人、上萬人的公司，接下來再說說我的大公司經歷。
1.
公司大了，人多了，優秀的人也多了。我在一家公司認識了兩位優秀的程式設計師，和他們一起工作過程中，讓我受益匪淺，被他們帶著一起學技術、分享技術、翻譯書，這些之前文章寫過，這裡就不贅述了。
總之，他倆是對我十幾年程式設計之路幫助最大的人，認識他們之後是我的技術突飛猛進的開始。
2.
我曾經待過的一家中等規模的公司，進一個專案組沒幾天，我就感覺到技術和業務的各種矛盾。一會兒是業務說技術理解錯了，開發的功能沒有按設計來；一會兒是技術說，業務上次定好的怎麼說變就變了……就這樣討論來討論去，專案開發中間反覆修改。最後專案上線有問題了，又是互相指責，新一輪的甩鍋大會。
以上情況在其他專案組也或多或少的出現過。
經過幾次客戶投訴，老闆坐不住了，從某家大公司高薪聘來一位高管。這位高管確實有本事，強行要求了業務團隊的文件輸出，強行要求了技術團隊的結果輸出。總的來說，就是制定了一系列的流程規範，並且強制執行。
效果立竿見影，公司的各種專案落地速度加快了。當時，我還是個開發小兵，但是好處是能親身感受到的，沒那麼多會議了，沒那麼多扯皮返工的事了。
誰知道，好景不長，一年多時間，高管走了，據說是因為公司的派系鬥爭。
高管走了之後呢，規範化執行就不再那麼得力了，慢慢的又變成了以前的爛樣子。
這次的經歷，是給我留下了深刻的印象，我第一次體會到了規範化的重要性。
3.
大公司複雜的專案更多，複雜的專案可以倒逼程式設計師技術提升。
一路走來，我發現自己的技術水平很多時候其實是隨著專案的發展被迫成長的。其實，很多時候，自身水平達不到能順利完成架構專案的水平，但是隻能咬牙堅持，逼著自己不斷學習。
一個程式設計師的技術水平的高低，是看他做過多少系統，更重要是看他踩過多少坑。
就像做好幾個單體系統，都不如做一個高併發、分散式系統的含金量高。但是一直待在小公司，又接觸不多高併發。這個死結的解決辦法可以看我之前寫的這篇文章：我招了個“水貨”程式設計師
4.
複雜的專案提升技術——這一條也不總是起作用。
十幾年前，我參與過上海證券交易所的一個專案，可以說是一個又大又複雜的專案。
- 大——整個專案好幾百人，是我參與過的一個人數最多的專案，估計這個紀錄到我退休也打破不了了。
- 複雜——和股票、錢相關的專案，複雜性也不用多說了。
但是我想說的是，這個專案對我的技術成長其實幫助不大。為什麼呢？
開發的時候，整個專案被拆分的非常細了，每個小組、個人所負責的功能就那些，而且各種規範也給大家定了條條框框。比如日誌要求debug、info、warn、error必須格式到位，入參、出參、耗時更是嚴格要求列印出來。
我們當時調侃，寫程式碼就像糊火柴盒一樣。按照文件、圖糊的這些火柴盒，都不知道能搭出來一個怎樣巨集偉的系統。
很多大公司的程式設計師都像螺絲釘，人盡其責，每個人只負責一塊內容。時間長了，如果再沒有輪崗，那早晚有幹吐的一天。
5.
沒去大公司的時候，我特別羨慕大公司的培訓，這事多好啊，公司掏錢讓員工成長。
剛進大公司，我發現大部分老員工對公司的培訓並不感興趣，能不去就不去。開始我還挺不理解這事。
隨著我參加了多次培訓之後，慢慢的，我也變得和那些老員工一樣了。
- 很多培訓和技術無關
- 有些培訓學完也落不了地，比如 OKR
- 平時工作就夠累了，我學不動了，我想躺平了
- 培訓安排在週末，沒誠意
6.
大公司的福利好、工作強度大、能給個人鍍金……這些我覺得大家都知道，沒必要寫了。
以上就是我在小公司和大公司的經歷和感受，不吹不黑。
以上都是個人經驗，一家之言，可能都不對，但不接受反駁。
大公司、小公司各有利弊，無論是身在哪種公司，多看自己公司的優點：
- 大公司規範、專業；小公司靈活、高效
- 大公司專案複雜、挑戰大；小公司更鍛鍊程式設計師全才
- 大公司優秀的人多；小公司人少、是非少
- 大公司有完善的晉升機制；小公司你能力強，或許晉升很快
最後，如果你第一次進入大公司，再給大家叮囑幾句：
1.不要亂打聽薪水。小公司沒多少人，人際關係也簡單，大家接觸多，互相都熟悉，有時候顧忌少。大公司要求員工薪酬保密，還是少問別人薪水，大不了以後對玩的好的同事知根知底了，找個私下場合，聊著閒天問好了。
2.別對已經定好的規範指手畫腳。去大公司之後，各種開發規範讓我這個小公司習慣了野路子的程式設計師非常不適應。後來我明白了，大公司制定規範的那些人當然知道規範會拖慢速度，但是人家除了追求“快”，更追求“穩”，更追求開發質量，更追求專案以後的可維護。
3.多認識點優秀的人。三人行必有我師，更何況大公司本身優秀的人就多。
4.不要給自己設限。我剛去大公司的時候，雖然有專門的測試，但是我在小公司已經習慣自己開發自己測試了，所以提交測試之前我都會自己先測的差不多了，既給測試少添麻煩，又顯得自己程式碼質量高。
5.儘量參與核心業務。如果你參與的是非核心業務，即使是大公司，說不定哪天業務就被砍了，例如前幾天的位元組的教育版塊。
最最後：
不管你在大公司還是小公司，多看公司的優點。那些改變不了的東西，再怎麼糾結也沒用，調整心態，珍惜當下。
就寫這麼多吧，希望這篇文章對你有幫助。原創不易，希望得到你的三連支援。
你好，我是四猿外。
一家上市公司的技術總監，管理的技術團隊一百餘人。
我從一名非計算機專業的畢業生，轉行到程式設計師，一路打拼，一路成長。
我會把自己的成長故事寫成文章，把枯燥的技術文章寫成故事。
歡迎關注我的公眾號，關注後可以領取高併發、演算法學習資料。
