醒醒吧，世界上有技术驱动型公司！

1

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

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

所以一切技术问题，都要服从产品交付和市场反馈。 因此，任何公司都不可能以技术去驱动自身。 人能够以技术驱动本身进步，但公司不行。

一家公司能够以技术切入某个市场，但若是它想生存下去，就必定不能以技术为导向，坚持以技术为导向的公司的生命力为零，其下场有两个： 破产或者在破产以前被收购。

若是你真的很痴迷钻研技术，请读研读博最后留校，或者进研究院让国家用纳税人的钱养你。

2

 每一个人都得加班

资本富集的地方，人都得加班，加班的本质，是人跟着机器跑、人跟着钱跑。

更为本质地说，资本富集的地方，人做为劳动力，也是资本的一种。 即人是资本而不是人自己。

资本的运转是不能停的，由于停一下损失的钱太多了，中国和外国都同样。

知道发达国家为何产业工人不加班吗？ 由于制造业已经不是这些国家主要创造财富的领域了。

发达国家资本富集的地方是金融行业，因此西方国家的金融狗同样加班。

劳动法？ 加班费？ 都不存在的。 劳动法和加班费只有在资本离开这个市场后才能给你保证。

通常公司的策略是： 付给你高于其余行业的薪水、换取你“自愿”加班。 不想加班的同窗们，大家能够去考公务员或者去欧洲作IT，我保证你不加班、不但不用加班，你甚至会很闲。

3

 先想后写

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

IT领域最重要的是经验，而不是你有多聪明，不聪明的人，或者更准确地说，不适合作这个行业的人，大学毕业后就改行了。

记住： 你作得好很差，不取决于你是否聪明，而取决于你是否愿意不断读书、不断学习和不断积累。 所以，若是你打算投身这个行业，还在学校的话就请抓紧一切时间多读书。

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

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

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

一个程序员，应该花80%的时间作代码设计、画UML图、画时序图，20%的时间写Code和Debug，菜鸟程序员的这个比例刚好是反的。

一句话，不论这个需求有多紧急，你都必定要“想好再动手”。 “想好”的标志就是设计文档写好了，文档一旦写好，写代码就是纯粹的无脑工做。

写文档的目的是让你在Code的时候，不须要停下来思考，更不须要推倒重来。 若是没有文档也能够作到这一点，你固然能够不写文档，同时思考下本身水平这么高是否是能够要求升职加薪了。

或者，你是否是在作无聊的if else编码工做？ 这篇推荐你们阅读。

4

 关注软技能

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

要有分享精神，不要担忧你知道的东西告诉别人后你就没价值了。你最大的价值在于你知道那些东西的过程，而不是那些东西自己。

你愿意和别人分享，别人天然也会愿意和你分享，最终达到1+1大于2的效果。

不分享，就像一个失去了互联网的程序员，试问他还能创造多少价值？ 恐怕他连平常工做都没法展开了。

持有“我把别人知道的都学会，把本身知道的都藏起来，别让别人学去”想法的人，实际上是默认全世界只有你聪明别人都是傻瓜，这样的人，在信息传输成本高的时代，能够活下去，可是在今天这个时代，他们的路会越走越窄，最后会本身走入死胡同。

固然，若是你真的知道了了不起的黑科技，那就请你保护好本身的知识产权，而后本身开公司玩吧。

5

 工做要有热情

智商决定你的起点，情商决定你能走多远爬多高。 混职场，靠的是情商。

情商高就是： 别人愿意和你一块儿工做、你有问题的时候别人愿意帮你。 智商有时候能够稍微弥补一下情商，但不起决定性的做用。

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

6

 写好文档

怎样让程序员变得可替代？ 三个字： 写文档。

不肯意写文档的程序员，应该马上立刻绝不犹豫地开掉。 程序员工做创造的价值，至少一半是经过文档体现出来才对。

“一个项目换一我的就要让项目大地震一下”，“解决Bug换一我的就不行，由于只有老人知道要改哪一行的哪一个关键字”，这不说明这个项目所涉及的技术有多复杂、不说明这个老人是什么技术大牛，而只说明这个项目的项目经理很蠢，这个项目已经失控了。

文档不是事无巨细的流水帐，写文档以及组织文档是须要智商的、是须要架构师去设计的。

美国的航天飞机那么复杂，可是在Pilot手里的手册也就那么多，而这个手册能够在航天飞机出问题的时候协助Pilot快速定位绝大多数问题。

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

7

 开发人员的文档的做用

给正在Code的本身看、给几个月后已经忘记这个模块当初是怎么开发的本身看、给要接手本身工做的新人看、给周边有关联开发任务的同事看、给领导等有关人员看，这是产品出bug的时候用来和别人怼的武器。

若是没有文档，这些工做量都会成倍增加。

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

参考：https://github.com/YvesZHI/FallingCode

这段代码自己并不复杂，应该说很是简单，可是没有文档……读读看吧。

简而言之，文档，就像盖楼房的设计图，没有图纸，你是不能开始搬砖的。

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

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

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

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

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

上面这一段话，就是你要写的文档，这个文档的读者主要是你，在你的模块出问题以前，别人一般不会读这个文档（不排除你的领导会要求看你这个文档）。

若是你既不须要时序图又不须要类图又没什么协议须要明确，那么，你就能够不写这个文档。另外，若是这个文档写得好，你的代码是不须要任何注释的。

8

 技术驱动

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

为何呢？ 由于我知道他的那句“技术驱动”很吸引你，你想学东西，可是对小公司来讲，它最大的任务是活下去，而后才是其余。

我不是说小公司学不到东西，我只是说小公司很难很难作到真正的技术驱动。

有人坚持认为微软这种公司是技术驱动，但微软从没大张旗鼓地说本身是“技术驱动”公司，并以此忽悠新人。

以华为为例。 华为成功的内在缘由，早就敲锣打鼓地告诉全世界了： 以客户为中心，以奋斗者为本，长期艰苦奋斗，坚持自我批判。

这四句话，没一句是直接和技术相关的。

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

华为的技术，不须要我多说，全世界的人都是有目共睹的，华为公司的技术专利数就摆在那里，那是谁也抹杀不了的，华为公司里的技术大牛多了去了。

但在这里，我要说的仍是第一段的意思： 一我的能够以技术驱动，但一家公司不行。

华为公司的核心理念，本质就是“成就客户”，你把客户成就了，你就把本身成就了，华为不是先成就本身再去成就客户的公司。

你去华为工做，你能够以技术驱动本身，但华为不能这样作。

这一点和微软与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同样，只有后续继续开发，才有可能让你继续跟进。

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

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

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

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

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

被“技术驱动”迷惑的同窗，其实就是读书读傻了，什么叫“读书读傻了”？ 就是把社会和学校等同成一样的东西……

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

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

做者： 智煜徽

zhihu.com/question/312019918/answer/608965942

- END -

推荐阅读：

关注 Java技术栈 公众号在后台回复： Java ，可获取一份栈长整理的最新 Java 技术干货。

点击「阅读原文」和栈长学更多～