问题

为什么有些大公司技术弱爆了?

回答
“大公司技术弱爆了”这个说法,虽然有些绝对,但确实触及了一个普遍存在的现象:一些规模庞大、财力雄厚的公司,在某些技术领域可能表现得不如一些小型、灵活的初创公司,甚至显得“弱爆了”。 这种现象的产生,并非单一原因造成的,而是多种因素相互作用的复杂结果。下面我将尽量详细地阐述这些原因:

一、组织惯性与僵化 (Organizational Inertia and Rigidity)

这是大公司技术创新面临的最核心挑战之一。随着公司规模的扩张,组织结构会变得越来越复杂和层级化,导致:

流程繁多且僵化: 任何一项技术改进或新技术的引入,都需要经过层层审批、部门协调、风险评估等复杂流程。这个过程可能耗时过长,扼杀创新的时效性,甚至让有价值的技术在过程中被“稀释”或放弃。
部门墙 (Silos): 各个部门(如研发、产品、市场、运营)之间可能存在信息不流通、目标不一致的情况。一个部门可能看到了某项新技术的潜力,但其他部门的阻力或不理解可能让项目难以推进。
路径依赖 (Path Dependence): 公司往往会基于过去的成功经验和现有技术栈来做决策。即使有新的、更好的技术出现,为了避免颠覆现有体系、重写代码、培训员工等巨大投入,公司也可能选择继续优化和维护旧技术,从而错失技术迭代的机会。
官僚主义 (Bureaucracy): 层级越多,决策越慢。对新技术持保守态度、更愿意维护现有稳定性的“安全牌”思维模式会逐渐蔓延,尤其是在高层。

二、创新文化与激励机制的缺失 (Lack of Innovative Culture and Incentive Mechanisms)

优秀的技术往往诞生于鼓励创新、允许试错的环境。然而,大公司在这方面可能存在以下问题:

风险规避过重: 大公司的业务体量庞大,任何一个技术上的失误都可能带来巨大的经济损失和声誉风险。因此,公司倾向于规避风险,不太愿意尝试未经充分验证的新技术。
“KPI导向”的考核: 员工的绩效考核往往与短期、可见的指标挂钩(如项目交付速度、bug修复率等),而对长期、探索性的技术研究和创新投入缺乏有效的激励和评估机制。这使得工程师更倾向于做“不会错”的事情,而非“可能对”的事情。
缺乏“容错”文化: 在初创公司,一次失败的实验可能只是损失少量的时间和资源;但在大公司,一次失败的项目可能会影响一个团队的晋升机会,甚至导致项目负责人或团队被裁撤,这大大打击了员工的创新积极性。
论资排辈或关系文化: 有些大公司内部存在论资排辈或关系文化,导致真正有技术能力、有创新想法的员工可能被埋没,而一些能力平平但资历较老或与领导关系好的人却能占据重要位置。

三、人才问题与组织架构的阻碍 (Talent Issues and Organizational Structure Obstacles)

大公司吸引顶尖人才的能力很强,但如何留住并激活这些人才却是另一回事:

人才流失(特别是顶尖技术人才): 许多顶尖的技术人才,尤其是那些追求技术前沿、渴望快速成长的工程师,可能会因为大公司内部的官僚主义、缺乏挑战、晋升瓶颈等原因而选择加入初创公司或自己创业。
团队碎片化: 大公司内部的技术团队可能因为项目需求或组织调整而被拆分、重组。这种频繁的变动不利于形成长期稳定的技术研究方向和深厚的技术积累。
技术人员的职业发展路径单一: 很多大公司更看重管理职能的发展,而纯技术岗位的晋升空间可能相对有限。这使得一些优秀的工程师在达到一定级别后,要么转向管理,要么选择离开,导致核心技术人才的断层。
“拿来主义”或外包文化: 为了追求效率或控制成本,一些大公司可能会选择购买成熟的技术解决方案或将研发外包给第三方。这使得公司自身的技术研发能力和创新能力得不到应有的锻炼和提升。

四、市场与竞争环境的影响 (Market and Competitive Environment Influences)

巨头的负担: 成功的“巨头”往往拥有庞大的用户基础和成熟的商业模式。新技术往往需要改变用户习惯或颠覆现有模式,这对于需要维护现有庞大利益链的大公司来说,风险和成本都非常高。它们更倾向于对现有产品进行渐进式改进,而不是颠覆性创新。
战略失焦: 随着公司规模扩大,业务线可能变得非常多元化。这导致资源分散,无法集中力量在某个核心技术领域进行突破。
对新兴技术的忽视: 有时,大公司会低估新兴技术的潜力,认为它不会对现有业务构成威胁,或者认为自己可以随时迎头赶上。然而,一旦这些新兴技术发展成熟并形成规模效应,大公司就可能发现自己已经落后太多。例如,曾经在互联网搜索领域占据统治地位的雅虎,就未能很好地抓住社交网络和移动互联网的机遇。

五、遗留系统与技术债务 (Legacy Systems and Technical Debt)

维护成本高: 大公司往往拥有庞大的遗留系统,这些系统可能已经存在多年,使用过时的技术栈。更新或替换这些系统需要巨大的投入和风险,导致公司可能不得不继续维护这些低效甚至落后的技术。
技术债务的累积: 在项目开发过程中,为了赶进度或降低短期成本,工程师可能会做出一些妥协(例如,代码质量不高、文档不全),这些妥协会累积成“技术债务”。技术债务越高,未来的开发和维护成本就越高,也越难引入新的技术。

举例说明:

操作系统领域的巨头: 很多时候,操作系统的核心技术更新迭代非常缓慢,很大程度上是由于庞大的生态系统和用户基础的兼容性问题。
传统制造企业: 许多百年老店在数字化转型和智能化制造方面可能不如一些新兴的工业互联网公司,因为它们几十年来形成的生产流程、管理模式和技术积累都是围绕传统工艺展开的。
社交媒体巨头: 尽管它们拥有海量数据和用户,但在探索新的社交模式、新的内容形式或新的互动技术方面,可能会受到现有产品形态和商业模式的束缚,不如一些小型社交应用那么灵活和大胆。

