科技公司到底是爲技術驅動還是業務驅動的爭論古來有之。對於技術人員而言，擁有良好工程師文化、代碼文化，核心競爭力是技術、尊重技術、技術人的公司似乎就可以稱得上是技術驅動型公司。但事實果真如此嗎？本文作者給出了不一樣的看法，他認爲，世界上沒有技術驅動型公司，谷歌、臉書不是，阿里、騰訊也不是。
免責聲明：本文僅代表作者一家之言，不代表InfoQ立場，歡迎評論區有理有據的討論。
世界上沒有技術驅動型公司，不論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使用。
這裏面有四個問題值得思考：
-
爲什麼那家開發DOS的公司沒能直接和IBM合作？
-
微軟購買DOS系統的錢哪裏來的？
-
微軟爲什麼不自己開發操作系統？
-
技術在前三個問題中的角色和作用是什麼？
至於有人說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參與分佈式金融平臺的開發；有創業經歷。