世界上没有技术驱动型公司

面试精选集,快快前往领取吧!offer.liangsonghua.me/。关注微信公众号:松花皮蛋的黑板报,获取更多精彩!
程序员


世界上没有技术驱动型公司,不论 Google、Facebook,仍是腾讯、阿里,都不是技术驱动型公司。由于技术不是源头,需求才是。面试


所以一切技术问题,都要服从产品交付和市场反馈。因此,任何公司,都不可能以技术去驱动自身。人能够以技术驱动本身进步,但公司不行。一家公司能够以技术切入某个市场,但若是它想生存下去,就必定不能以技术为导向,坚持以技术为导向的公司的生命力为零,其下场有两个:破产或者在破产以前被收购。若是你真的很痴迷钻研技术,请读研读博最后留校或者进研究院让国家用纳税人的钱养你。
小程序

客观看待加班问题


资本富集的地方,每一个人都得加班。加班的本质,是人跟着机器跑、人跟着钱跑。更为本质地说,资本富集的地方,人做为劳动力,也是资本的一种。即,人是资本而不是人自己。设计模式

资本的运转是不能停的,由于停一下损失的钱太多了,中国、外国,都同样。知道发达国家为何产业工人不加班吗?由于制造业已经不是这些国家主要创造财富的领域了。发达国家资本富集的地方是金融行业,因此西方国家的金融狗同样加班。缓存

劳动法?加班费?都不存在的。劳动法和加班费只有在资本离开这个市场后才能给你保证。通常公司的策略是:付给你高于其余行业的薪水、换取你“自愿”加班。不想加班的同窗们,大家能够去考公务员或者去欧洲作 IT,我保证你不加班、不但不用加班,你甚至会闲出病。服务器

多读书,但别迷信技术


IT 是工科,不是理科,和 IT 行业类似度最高的行业是盖楼房。真的,类似度至关惊人。微信

IT 领域最重要的是经验而不是你有多聪明,不聪明的人或者更准确地说不适合作这个行业的人,大学毕业后就改行了。记住:你作得好很差,不取决于你是否聪明,而取决于你是否愿意不断读书不断学习和不断积累。所以,若是你打算投身这个行业而你还在学校,请抓紧一切时间多读书。架构

公司是你创造财富的地方,公司不是学校。你能够在工做中学习,但你不能放下工做而后去学习,除非你的工做已经作完了。app

能大规模商用的技术,都不须要智商,不然这种技术就不可能规模化。某些程序员们,请中止大家的蜜汁自信。机器学习

技术栈,一旦确立了,就很难改了。一个技术人员是如此,一家公司也是如此。根本缘由是:每个栈的 size 都太深了…就像是 ulimit -s unlimited 过同样。

一个程序员,应该花 80% 的时间作代码设计、画 UML 图、画时序图,20% 的时间写 code 和 debug;菜鸟程序员的这个比例刚好是反的。一句话,不论这个需求有多紧急,你都必定要“想好再动手”;“想好”的标志就是设计文档写好了;文档一旦写好,写代码就是纯粹的无脑工做。

写文档的目的是让你在 coding 的时候,不须要停下来思考更不须要推倒重来。若是没有文档也能够作到这一点,你固然能够不写文档同时思考下本身水平这么高是否是能够要求升职加薪了……或者,你是否是在作无聊的 if else 编码工做?

要关注说烂了的软技能


英语很重要。可否使用英语查阅资料,是区分技术人员水平的重要指示之一。寄但愿于“有人早晚会翻译成中文”的人是愚蠢的、是会被淘汰的。

要有分享精神,不要担忧你知道的东西告诉了别人你就没价值了。你最大的价值在于你知道那些东西的过程,而不是那些东西自己。你愿意和别人分享别人天然也会愿意和你分享,最终达到 1+1 大于 2 的效果。不分享,就像一个失去了互联网的程序员,试问他还能创造多少价值?恐怕他连平常工做都没法展开了。持有“我把别人知道的都学会、我把本身知道的都藏起来别让别人学去”想法的人,实际上是默认全世界只有你聪明别人都是傻瓜,这样的人,在信息传输成本高的时代,能够活下去,可是在今天这个时代,他们的路会越走越窄最后会本身走入死胡同。固然,若是你真的知道了了不起的黑科技,那就请你保护好本身的知识产权而后本身开公司玩吧。

工做要有热情。智商决定你的起点,情商决定你能走多远爬多高;混职场,靠的是情商。情商高就是:别人愿意和你一块儿工做、你有问题的时候别人愿意帮你。智商有时候能够稍微弥补一下情商但不起决定性的做用。

如何让本身变得不可替代?


现代管理学的精髓,就是让每一个人(包括老板本人)都变得可替代。若是你以为本身不可替代,要么是你的错觉,要么是你在一家管理很是原始的、风雨飘摇立刻要完蛋的公司。