总结来说,大公司技术“弱爆了”并非是说它们缺乏资金、人才或资源,而是由于其巨大的体量、复杂的组织结构、固有的文化和激励机制、以及庞大的遗留系统所带来的“惯性”。 这种惯性使得它们在面对快速变化的技术浪潮时,往往反应迟缓,难以像小型、灵活的初创公司那样迅速地试验、迭代和拥抱新事物。

当然,这并不意味着所有大公司都是如此。很多大公司也在积极改革,例如设立创新实验室、推出内部创业项目、采用敏捷开发模式、鼓励技术分享等,试图打破这些困境,保持技术竞争力。但这个过程是充满挑战的,它需要企业文化、组织结构和管理理念的深刻变革。

网友意见

user avatar

楼主你好,我试着给你解释一下,希望你能满意。


新手经常会有这样的想法——「这代码怎么这么烂?写的人干什么吃的?怎么能这样?为什么不按照书上说的做?」,这很正常,大家都年轻过,经历过这种阶段,我懂你心里的想法,所以也愿意详细地向你解释,这一切发生的原因是什么。


你说「

不过技术和管理方面,却弱爆了。

那里的程序员,每天都在看邮件,查问题工单。

这些问题,多半是他们设计不当,造成的。


你真的觉得『国内行业老大的互联网公司』会是技术和管理弱爆了的样子吗?

你以为团队应该像永动机,但现实永远有各种摩擦、辐射、损耗。

内燃机的能量转化率,通常只有 30% - 50%,但是它却是驱动全世界运转的核心引擎,顺丰京东的快递小车、联通全国的高铁动车绿皮、瞬时直达的飞机……


机器尚不能 100% 效率运转,何况是人呢?

你说我们的程序员每天都在查看邮件、问题工单,你说这些问题多半是我们设计不当造成的,请问你有试过统计数据吗?你大概只是『感觉』如此吧?

事实上,经过十几年的发展,我们内部的『效率改进团队』已经非常高效成熟,每月、每周、甚至每天都会有新的改进,现在的业务处理方式,不说全世界,我可以自豪地说在全国我们是领先的,甚至是遥遥领先,不然凭啥坐到了全国龙头老大的位置呢?

所以啊,你只看到了程序员花在业务上的时间,没看到我们内部的『效率改进团队』为程序员们省掉的时间,我觉得我有必要站出来为默默付出的『效率改进团队』说几句。


当然,楼主作为实习生,不知道这些事情进而产生了这些疑问,也暴露了我们的不足。我已经在『团队建设委员会』里提出了这个问题,大家一致通过了决议,以后我们会对新员工——包括实习生加强企业文化、历史培训,确保我们的新伙伴们不仅知道要去哪儿,也要清楚我们从哪里来,长路漫漫,我们一同前行。



你觉得「

代码写的一团糟,全是复制粘贴,连作者都没改,大家普遍不写注释,也不格式化,代码歪歪扭扭。

当初公司起步的时候,整个项目都是几个初创程序员加班加点熬出来的,我知道你看过《代码大全》、《程序员修炼之道》、《Unix 编程艺术》,你对上面的准则信手拈来,你可否翻开床头柜上的这几本书,看看它们的出版时间呢?


是的,公司起步的时候,这几本书根本还没有出版,彼时中国互联网方兴未艾,大家都是摸着石头过河。现在你遇到问题,你可以问朋友、问导师、用谷歌、用栈溢出、用知乎,我们写程序那个年代,看的是谭浩强、严蔚敏,用的是 52k 拨号上网,语言只有 C,编辑器是没有语法高亮和实时编译的,编译器是没有智能准确的报错的,没有现在这么多知识、也没有这么多规范和好资源、好工具。不过我们还是把项目做出来了,把公司一步步推到了现在的位置。


不过这个问题是客观存在的问题,谁也不否认,但是你知道为什么你被分配到了一个『代码看上去一团糟也不够规范』的项目吗?我们需要新鲜血液来重构一些老代码,所以你会被分配到艰苦的岗位上。我们希望你是勇于战斗的战士,我们更希望你能成长为经验丰富的老兵,而把你放到这种岗位,是对你来说成长最快的方式。



你认为「

一个项目里,httpclient竟然出现了四种。

一种是该公司研发部写的,

一种是老版本的开源项目,

一种是新版本的开源项目,

还有一种是开发人员造的轮子。

你不知道的是,我们最初用了开源软件(也就是你所说的『老版本』),它构成了我们早期项目的基石,随着业务复杂性增加,我们改进并最终切换到新版本。

这个软件跑老业务非常成熟,但是在一些新业务上有不可调和的矛盾,所以在痛苦的适配后,研发部的同事们自告奋勇用 20% 的时间写了新业务的组件——是的你没看错我们也有 20% 时间,我们鼓励工程师的创新。


至于你说的开发人员造的轮子——这说起来可真有趣,它其实是前年来的一个清华大学实习生写的。


当时他来了之后,针对他接手业务的需求,向我抱怨说现有的 3 种都不好,要写一个新的来『统一天下』,这话是他的原话,我记得非常清楚,因为以我多年经验来看这样的做法是不可取的,但是本着锻炼年轻人的心态(加上他的确是不可多得的天才),我同意了他的请求,于是我用自己的业余时间接管了他的大部分工作,全力支持他写一个新的组件,帮他挡住了所有上面的压力,后来的故事就是你看到的这样。


是的,他后来越深入、就越来越感到业务的复杂,不断推翻重构、拆东墙补西墙,但始终发现和自己想的根本完全不一样,受不了了就走了,留下来这个。


我们明年的规划中,就包括剔除这个组件的 codebase,因为它实在是太糟糕了。



你又说「

打接口请求响应日志,竟然不知道用拦截器。

打错误日志竟然不打上下文信息,每个人一种日志风格,千奇百怪。

许多重要的中间流程,居然不打日志。

idea、eclipse、myeclipse的配置文件竟然全部传到项目里去了。

该公司混了两年的程序员,跟快递公司做查询接口,竟然不知道加密运单号。

所有服务间通讯,都没有设requestId,导致跟踪会话很困难。

