摘要:世界上沒有技術驅動型公司,不論Google、Facebook,還是騰訊、阿里,都不是技術驅動型公司。

因為技術不是源頭,需求才是。因此一切技術問題,都要服從產品交付和市場反饋。

所以,任何公司,都不可能以技術去驅動自身。人可以以技術驅動自己進步,但公司不行。

一家公司可以以技術切入某個市場,但如果它想生存下去,就一定不能以技術為導向,堅持以技術為導向的公司的生命力為零,其下場有兩個:破產或者在破產之前被收購。

如果你真的很癡迷鉆研技術,請讀研讀博最后留校或者進研究院讓國家用納稅人的錢養你。

資本富集的地方,人都得加班,加班的本質,是人跟著機器跑、人跟著錢跑;更為本質地說,資本富集的地方,人作為勞動力,也是資本的一種。

即,人是資本而不是人本身。資本的運轉是不能停的,因為停一下損失的錢太多了。

中國、外國,都一樣。

知道發達國家為什么產業工人不加班嗎?

因為制造業已經不是這些國家主要創造財富的領域了。發達國家資本富集的地方是金融行業,所以西方國家的金融狗一樣加班。

勞動法?加班費?都不存在的。勞動法和加班費只有在資本離開這個市場后才能給你保證。

一般公司的策略是:付給你高于其他行業的薪水、換取你“自愿”加班。不想加班的同學們,你們可以去考公務員或者去歐洲做IT,我保證你不加班、不但不用加班,你甚至會閑出病。

IT是工科,不是理科,和IT行業相似度最高的行業是蓋樓房。真的,相似度相當驚人。

IT領域最重要的是經驗而不是你有多聰明,不聰明的人或者更準確地說不適合做這個行業的人,大學畢業后就改行了。

記住:你做得好不好,不取決于你是否聰明,而取決于你是否愿意不斷讀書不斷學習和不斷積累。因此,如果你打算投身這個行業而你還在學校,請抓緊一切時間多讀書。

公司是你創造財富的地方,公司不是學校。

你可以在工作中學習,但你不能放下工作然后去學習除非你的工作已經做完了。

能大規模商用的技術,都不需要智商,否則這種技術就不可能規模化。某些程序員們,請停止你們的蜜汁自信。

技術棧,一旦確立了,就很難改了。一個技術人員是如此,一家公司也是如此。根本原因是:每一個棧的size都太深了……就像是ulimit -s unlimited過一樣。

一個程序員,應該花80%的時間做代碼設計、畫UML圖、畫時序圖,20%的時間寫code和debug;菜鳥程序員的這個比例恰好是反的。

一句話,不論這個需求有多緊急,你都一定要“想好再動手”;“想好”的標志就是設計文檔寫好了;文檔一旦寫好,寫代碼就是純粹的無腦工作。

寫文檔的目的是讓你在code的時候,不需要停下來思考更不需要推倒重來。如果沒有文檔也可以做到這一點,你當然可以不寫文檔同時思考下自己水平這么高是不是可以要求升職加薪了……或者,你是不是在做無聊的if else編碼工作?

英語,很重要。能否使用英語查閱資料,是區分技術人員水平的重要指示之一。寄希望于“有人遲早會翻譯成中文”的人是愚蠢的、是會被淘汰的。

要有分享精神,不要擔心你知道的東西告訴了別人你就沒價值了。你最大的價值在于你知道那些東西的過程,而不是那些東西本身。

你愿意和別人分享別人自然也會愿意和你分享,最終達到1+1大于2的效果。不分享,就像一個失去了互聯網的程序員,試問他還能創造多少價值?恐怕他連日常工作都無法展開了。

持有“我把別人知道的都學會、我把自己知道的都藏起來別讓別人學去”想法的人,其實是默認全世界只有你聰明別人都是傻瓜,這樣的人,在信息傳輸成本高的時代,可以活下去,但是在今天這個時代,他們的路會越走越窄最后會自己走入死胡同。

