经常有很多读者问我
大公司和小公司的程序员差别在哪？程序员能去小公司吗？
大公司、小公司我都待过，今天就和大家说说我的经历，先从小公司说起。
之前文章说过，我的第一份工作是在一家北京的小公司做程序员，全公司一共 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.尽量参与核心业务。如果你参与的是非核心业务，即使是大公司，说不定哪天业务就被砍了，例如前几天的字节的教育版块。
最最后：
不管你在大公司还是小公司，多看公司的优点。那些改变不了的东西，再怎么纠结也没用。
调整心态，珍惜当下。
发表评论 取消回复