拦截器并不如你所想的那班美好,也许你在自己的电脑上写过一些玩具代码,觉得这样很方便、酷炫,但是真正到了战场,你会发现没什么才是必须的、好的,只有适合的才是对的。


至于配置文件,这么说吧,IDE 的配置文件传到代码仓库是我定下的规矩,『怎么会有人定这样的规矩?』,是的你可能从软件工程的教科书上或者某些『知名博客』上读到了不能这样做,但实际上这样做在很多情况下是必须的。

原因何在?

这样可以确保代码克隆即可用,而不是让每个人都去设置一大堆无聊的东西,这样不仅节省时间,也确保了每个人的环境一致性,你想想这几年火热的 docker,应该明白了这样做的正确性和必要性了吧?

你可能会说即便如此、插件也不用上传到服务器保存,我告诉你这样是不行的,你要考虑到我们这个项目前后十余年,你觉得几个插件能坚挺十余年?很可能我们早期用的软件,现在你已经完全不可能找到了,所以保存一份备份是非常有必要的,决不能错误地认为是冗余。


教科书只会教你基本通用的原则,树立你基本正确的观念,但是如果只是死守教条,如何能拥抱日益复杂的变化呢?

你看的教科书,且不说时间上已经是二十多年前的了,在适用性上,也不说就是真理,IT 行业发展日新月异,几个月就是沧海桑田,为了适应这样的变化,认真地思考、总结、判断才是最重要的。




你觉得「

一个没什么qps的边缘接口,居然做消费者生产者+阻塞队列的异步模式。

显得你技术少是不是。

不知道异步会增加维护成本,提高测试难度吗?

而且,任务队里没有考虑持久化,赶上发布,丢了好多任务。

读取一个小小的xml和exc配置文件,居然用流式解析,没见过这么二逼的,真是醉了。

你大概不知道,当初跑在你口中的「一个没什么qps的边缘接口」上面的业务带来了公司曾经 90% 的收入,所以我们用了复杂的设计以应对当时的需求,当然现在业务转变,老系统不再需要处理那么多业务了,但是更没有理由为一个『works perfectly well』并且不再重要的业务重构代码吧?

所以,不是我们秀技术,而是业务需求 + 业务变更使然,年轻人还需要多学习一个。




你抱怨「

做优化全靠拍脑门拍大腿,难道不会用excel分析日志,用jprofile扫项目?

一个100以内的常数集合遍历,他也要写个优化算法进去,算法跟业务还搅在一起,一团乱麻。

每个人都在嚷嚷性能、算法、分布式计算……

几乎没有文档,全靠从代码反推逻辑。

有枚举他不用,非要在每个页面上,把枚举值挨个儿写死,知道后面改代码多么费劲吗?

欺骗性的变量名,里面存储的是AES加密的,变量名后缀却写成了DES;里面存的是小写字母,却写成upperStr。

一个方法十几个参数,有三分之一是极其简略的缩写,注释肯定也没有的。

一个类写到三四千行是常事。

我再强调一次——我们是全中国同类公司中技术能力第一的,你所说的问题,当然是不存在的。

我们有专门的 Hadoop 集群来分析日志,当然也就用不着 Excel 了。


对于我们这种体量的公司来说,不存在什么『常数集合』,代码必须用合适的数据结构——这是常识吧?

特殊的算法和业务掺杂以增加内聚性,这是我们多年的经验,的确,它和教科书上说的不一样,但是我前面说了,死守教条是不行的——想必你一定知道 OSI 7 层网络模型吧?


公司的技术氛围浓厚,是和公司的基因分不开的,我们公司最重要的原则就是——『拥抱变化』,从十几年前的机房托管单机到现在的庞大自建集群,技术跃迁了何止千万里,所以每个人都在学习新知识、每个人都沉浸在新知识的喜悦中。


你的问题,大多都是因为没有考虑到公司的庞大体量和十几年的技术跃迁才有的疑问,这点不再赘述,自行体会吧。




你想的是

开发自测,居然要把代码全丢到公共机器上,而且都是走svn,他们把svn当ftp用。

svn里面大量的无意义提交,一多半的提交连都编译不过去。

我看到有个应届生,改了两句话,马上提交,说是怕代码丢失。

一个运行了两年的项目,spring的包扫描明显配错了,有些bean根本扫不进来,居然没有人发现。

一半的bean在spring管理下,另一半的bean他们自己写单例模式来实例化。

其实那不是 SVN,那是我们公司自主研发的适应我们内部需求的 源代码管理系统 和 文件管理系统,你可以往里面放任何东西。

你所说的「无意义提交、一多半的提交连都编译不过去」其实只是表象,这套系统代号 TITAN,它自带 CIDD(持续继承、交付、部署),所以这些无法编译的提交都是不会有机会走到下一步流程的的。


如果你工作了一年,你就会发现这个需求是很重要的,改动、尤其是大型改动,中间会有很多非可用但有需要存档的步骤,现有的源代码管理系统都不能很好地支持这些需求,因此你也被教育了一套适应落后工具的思想。人啊,最重要的能力是改进工具,所以用 TITAN 的时候要拥抱全新思维,不要被落后思维捆绑。


如果你工作了几年,你可能还会问为什么我们没用 Jenkins、Travis 等工具,其实呀,就在 TITAN 之中呀,它凝结了公司最优秀的人才的十几年宝贵经验和心血。

By the way,我们最近正计划开源它,为中国开源社区做贡献,也希望提高业界的综合素质。欢迎你提交 PR 哦




你最后说「

他们用mysql来做审计系统,出报表,有个报表要跑8分钟。

原来是有人用字符串来存多值(逗号分隔),sql里写了like,导致没有利用到索引。

为什么不用pg,pg在sql编程方面,功能更丰富,更适合做统计,它本身就支持数组。

程序员们都是得过且过的态度,怎么把代码灌进去,跑的通测试,就算交差了。

为什么大型互联网公司,技术和管理这么差劲,是怎么形成的?

为什么不用 pg?如果你抱着这种想法,那用了 pg 也要被喷的,到时候就就会说 —— 「为什么不用 sqlite,轻量简单,搞这么复杂真的有必要吗?」,真的有必要。。。