當然,如果你真的知道了了不得的黑科技,那就請你保護好自己的知識產權然后自己開公司玩吧。

工作要有熱情。

智商決定你的起點情商決定你能走多遠爬多高;混職場,靠的是情商。情商高就是:別人愿意和你一起工作、你有問題的時候別人愿意幫你。智商有時候可以稍微彌補一下情商但不起決定性的作用。

現代管理學的精髓,就是讓每個人(包括老板本人)都變得可替代。如果你覺得自己不可替代,要么是你的錯覺,要么是你在一家管理非常原始的、搖搖欲墜馬上要完蛋的公司。

怎樣讓程序員變得可替代?三個字:寫文檔。不愿意寫文檔的程序員,應該立刻馬上毫不猶豫地開掉。程序員工作創造的價值,至少一半是通過文檔體現出來才對。

“一個項目換一個人就要讓項目大地震一下、解決bug換一個人就不行因為只有老人知道要改哪一行的哪個關鍵字。”

這不說明這個項目所涉及的技術有多復雜、不說明這個老人是什么技術大牛,而只說明這個項目的項目經理是蠢貨因為這個項目已經失控了。

文檔不是事無巨細的流水賬,寫文檔以及組織文檔是需要智商的、是需要架構師去設計的。美國的航天飛機那么復雜,但是在pilot手里的手冊也就那么多,而這個手冊可以在航天飛機出問題的時候協助pilot快速定位絕大多數問題。

不可替代的打工者只有一種:以中高層領導的身份跟完了一個項目而且這個項目正處于大紅大紫的階段,公司為了防止你跳槽到競爭對手那里,愿意付給你薪水養著你天天在辦公室喝茶。只要項目一直紅著,公司就愿意一直養著你。

讀完這個答案后如果你覺得我是一個輕視技術的人,那么恭喜你,你和我一樣,是一名杠精。杠精讀別人的回答,永遠不會去正面理解,而只會想盡一切辦法找這個答案的漏洞。

“開發人員的文檔的作用”

給正在code的自己看、給幾個月后已經忘記這個模塊當初是怎么開發的自己看、給要接手自己工作的新人看、給周邊有關聯開發任務的同事看、給領導等有關人員看、產品出bug的時候用來和別人懟的武器。

如果沒有文檔,這些工作量都會成倍增長。

代碼再精簡再直觀,也不可能有人類語言直觀,誰覺得自己厲害到讀代碼和讀人類語言寫的文檔速度一樣快讀地步,我給你個我上大學時候寫的小程序,麻煩你讀一下代碼,看看你多長時間可以看明白:https://github.com/YvesZHI/FallingCode

這段代碼本身并不復雜,應該說非常簡單,但是沒有文檔……讀讀看吧。

簡而言之,文檔,就像蓋樓房的設計圖,沒有圖紙,你是不能開始搬磚的。

領導有沒有給你看需求分析文檔?有沒有拿著需求分析文檔給你宣講你要做什么?沒有?不干活;

測試的同事有沒有給你看測試用例文檔?有沒有給你宣講?沒有?不干活;

你自己明白領導的意圖了嗎?明白測試同事的意圖了嗎?

想明白后,開始想自己要開發的模塊里的各個功能模塊之間的關系,可以畫時序圖;時序圖畫完了,看看是否有(可能)頻繁變化的模塊/需求。

如果有,請務必使用一些設計模式,如果要用設計模式,請務必畫UML類圖,如果沒有頻繁變化的模塊/需求,請一定不要用設計模式。

最后,看看在一個功能模塊中,有沒有邏輯比較復雜的地方,如果有,請畫流程圖;模塊和模塊之間有沒有需要明確的協議?

如果有,請把協議寫出來。

