醒醒吧，世界上有技術驅動型公司！

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 技術乾貨。

點擊「閱讀原文」和棧長學更多～