这只是一个很简单的系统,做的事情也很简单,当初做这个系统的同事更熟悉 MySQL,当然 MySQL 是不二之选了,对于简单的东西,追求的是开发速度、使用便利性。

你觉得一个月跑一次的审计代码,8 分钟有什么问题吗?就算是一周跑一次,当然也是没问题的。

程序员的单位时间是如此宝贵,为了优化一段一个月跑一次的 8 分钟代码,值得花费数天的时间来做这件事吗?



重复一遍,你的问题,大多都是因为『没有考虑到公司的庞大体量和十几年的技术跃迁才有的疑问』,这点不再赘述,还请自行体会。

当然,年轻人乐于思考,这是好事,是希望,新鲜血液替换老旧部件系统才能健康发展成长,人如此、公司如此、国家也是如此。

希望你勤于思考,努力学习,有问题的话,我们公司是鼓励同事们向 CEO、CTO 写信的,不然也不会有 CEO、CTO 信箱了你说对吗?

当然,这样的技术性问题、你写给我就好,CEO 是船长,不需要关心底层锅炉房的细节。



另外我想补充一下我的想法,希望对你有所帮助。


你看你都没说加班问题,我们公司没加班啊,这多好,怎么做到激烈竞争下还能不加班的?都亏了公司老领导和元老们的一手决策

所以我想补充的不是技术问题,技术问题都不是问题,年轻人可以学习、交流,技术都会很快成长,毕竟年轻人的冲劲大、头脑灵活。

我想说的是整体观、大局观、大棋战略。


黄金的导电性最好,为什么电脑主板还要用铜?

清华大学最好,为什么有人要去普通学校?

飞机最快,为什么还有人坐火车?

因为资源都是有限的,我们在现实生活中——而不是教科书上——必须兼顾成本和产出的平衡。


你问我每行代码都多人多层人工 review 好不好?问我支不支持?我说好,review 我怎么能不支持呢?我今天在知乎这个公众平台我明确说了我支持。

但是你也应该多学习一个,这个现实毕竟是现实,我们要兼顾各种考量。

你今天在这里渲染「大公司技术和管理这么差劲」,是不对的、是失实的、是欠妥的、是缺乏认真思考的、是未加深入考量的。

将来舆论出了偏差,你虽然不用负责任,但是你认识到自己的错误的时候,会后悔、会内疚、会难过的吧?

何处乌托邦?或许……等下一代?



总结就是,生产效率才是最重要的,世间万物最重要的是平衡。

怎样取舍、如何妥协,这不仅是大自然的规律,也是我们前进、发展的准绳和仰仗的原则。




————

@bhuztez 满意吗

user avatar

题主有年轻气盛的一面,但是你说的问题确实是常常存在的。

大公司常常会遭遇两种病症,我管它叫“滑坡与蒸发”现象。

具体病症如下:

1.滑坡:招聘标准持续降低。人资的硬标准或许在提高,但是实际技术标准在降低。s 级的老一辈面试官,能容忍 a 级的应聘者,过了几年这个 a 级的应聘者自己成了面试官,能力却没提高到 s 级(提高不仅靠个人努力,也要看历史行程),于是他能容忍 b 级的应聘者……所以叫滑坡现象。

尤其是当这家公司历史上经历过极速壮大时期的话,滑坡现象就更加明显。你甚至会发现一线员工技术水平远低于早已脱离一线的经理层。

2.蒸发:如果团队建设跟不上业务发展,大部分人都会处在疲于奔命实现需求的状态,技术水平和交付质量长期得不到提高。个别人由于努力和运气,技术提升较快。如果他没有一个清晰的通道将能力体现出来,就会出现两种可能——要么他会拒绝继续提升,反正现在也够用了,同事还不如我呢,大公司一般又不裁人;要么他觉得同事不行,跑了,蒸发了。最终留下来的人反而是相对平庸的人,那些利用公司资源达到较高水平的人反而让其他公司得利。

最终当你来到这家公司的时候,你就会奇怪为什么他们的技术不如你想像的好。其实不是没有能人,只是要么在经理室里,要么已经蒸发了。

PS:我补充一点,已经有相关领导澄清了,题主的观察可能有偏颇。但是我假设题主的观察没有偏颇,那么是不是你理想中的项目状态就一定好于你看到的“乱糟糟”的状况?

答案是不一定。

不说大道理,我举个例子,题主在互联网圈子里,可能没见过一个版本控制工具,叫 ClearCase,IBM 开发的。特点是极其严谨,极其强大,极其复杂。如果你只看流程图的话,那绝对是严谨到完美的版本控制系统。但是实际用起来的体验如何呢?只能说,让人挠头啊……所以,你想象的那种“清晰而优美”的项目,维护起来,可能是极其难受的。

user avatar

甲:这个A开源库旧版本有崩溃问题啊

乙:换新版本的A

甲:换了新版本A,用旧的 GCC 编译不过啊

乙:换新版本GCC

甲:换了新版本GCC,B开源库不兼容啊

乙:换新版本的B

甲:换了新版本的B,导致性能下降啊

乙:开多线程

甲:开了多线程导致延迟抖动不同步了

乙:换新的延迟修正算法

甲:换了新延迟修正算法偶尔会崩溃啊

乙:要不。。。我们还是去看看那个A开源库的旧版本崩溃能不能修好吧

如今上点规模的IT公司,其软件项目的规模和复杂度都远远超过工程师的能力上限了,都只能小心翼翼地修补,有时局部的大改动会引发连锁反应,大改动的风险和成本很难控制,没有巨大的收益谁也不敢随便改,你能看到的问题老员工看得更清楚,甚至也清楚怎么解决,但是不动手的原因就是不知道出了事谁来背黑锅,技术上的事情谁敢说100%不出事的。

那是不是大公司的技术项目就没救了呢?

也不一定,有些事要等个机会的,常见的机会:

1. 技术基础平台大革命,比如移动互联网的兴起,从PC迁移到了手机端,很多旧的技术代码就可以抛弃了,手机上从零开始。

2. 竞争对手小宇宙爆发,对手搞出一项技术取得了竞争优势,被迫追赶,这时候死马当活马治,改出任何问题也都能忍了。