上面這一段話,就是你要寫的文檔,這個文檔的讀者主要是你,在你的模塊出問題之前,別人通常不會讀這個文檔(不排除你的領導會要求看你這個文檔)。

如果你既不需要時序圖又不需要類圖又沒什么協議需要明確,那么,你就可以不寫這個文檔。另外,如果這個文檔寫得好,你的代碼是不需要任何注釋的。

“技術驅動”

一些朋友認為我對“技術驅動”有誤解,對此我不想辯論了。

上面那段話就是我想對后輩說的。什么意思呢?就是告訴后輩,如果一家公司打著“我們是技術驅動型公司”的名號在招人,那么如果你決定要去這家公司,我勸你一定要想好考察好。

為什么呢?

因為我知道他的那句“技術驅動”很吸引你你想學東西,但是對小公司來說,它最大的任務是活下去,然后才是其他,我不是說小公司學不到東西,我只是說小公司很難很難做到真正的技術驅動。

評論區有人堅持認為微軟這種公司是技術驅動,這個問題我后面會專門補充,目前我只能說:我是沒見過微軟大張旗鼓地說自己是什么“技術驅動”公司然后忽悠新人。

“技術驅動2”

看來有不少朋友愿意和我糾結這個“技術驅動”的問題,那我就和你們杠一杠。

我以華為為例來說說。

華為成功的內在原因,早就敲鑼打鼓地告訴全世界了:以客戶為中心,以奮斗者為本,長期艱苦奮斗,堅持自我批判。

這四句話,沒一句是直接和技術相關的。

這里我先特別聲明一下,我不是說,技術人員在華為就不會搞技術、不會提升自己的技術水平、華為的技術水平差。

華為的技術,不需要我多說,全世界的人都是有目共睹的,華為公司的技術專利數就擺在那里,那是誰也抹殺不了的;華為公司里的技術大牛,多了去了;但在這里,我要說的還是第一段的意思:一個人可以以技術驅動,但一家公司不行。

華為公司的核心理念,本質就是“成就客戶”,你把客戶成就了,你就也把自己成就了,華為不是先成就自己再去成就客戶的公司。

你去華為工作,你可以以技術驅動自己,但華為不能這樣做。這一點和微軟與IBM的合作極其相似:IBM說,你們微軟現在搞的東西我愿意用,但是我需要你們給我搞個操作系統,這樣我們才能繼續合作。

然后微軟怎么做的呢?它馬上購買了另外一家公司搞的DOS操作系統,然后直接授權給IBM使用。

這里面有四個問題需要各位杠精們思考:

1. 為什么那家開發DOS的公司沒能直接和IBM合作?

2. 微軟購買DOS系統的錢哪里來的?

3. 微軟為什么不自己開發操作系統?

4. 技術在前三個問題中的角色和作用是什么?

至于評論區有朋友說Intel是技術驅動公司,我建議他去了解一下Intel為什么放棄了手機市場:重點關注Intel決定放棄手機市場的原因,然后你就會發現,這個原因的本質,就是一種技術情節的產物。

Intel放棄手機市場與華為決定進軍手機市場是截然不同的。

華為本來是做基站、路由器和交換機的,這是它的主營業務。那么華為為什么決定進入手機市場?

是什么原因驅使華為在沒有任何技術積累的前提下進入手機市場、以至于最初華為的手機被華為員工戲稱為“暖手寶”倒貼錢都沒人愿意用但現在華為手機如此成功?

所以,我還是那個觀點:世界上沒有技術驅動型公司。我本人就是程序員,我一直都以技術在驅動自己我一直都在努力提升自己的技術水平但是我還是要說:世界上沒有技術驅動型公司。

“技術驅動3”

一個新的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產品的公司”,這個世界上當然是有的,但是這樣的公司,根本不會用“技術驅動”這種詞來忽悠新人。

最后,隔行如隔山但隔行不隔理。如果你讀完上面的東西,對自己所處的行業有了進一步的認識,我以為,是很正常的。