• 大公司和小公司的程序员差别在哪?程序员能去小公司吗?


    经常有很多读者问我

    大公司和小公司的程序员差别在哪?程序员能去小公司吗?

    大公司、小公司我都待过,今天就和大家说说我的经历,先从小公司说起。

    之前文章说过,我的第一份工作是在一家北京的小公司做程序员,全公司一共 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.尽量参与核心业务。如果你参与的是非核心业务,即使是大公司,说不定哪天业务就被砍了,例如前几天的字节的教育版块。

    最最后:

    不管你在大公司还是小公司,多看公司的优点。那些改变不了的东西,再怎么纠结也没用,调整心态,珍惜当下。

    就写这么多吧,希望这篇文章对你有帮助。原创不易,希望得到你的三连支持。


    你好,我是四猿外。

    一家上市公司的技术总监,管理的技术团队一百余人。

    我从一名非计算机专业的毕业生,转行到程序员,一路打拼,一路成长。

    我会把自己的成长故事写成文章,把枯燥的技术文章写成故事。

    欢迎关注我的公众号,关注后可以领取高并发、算法学习资料。

  • 相关阅读:
    python基础之字符串和字节的转换
    python学习笔记(三)字符串方法、读写文件、json处理以及函数
    python学习笔记(二):list,字典,字符串,元组,文件
    python学习笔记(一):python入门
    接口测试:jmeter学习笔记:数据库操作和压测
    接口测试:postman和jmeter随记
    设计模式之建造者模式
    设计模式之外观模式
    设计模式之模板模式
    设计模式之原型模式
  • 原文地址:https://www.cnblogs.com/siyuanwai/p/15132381.html
Copyright © 2020-2023  润新知