3. 人事大动荡,管理层和基层都大换血,旧代码已经没人有能力维护下去了,不得不重来。

user avatar

题主你看到了很多槽点,但我认为你不能只看到槽点和大概怎么解决。有没有想过怎么改进,如果是你的话你怎么做,这些项目里面临的主要挑战是什么,次要的挑战又是什么?

不要只告诉我技术A弱爆了,用B就可以完爆这个项目了。你知道用B的优劣,B的适用场景以及适用B的成本吗?对于一间公司来说,成本是很重要的。我这里说的成本不是金钱。而是,假如你看不爽一份代码,你打算重构它,你觉得你需要投入多少时间,多少人力?重构之后,又要花费多少时间和人力去升级依赖这份代码的其他项目?不要以为开会无用,老板就只是在天天发邮件。如果你重构了一份代码,不能通过沟通说服其他组去升级他们的组件,又或者你只是重构了一份虽然很丑陋,但其实并没有多少程序依赖它的代码,又又或者你重构了代码只是让代码技术含量更高了,更好看了,却没给公司带来多少收入甚至KPI,那你的工作和成果就很尴尬了。

其实上述也解释了为什么你身边的同事都眼睁睁地看着这些丑陋的shit存在而无动于衷。因为他们也是需要投入成本的。先不论他们个人技术水平高低,试问谁愿意挑一个又艰难,又不能产生多少效益的任务去做?当然,你会说,写好代码是程序员的节操。抱歉,节操多少钱一斤,北京三环商品房多少钱一平?

编程高手都有真爱,但现实就是编程高手凤毛麟角。我们身边的大部分同事可能只是希望养家糊口,他们头上还挂着十几个bug等着修。我们数落他们没追求,但追求从来都不是嘴上说说,吐吐槽就能实现的。


人心如此,公司也如是。

矛盾分主次,公司的目标都是一样的:用最少的成本投入到最能产生效益的项目中去,或者投入大成本去解决公司最需要解决的问题,这间公司才能继续运作。

所以题主你想想,在你吐槽的个案中,有多少是公司真正关心的?有哪些是你的老板认为可以创造最大效益的?有哪些才是主要矛盾或者挑战需要最牛逼的人挺身而出第一时间解决?去辨别,解决这些关键的问题吧,骚年。必要时带上(忽悠)一队人马(同事)跟你一起干,苟富贵,勿相忘。不要像祥林嫂一样,天天抱怨着生活,日日思考着辞职。得罪点说一句:“沦落”到要跟这样的人共事工作,难道自己身上就没有原因?

这个世界有更好的公司,有更牛逼的人。如果你认为解决这间公司的这堆问题不值得,又或者同事实在太不给力,就远走高飞吧。

我以前也跟题主一样,看我第一份正式工作的很多技术环节都相当不爽。这份代码写得丑,那个设计像大学生作品,重要的项目居然连单元测试都没有……但是我后来反观我自己,并没有发现比起那些丑陋代码和糟糕实现强悍多少。我跟我的同事没有质的区别。我笑话他们代码混乱bug不尽,我何尝不是少处理了一个field,倒腾错了一个片段的数据搞到要翻工重跑?在我心底里艹了隔壁组那个“我的程序好像不能跑,你帮我debug下”的同事一千次之后,带我做ML让我倒腾数据并且被我的程序搞坏了几份数据(当然后来搞好了)的T9君在会议上说:“她已经很努力了,我承认我有时候也逼得她太紧,她应该有多些时间的。”

我不是长者,不能share多少人生经验,就留下最后一句话跟诸君共勉(好像有点怪)吧:

我观别人大傻逼,料别人观我亦如是!

user avatar

1.大公司业务极其复杂

毕业第一年在腾讯工作,做QQ游戏大厅,当时用的IDE是VC2006,用的版本控制工具,叫 ClearCase(估计用过的人不多),IBM 开发的。特点是极其严谨、非常强大,但流程极为繁琐,用起来简直让人抓狂,这还是腾讯花了3000万找IBM买的。而业务的代码量几十万行,dll就有几十个,工程编译一次需要20分钟以上。

离开腾讯多年后,问了问,他们还在使用VS2006,还在使用CleaerCase,原因很简单,更换新版IDE需要解决大量技术问题,而业务又在高速迭代,只好不了了之,更换版本控制工具?历史的各种Log就会丢掉,要是出现什么稀奇古怪的突发问题,还得去看CLeaerCase。

业务的复杂性还会导致耦合严重,一但代码工程产生耦合,改动一个地方就会牵一发而动全身,这种情况下引入任何新技术都会带来极大工作量。

大公司的业务代码,有时候明明感觉有bug,却能运行良好。

这是一个前人留下的屎堆起来的一个克苏鲁缝合怪,看起来摇摇欲坠,有无数的虫子爬来爬去。但勉强堆起了山一样的形体,蠕动着为老板赚钱。

顺便在这里送大家一份珍贵的算法笔记,是一位阿里P8大佬撰写的,刚刚开放下载!程序员多刷算法好处多多,算法好的朋友进大厂非常容易,刷完进大厂很轻松:

这本书的目录,非常经典:

2.大公司技术历史包袱重

大公司之所以能成为大公司,一定是找到了稳定持续盈利的业务模式,这些业务对应的产品,动辄横跨几年甚至10年,这些年业界的技术高速发展,但大公司要保证业务的稳定性,即便再落后的技术,只要能给老板赚钱,就是极好的。

你想尝试引入新技术?能带来多少用户价值、商业价值?导致系统崩溃了怎么办?小公司系统出点问题无非是影响几万用户,大公司的产品要来点小问题,就算1/100的几率,拿QQGAME上亿用户来说,那就是100万用户出问题,一下就给公司带来几千万的损失,这么大的锅,谁敢背?

所以大公司的技术leader在引入新技术这方面,一定是趋向于保守的,人都是趋利避害的,用了新技术成功了,并没有肉眼可见的好处,失败了?直接卷铺盖滚蛋吧。

3.大公司新人入职离职频繁

