作者介紹：智煜徽，洛林大學計算機專業研究生，現就職于華為，從事自動駕駛/機器學習相關研發作業，曾在盧森堡-Clearstream參與分布式金融平臺的開發；有創業經歷，
一、世界上沒有技術驅動型公司
二、人人都得加班
三、先想后寫
四、關注軟技能
五、寫好檔案
六、開發人員的檔案的作用
七、技術驅動
世界上沒有技術驅動型公司
世界上沒有技術驅動型公司，不論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的時候用來和別人懟的武器，
如果沒有檔案，這些作業量都會成倍增長，
代碼再精簡再直觀，也不可能有人類語言直觀，誰覺得自己厲害到讀代碼和讀人類語言寫的檔案速度一樣快，
簡而言之，檔案，就像蓋樓房的設計圖，沒有圖紙，你是不能開始搬磚的，
領導有沒有給你看需求分析檔案？有沒有拿著需求分析檔案給你宣講你要做什么？沒有？不干活，
測驗的同事有沒有給你看測驗用例檔案？有沒有給你宣講？沒有？不干活，
你自己明白領導的意圖了嗎？明白測驗同事的意圖了嗎？想明白后，開始想自己要開發的模塊里的各個功能模塊之間的關系，可以畫時序圖，
時序圖畫完了，看看是否有（可能）頻繁變化的模塊/需求，如果有，請務必使用一些設計模式，如果要用設計模式，請務必畫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產品的公司”，這個世界上當然是有的，但是這樣的公司，根本不會用“技術驅動”這種詞來忽悠新人，
最后，隔行如隔山，但隔行不隔理，如果你讀完上面的東西，對自己所處的行業有了進一步的認識，我以為，是很正常的，
原文鏈接:知乎
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/55288.html
標籤：其他
上一篇：程式員與「中臺」的愛恨交錯
下一篇：一些用著方便的谷歌插件