怎样让程序员变得不可替代?三个字:写文档。不肯意写文档的程序员,应该马上立刻绝不犹豫地开掉。程序员工做创造的价值,至少一半是经过文档体现出来才对。“一个项目换一我的就要让项目大地震一下、解决 bug 换一我的就不行由于只有老人知道要改哪一行的哪一个关键字”,这不说明这个项目所涉及的技术有多复杂、不说明这个老人是什么技术大牛,而只说明这个项目的项目经理是蠢货,由于这个项目已经失控了。

文档不是事无巨细的流水帐,写文档以及组织文档是须要智商的、是须要架构师去设计的。美国的航天飞机那么复杂,可是在飞行员手里的手册也就那么多,而这个手册能够在航天飞机出问题的时候协助飞行员快速定位绝大多数问题。

不可替代的打工者只有一种:以中高层领导的身份跟完了一个项目并且这个项目正处于大红大紫的阶段,公司为了防止你跳槽到竞争对手那里,愿意付给你薪水养着你每天在办公室喝茶。只要项目一直红着,公司就愿意一直养着你。

文档的做用


给正在 Coding 的本身看;给几个月后已经忘记这个模块当初是怎么开发的本身看;给要接手本身工做的新人看;给周边有关联开发任务的同事看;给领导等有关人员看……这是产品出 bug 的时候用来和别人怼的武器。若是没有文档,这些工做量都会成倍增加。

代码再精简再直观,也不可能有人类语言直观,谁以为本身厉害到读代码和读人类语言写的文档速度同样快,那我给你一个我上大学时候写的小程序,麻烦你读一下代码,看看你多长时间能够看明白。

这段代码自己并不复杂,应该说很是简单,可是没有文档……读读看吧。简而言之,文档,就像盖楼房的设计图,没有图纸,你是不能开始搬砖的。

  • 领导有没有给你看需求分析文档?有没有拿着需求分析文档给你宣讲你要作什么?没有?不干活。

  • 测试的同事有没有给你看测试用例文档?有没有给你宣讲?没有?不干活。

  • 你本身明白领导的意图了吗?明白测试同事的意图了吗?想明白后,开始想本身要开发的模块里的各个功能模块之间的关系,能够画时序图。

  • 时序图画完了,看看是否有(可能)频繁变化的模块 / 需求,若是有,请务必使用一些设计模式,若是要用设计模式,请务必画 UML 类图,若是没有频繁变化的模块 / 需求,请必定不要用设计模式。

  • 在一个功能模块中,有没有逻辑比较复杂的地方,若是有,请画流程图。

  • 模块和模块之间有没有须要明确的协议?若是有,请把协议写出来。

上面这一段话,就是你要写的文档,这个文档的读者主要是你,在你的模块出问题以前,别人一般不会读这个文档(不排除你的领导会要求看你这个文档)。若是你既不须要时序图又不须要类图又没什么协议须要明确,那么,你就能够不写这个文档。另外,若是这个文档写得好,你的代码是不须要任何注释的。

技术驱动是个伪命题?

若是一家公司打着“咱们是技术驱动型公司”的名号在招人,我劝你必定要想好考察好,再决定是否去这家公司。

为何呢?由于我知道他的那句“技术驱动”很吸引你,你想学东西,可是对小公司来讲,它最大的任务是活下去,而后才是其余。我不是说小公司学不到东西,我只是说小公司很难很难作到真正的技术驱动。有人坚持认为微软这种公司是技术驱动,但微软从没大张旗鼓地说本身是“技术驱动”公司,并以此忽悠新人。

以华为为例。华为成功的内在缘由,早就敲锣打鼓地告诉全世界了:以客户为中心,以奋斗者为本,长期艰苦奋斗,坚持自我批判。这四句话,没一句是直接和技术相关的。

这里我先特别声明一下,我不是说,技术人员在华为就不会搞技术、不会提高本身的技术水平、华为的技术水平差。我毫不是这个意思。

华为的技术,不须要我多说,全世界的人都是有目共睹的,华为公司的技术专利数就摆在那里,那是谁也抹杀不了的,华为公司里的技术大牛多了去了。但在这里,我要说的仍是第一段的意思:一我的能够以技术驱动,但一家公司不行。

华为公司的核心理念,本质就是“成就客户”,你把客户成就了,你就把本身成就了,华为不是先成就本身再去成就客户的公司。你去华为工做,你能够以技术驱动本身,但华为不能这样作。

这一点和微软与 IBM 的合做极其类似:IBM 说,大家微软如今搞的东西我愿意用,可是我须要大家给我搞个操做系统,这样咱们才能继续合做。而后微软怎么作的呢?它立刻购买了另一家公司搞的 DOS 操做系统,而后直接受权给 IBM 使用。

这里面有四个问题值得思考:

  1. 为何那家开发 DOS 的公司没能直接和 IBM 合做?

  2. 微软购买 DOS 系统的钱哪里来的?

  3. 微软为何不本身开发操做系统?

  4. 技术在前三个问题中的角色和做用是什么?