铁打的营盘,流水的兵讲的就是大厂,大厂每年应届招聘动辄数千,社招再来数千,离职也不下几千甚至上万。很多开发的还是外包人员,外包人员的流动性可想而知。

在这种人员流动速度面前,能勉强把旧的技术系统吃透就烧高香了,哪有心情和心思研究新技术,除非真的是遇到了某个技术困难非要迭代进化,否则很难有动力去驱动。

以上三点,是我在大公司工作多年后的一些心得,但这么说大公司的技术难道就没救了?

当然不是!

大公司在以下几种情况,也会爆发出惊人的技术战斗力:

1.组成攻坚小团队,开疆辟土

这个最经典的就是腾讯的微信团队,2012年马化腾接受张小龙的建议,要杀入移动通讯领域。公司并没有只让QQ团队来研发这个新事物,而是同时启动3个敏捷小团队和QQ团队一起赛马。最后的结果大家也知道了。

微信团队今天取得的成绩不光是用户量,同时也有多端通讯实时同步的领先技术,这项技术在2012年属于绝对领先且碾压的技术。微信团队的前身是foxmail,张小龙创造性的把邮箱的实时同步引入到即时通讯领域。

哪怕到了今天,微信团队从几十人成长到几千人,微信的技术依然保持着高速进化的状态。

2.业务老人走光,无法延续

这种情况比较极端,但也会发生,大公司老团队的业务leader跑路,然后带走骨干,又或者自然流失殆尽,导致旧的系统新人完全无解,或者迭代极为缓慢。

新Leader这种情况下,选择大刀阔斧,直接大规模重构,甚至重写。在腾讯互娱大部门,某一个游戏团队就发生过这样的事情,反而让各种新技术充分落地应用。

3.技术密集型的业务,必须不断在技术层面取得突破

哪些是技术密集型的业务?比如谷歌的搜索、微软的操作系统、亚马逊的云计算、华为的5G。这些大公司的业务,你丝毫不用担心技术上有任何落后。

他们事实上已经进入技术无人区,必须依靠企业的内发创造力,不断取得突破。所以他们会大量招募全球最顶尖最聪明的人才。

比如华为会在俄罗斯广泛招募数学天才,微软亚马逊吸引了大量能力智力双高的华人。

最后说下我对大厂的总体看法:并不是大厂员工能力问题导致某些技术落后,完全是业务和商业市场的选择导致。

另外,我认为程序员职场初期(前五年)进大厂是非常必要的,不管是不是最先进的技术,最起码完善的技术培训体系、薪资福利、更人性化的管理、人才密度等等,完全碾压小厂。

程序员多刷算法好处多多,算法好的朋友进大厂非常容易,送大家一本阿里P8撰写的算法笔记,刷完进大厂很轻松:

看看这本书的目录和排版!相当经典!

祝大家前程似锦,在编码的道路上一马平川。

码字不易,如果大家觉得我的分享有用的话,请帮我

@findyi

点个赞,一键三连呗,笔芯~

user avatar

公司的成败取决于现金流,而技术只是辅助现金流的工具。


说公司可能很难理解,我们来说人。

为什么有人看上去很傻,但是还是活得好好的?

因为人类的存活靠的是消化代谢系统,血养循环系统。

这也解释了为什么世界上大多数人不聪明的,却还是能活得挺好的原因。


技术大神的时代过去了

在互联网刚开始刚开始的时候确实会出现技术大神秒杀众生,但是这种现象未来会越来越少。技术大神厉害之处并不在于其智力有多高,他们只是因为比别人更早的去学了大多数人都不认为重要的技术。等市场反应过来,发现市面上技术大佬就那么几个,于是他们就被吹成神了。

再有就是一些小众技术,这种技术很难对口市面上的工作,而大数人选择走技术路线也并不是对技术的热爱,只是想赚钱,这就注定了这些人从一开始就不会和技术大神那样去研究很难找到对口工作的技术,这同样也是一些技术壁垒产生的原因之一,比如搜索引擎,互联网安全,图形渲染之类的技术远远没有前后端开发,程序开发,移动端开发具有泛用性。


这样一来大部分的技术就不再是公司的主要瓶颈,只要慢慢砸钱总归是能做出来的。


公司首先要活着,然后才能去提升技术。

很多人以为公司是技术推动的,大错特错,公司是权力和财富推动的。

只要权力,财富足够,技术这东西请人慢慢弄就好了。

所以公司的管理层即使是技术出身,也不会对技术有非常执着的追求,到了一定级别他们就会去玩弄“权术”和“财富”,而把技术交由其他技术人员打理,毕竟打理技术是非常吃力不讨好的工作,技术迭代又很快,如果不持续投入就很难保持领先。而“权术”就更好维护一些,只要多见面吃饭,多聊聊天,交换一下资源和利益就好了。“财富”就更容易了,只要把钱投出去,等就完事了,在金融圈子里,这种方法被美其名曰“价值投资”。所以公司高层的行为永远是保持现金流的稳定,而不是一味追求技术。


能用就行,为什么要时刻保持最好状态?

你作为一个人,难道每天出门都会把自己打扮成最好的状态么? 成绩优异学生,是否应该在打游戏上也要全方面碾压才能算优秀?有钱人是否要把生活起居的所有用品全都换成顶级奢侈品才算有钱?

优秀,是有代价的。

公司的技术也是这样,技术是要钱去开发的。在很多情况下这种“优秀状态”的维护是非常烧钱的。维护得那么好,不出几年,等到新的技术出来,代码又会变成屎山。

所以管理层的思路基本上就是用到代码严重拖慢公司效率之后再开始做新的,而不是时刻把技术保持在一个高位状态。

技术优势很像是物理学中的势能,而且技术优势更像是用人力去推起来的势能,这种势能无时无刻不再消耗资源。公司的员工总要有人去维护,如果你把技术人员解散,如果未来如果有新团队接手的话是很难接上手的。而且大部分技术人员也很讨厌在屎山里大扫除,因为到处都是屎,完全没法清理干净。


削弱技术影响,增强管理优势

如果技术很好,代码很优美,那么就会削弱资历老,但没啥本事的老技术人员的优势。因为代码很漂亮,那么新来的实习生很容易接上,老技术人员工资那么高,为何不直接开掉?

