世界上沒有技術驅動型公司

面試精選集，快快前往領取吧！offer.liangsonghua.me/。關注微信公衆號：松花皮蛋的黑板報，獲取更多精彩！

世界上沒有技術驅動型公司，不論 Google、Facebook，仍是騰訊、阿里，都不是技術驅動型公司。由於技術不是源頭，需求才是。

所以一切技術問題，都要服從產品交付和市場反饋。因此，任何公司，都不可能以技術去驅動自身。人能夠以技術驅動本身進步，但公司不行。一家公司能夠以技術切入某個市場，但若是它想生存下去，就必定不能以技術爲導向，堅持以技術爲導向的公司的生命力爲零，其下場有兩個：破產或者在破產以前被收購。若是你真的很癡迷鑽研技術，請讀研讀博最後留校或者進研究院讓國家用納稅人的錢養你。

客觀看待加班問題

資本富集的地方，每一個人都得加班。加班的本質，是人跟着機器跑、人跟着錢跑。更爲本質地說，資本富集的地方，人做爲勞動力，也是資本的一種。即，人是資本而不是人自己。

資本的運轉是不能停的，由於停一下損失的錢太多了，中國、外國，都同樣。知道發達國家爲何產業工人不加班嗎？由於製造業已經不是這些國家主要創造財富的領域了。發達國家資本富集的地方是金融行業，因此西方國家的金融狗同樣加班。

勞動法？加班費？都不存在的。勞動法和加班費只有在資本離開這個市場後才能給你保證。通常公司的策略是：付給你高於其餘行業的薪水、換取你「自願」加班。不想加班的同窗們，大家能夠去考公務員或者去歐洲作 IT，我保證你不加班、不但不用加班，你甚至會閒出病。

多讀書，但別迷信技術

IT 是工科，不是理科，和 IT 行業類似度最高的行業是蓋樓房。真的，類似度至關驚人。

IT 領域最重要的是經驗而不是你有多聰明，不聰明的人或者更準確地說不適合作這個行業的人，大學畢業後就改行了。記住：你作得好很差，不取決於你是否聰明，而取決於你是否願意不斷讀書不斷學習和不斷積累。所以，若是你打算投身這個行業而你還在學校，請抓緊一切時間多讀書。

公司是你創造財富的地方，公司不是學校。你能夠在工做中學習，但你不能放下工做而後去學習，除非你的工做已經作完了。

能大規模商用的技術，都不須要智商，不然這種技術就不可能規模化。某些程序員們，請中止大家的蜜汁自信。

技術棧，一旦確立了，就很難改了。一個技術人員是如此，一家公司也是如此。根本緣由是：每個棧的 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