至于有人说 Intel 是技术驱动公司,我建议你们能够去了解一下 Intel 为何放弃了手机市场:重点关注 Intel 决定放弃手机市场的缘由,你就会发现,这个缘由的本质,就是一种技术情节的产物。

Intel 放弃手机市场与华为决定进军手机市场是大相径庭的。华为原本是作基站、路由器和交换机的,这是它的主营业务。

那么华为为何决定进入手机市场?是什么缘由驱使华为在没有任何技术积累的前提下进入手机市场?以致于最初华为的手机被华为员工戏称为“暖手宝”,倒贴钱都没人愿意用,而如今却如此成功?

因此,我仍是那个观点:世界上没有技术驱动型公司。

我本人就是程序员,我一直都以技术在驱动本身,努力提高本身的技术水平。可是我仍是要说:世界上没有技术驱动型公司。

  • 一个新的 team 要开发一款软件,它首先要解决的问题,是在产品 1.0 开发出来而且赚到钱以前这个 team 的经费。

  • 其次,它要提早找好产品的客户群和可能存在的销售渠道,而且作完相应的工做。

  • 再次,它要作产品规划,如何时出 1.0 版本的产品、哪一个模块开发大概要多久、什么类型的问题能够暂时搁置、什么类型的问题不能搁置、要组织公关组公关等(全是项目管理相关内容,和技术没有直接关系)。

  • 最后,进入产品开发阶段。一旦进入产品开发,就像工厂的流水线同样,是不可能出现什么致使产品开发进行不下去的技术难点的(不然技术 leader 就是白痴,这种产品在头脑风暴阶段就应该被拍死才对)。

因此,“指望出现决定产品生死的技术难点,而后本身 nb 闪闪地搞定”这种事情,是不可能发生的。同时,在开发过程当中,不免出现各类意料以外的 bug,好比,你负责的模块出现了三个 bug,其中一个是必现问题,且直接影响功能实现,那这是必定要搞定的,若是你搞不定,team 会找其余老手和你一块儿攻关。

攻关结果有两种,一种是 bug 解决了,可是不知道为何;另外一种是 bug 解决了也知道了是为何。

对于第一种状况,team 是不会为了找到缘由而让你潜心研究几个月的,为何?由于你还有后续工做要完成,而这个 bug 已经解决了,不影响用户使用了。

何时才有可能让你继续跟进这个问题呢?1.0 版本的产品市场反馈符合预期,且公司决定要继续投入 2.0 版本 ——只有这个条件知足,你才有可能继续跟进这个问题,为何是有可能呢?

由于这个 bug 已经不影响客户使用了,不必投入人力去研究了,你若是花几个月的时间去找这个 bug 的缘由,那么请问:2.0 版本的工做谁作?

在不少项目中,相似这种“问题解决了可是不知道缘由”的 bug,是比较常见的,不少时候,直到这个产品生命周期结束,这些 bug 的缘由都没有找到。所以,“指望碰到神秘 bug,而后本身潜心研究几个月,终于把缘由找到”这种事情,不少时候是不存在的。

接着上面的“三个 bug”继续:另外两个 bug,是几率发生且发生几率很低。

这个时候若是工期比较赶,公司会想办法绕过这两个 bug,好比定时重启服务器、定时清理缓存等(这些方法一般能够绕开低几率 bug),不会给你“潜心研究三个月而后把 bug 解决”的机会的。

何时才有可能让你继续研究这两个 bug 呢?和第一个 bug 同样,只有后续继续开发,才有可能让你继续跟进。

如今,请各位再从新品味一下“技术驱动”这个词。到底什么是技术驱动?

其实这个词真正的含义就是:咱们公司效益很好,能养活 nb 的技术团队,因此产品能不断迭代演进开发,随着产品的不断迭代,技术人员有可能会遇到一些其余公司遇不到的问题。

因此,若是一家新成立的小公司说本身是技术驱动的……连 1.0 版本的产品都没有,就敢说本身是技术驱动?你信吗?无论你信不信,反正我不信。

简而言之,“技术驱动”的同义词就是“咱们公司颇有钱”+“咱们公司不是炒股炒房而是作产品的公司”。

至于为何不直接这么说呢?这是由于这种说法不容易被十年寒窗苦读、潜心研究技术的同窗接受……

“颇有钱的、作 IT 产品的公司”,这个世界上固然是有的,可是这样的公司,根本不会用“技术驱动”这种词来忽悠新人。

最后,隔行如隔山,但隔行不隔理。若是你读完上面的东西,对本身所处的行业有了进一步的认识,我觉得,是很正常的。


关注微信公众号:松花皮蛋的黑板报,获取更多精彩!

做者介绍

智煜徽,洛林大学计算机专业研究生,现就任于华为,从事自动驾驶 / 机器学习相关研发工做。曾在卢森堡 -Clearstream 参与分布式金融平台的开发;有创业经历。

原文连接:

https://www.zhihu.com/question/312019918/answer/608965942
相关文章
相关标签/搜索