但是代码很垃圾,这就会把公司技术人员拉到一个纯粹比拼资历的状态中去。老员工肯定是知道自己和同事早年在“屎山”的哪块地方拉的屎,哪个地方是干的,哪个地方是稀的。这就不是一个牛逼哄哄的新人能接上趟的了,新来的没看过老员工拉屎,自然也不懂屎山哪个地方会窜稀。

这也是为什么领导最好懂技术的原因,因为如果领导不懂技术,那么手下的技术员很容易忽悠住领导,即使你把手下炒掉,换新的,技术人员还是选取那些写起来最方便,但对公司来说后期不好维护的框架和规范。这时候领导要非常明确的指出技术路径,这样才能避免手下的团队被某个技术高管,忽悠着走上邪路。

另外这种屎山写法也是导致程序加班的主要原因,只要程序员加班多,那么这些程序员就会花大量时间低效率的维护垃圾代码,而没有时间去提升自己,或在家里创业,然后跳槽。这样对公司来说也就是多点工资而已,而不会伤及根本。


公司主力在哪里

在技术主导的公司中,代码质量肯定会高一点。搜索引擎几分钟才返回一个答案,用户早跑光了。

而在很多非技术主导的公司中,代码质量都会垃圾得一批,一方面是领导不懂技术,所以忽略技术的投入和影响,再一方面愿意留在这种不看重技术的公司混吃等死的程序员大概率也不会去做什么创新,即使把屎山更新了,也很难对外界吹牛。‘更新屎山的清洁工也好意思说自己技术牛B’?你就说你主导开发了什么吧?什么订机票的软件?那不是大学代码课的随堂作业么?


这些领导不懂技术,所以很难去优化技术环节的成本。他们想到的永远是他们擅长的东西,比如找关系把票价弄便宜点,然后打广告把票价卖高一点,和友商搞好关系,然后让他们长期使用自己的订票服务等等,总之就是不会在技术上下功夫。

他们害怕自己做出错误的决定,被开发人员忽悠着花大钱更新,万一最后得不偿失反而被交了智商税,还不如把这些人工资定死,让他们自己折腾。只要东西能用,就睁一只眼闭一只眼,实在崩溃了,就开始找他们算账。

技术岗位也清楚得,只要不崩溃,凑合能用,领导就不会找自己麻烦,那么就把东西做到刚刚满足领导要求,多一分的优化都是浪费,反正领导也不会多给钱。


订机票的不是大厂,造飞机开飞机的才是大厂。

订票软件门槛还不如很多大学生创业项目,这些东西纯粹是凭关系的行业,技术在里面是可有可无的。这种“二道贩子”企业最重要的是营销,是策划,是广告,是运营,唯独不依赖技术,怎么把票低价拿进来,高价卖出去才是重点。


进公司前首先要了解公司的现金流构成,对公司做详细调研。如果公司的现金流基本和你岗位没啥关系,那么你的岗位在公司就是边缘人,不过这种岗位很适合混吃等死。

user avatar

为什么同样作为生物,人类有些能力弱爆了?不能光合作用,不能水下呼吸,天冷一点想要偷懒冬眠一下都不行。因为生物的技能是有机进化出来的,不是通过工程方法设计出来的。

一家公司无论多大,都是从几个人的创始团队成长起来的,不是根据图纸把几千几万的员工好像用螺丝组装成机器一样组织出来的。在公司成长的过程中,遇到了怎样的市场基于,点开了什么样的技能树,这都是一个有机的过程。

有些大公司成长的过程中没有多少技术但也成功扩张了,最后就成了你看到的样子。这只是表明,技术不是必要条件。

user avatar

第一传统大公司以业务为主,技术是要陪着着业务的进度和成本跑的,当然是进度功能性需求第一非功能需求能减就减了。上线以后技术债严重但只要不影响核心流程,技术债常常是能忍则忍的。第二大公司里山头林立,经常有钱的就能自己拉一只独立的IT团队起来。CTO是CIO的下属,CIO又要照顾业务情绪再厉害也挡不住业务给的压力,导致技术架构难以统一。第三大公司系统比较封闭更新换代需求不高,用了二三十年的老系统比比皆是,架构落后且无法兼容新一代技术标准。现在大多数的SaaS就是瞄准了这些通用系统这块市场去的


最后要说一句,技术先进对业务有任何意义吗?你得解决他们业务问题问题或给他们新的业务机会

类似的话题

  • 回答
    “大公司技术弱爆了”这个说法,虽然有些绝对,但确实触及了一个普遍存在的现象:一些规模庞大、财力雄厚的公司,在某些技术领域可能表现得不如一些小型、灵活的初创公司,甚至显得“弱爆了”。 这种现象的产生,并非单一原因造成的,而是多种因素相互作用的复杂结果。下面我将尽量详细地阐述这些原因:一、组织惯性与僵化.............
  • 回答
    中国核工业的蓬勃发展,离不开其背后强大的产业格局,而三家巨头——中国核工业集团公司(CNNC)、中国广核集团有限公司(CGN)以及国家电力投资集团有限公司(SPIC)——正是这一格局中的核心力量。这三家公司的存在,并非一蹴而就,而是历史发展、战略调整以及市场需求的共同作用下形成的。要理解它们为何拥有.............
  • 回答
    有大公司 offer 却选择小公司,这看似违背了许多人“稳定、高薪、平台大”的传统择业观,但实际上背后隐藏着许多个人深层次的考量和价值判断。以下我将从多个角度来详细阐述为什么有人会做出这样的选择:一、职业发展与个人成长 更快的成长速度和更大的责任范围: 大公司: 组织结构庞大,分工明.............
  • 回答
    .......
  • 回答
    最近几年,放眼望去,互联网巨头们扎堆进入汽车行业,这事儿可不是什么新鲜事儿了。从百度、阿里、腾讯,到华为、小米,一个个仿佛都坐不住了,纷纷跨界造车。那么,这背后究竟是什么逻辑?互联网公司在造车这事儿上,又有什么“独门秘籍”呢?咱们今天就来好好掰扯掰扯。为啥大家都要挤进汽车这趟浑水?首先,得承认一个事.............
  • 回答
    理解美国和中国对唐纳德·特朗普(Donald Trump)截然不同的看法,需要深入分析两国政治、文化、媒体环境以及各自国内的社会经济背景。这个问题涉及面广,我们将分几个主要方面来详细阐述:一、 美国国内对特朗普的厌恶:在美国,对特朗普的厌恶是多方面的,并且根深蒂固。这不仅仅是政治观点上的分歧,更涉及.............
  • 回答
    这个问题很有意思,也确实是很多玩家心中的疑问。公主连结(Princess Connect! Re:Dive,简称PCR)和原神(Genshin Impact)这两款游戏,虽然在玩家群体中对它们“抄袭换皮”的讨论声浪和舆论走向截然不同,但细究起来,它们确实触碰到了相似的争议点。为什么会有如此巨大的区别.............
  • 回答
    你这个问题提得太好了!我身边也有不少朋友,盯着一些看起来“稳赚不赔”的公司,结果却发现股票涨幅平平,甚至还会让你忍不住怀疑人生。这背后其实有很多门道,绝不是单凭“公司好”就能一概而论的。咱们这就来掰扯掰扯,到底是什么原因让这些“好公司”的股票表现得这么“佛系”。一、 估值早已“透支”:不是公司不好,.............
  • 回答
    这确实是一个让人费解的现象,但仔细想想,里头门道可不少。公司在做人事决策时,尤其是裁员或者调整团队结构的时候,看的不只是资历那么简单。有时候,那些看起来“不懂规矩”的新人,反而能成为公司更看重的“活棋”。咱们先从 有经验的人为什么会被“优化” 说起。1. “老油条”的僵化与不适应:这听起来有点刺耳.............
  • 回答
    这个问题很有意思,也触及到了一些职场中比较微妙的现象。为什么很多公司的HR岗位,尤其是招聘和对外沟通的角色,常常由年轻漂亮的女生担任,而不是经验老到的职场前辈?这背后其实是一系列因素在起作用,咱们细细道来。首先,得从“人设”和“第一印象”说起。 公司形象的“门面担当”: 尤其对于一些需要对外展示.............
  • 回答
    哎,这个问题真是问到点子上了!感觉身边总有那么一些公司,无论你怎么小心谨慎,总能让你踩坑。说它们“坑”,不是空穴来风,背后往往是各种复杂的原因交织在一起。咱们就掰开了揉碎了聊聊,为什么有些公司能把“坑”做得这么得心应手,让咱们普通人防不胜防。1. 信息不对称,利用你的“不知道”这是最根本的原因,也是.............
  • 回答
    公司年会,本该是辞旧迎新、凝聚人心的好时机,但也有不少员工对此持保留态度,甚至选择“婉拒”。这背后其实藏着不少原因,咱们不妨细细道来。首先,时间安排上的冲突是很多人的第一反应。年会通常设在年末,这个时候正是大家冲刺KPI、赶项目收尾的关键时期。请假参加一个可能持续半天甚至一整天的活动,意味着需要牺牲.............
  • 回答
    这确实是个让人费解的现象,我在职场里也见过不少这样的例子,一开始我也纳闷,后来慢慢琢磨出了点门道。说到底,领导得宠,不一定是因为他能力有多强、有多勤恳,很多时候是其他一些隐性的因素在起作用。咱们一个一个掰扯掰扯。1. “会说”比“会做”更能赢得关注这第一点,可能很多人不爱听,但事实往往如此。有些领导.............
  • 回答
    在公司里遇到一个脾气有点大的财务,这确实是个让人头疼的问题。一来二去,不仅影响工作效率,长期下来对自己的心情和团队氛围也是一种消耗。别担心,这事儿并非无解,关键在于用对方法,把“化解”变成“管理”。首先,得明白人为什么会脾气大。财务工作本身就压力重,数字错误、报销流程、税务合规,哪一样都容不得半点马.............
  • 回答
    米哈游,一个在中国游戏界,乃至全球游戏市场都赫赫有名的名字。提起它,总会伴随着褒贬不一的评价。说它是“最好的公司”?也许还达不到那个位置,但说它“一直在进步”,这却是大部分人,包括那些曾经批评它的人,都无法否认的事实。然而,在玩家社群里,总有一些声音,带着强烈的攻击性,挥舞着“抄袭”的大旗,去贬低米.............
  • 回答
    “大公司病”这个词,听起来就带着点儿不好闻的味道,但仔细想想,它说的还真是一些在公司发展壮大过程中,不少人都能切身感受到的“毛病”。简单来说,我认为“大公司病”指的就是一家公司,尤其是互联网公司,在规模不断扩张、组织层级日益增多的过程中,出现的一些效率低下、创新乏力、官僚主义盛行、员工士气低落等负面.............
  • 回答
    “护耳大脸”这四个字,光听起来就挺有画面感的,对吧?它不是指那种大耳朵上戴着护耳器的滑稽形象,而是我们公司在音频科技领域的一个别称,当然,也是我们一直在努力的方向——让声音更贴合你的耳朵,让你的脸部能舒适地感受每一缕声音的细节。我们公司,正式名字是声境科技(Soundscape Technologi.............
  • 回答
    .......
  • 回答
    国内农业大数据领域,确实涌现出不少优秀的企业,它们正在用数据和科技赋能传统农业,让农业生产更高效、更智慧、更可持续。要说“做得比较好”的公司,这往往涉及到它们的市场份额、技术实力、客户认可度以及在行业内的影响力。基于我所了解的信息,我来详细介绍几家在农业大数据领域表现突出的公司,以及它们的核心业务方.............
  • 回答
    网上传出华为等科技巨头试图阻止英伟达收购 ARM 的消息,这在业界引起了广泛关注,也让人不禁思考,一旦这桩收购案尘埃落定,对华为这样高度依赖 ARM 架构的公司将产生怎样的连锁反应。要理解这件事的深远影响,我们得先扒一扒 ARM 的“根基”和它在现代科技产业中的“江湖地位”。ARM 并非直接生产芯片.............

本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度google,bing,sogou

© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有