程式設計師生存定律這系列的目錄在這裡：程式設計師生存定律--目錄。喜歡從頭瞄的，可以移步。

假設說你想在江湖裡謀求一定的地位，那麼你可以練習獨孤九劍成為超一流高手，也可以練習醫術，成為絕世神醫。這兩者在江湖裡都是有地位的，也都是稀缺的，一者是因為殺傷力，二者是因為人都有山高水長。 程式設計師也一樣，增值也好，改善表達力也好，最終都要在某種環境下達成一定的稀缺性，這樣一個人才有價值。稀缺性同時受兩個維度上的力量影響：一個是自身的努力，比如前文所提到的增值和表達力；一個是大環境的變化以及對這種變化的適應。在這一章裡主要關注的是後者。 稀缺性可帶給你什麼 既然稀缺性對個人有如此大的影響，那稀缺性到底可以帶給一個人什麼樣的影響，我們看一個簡單的例子： 在日本曾經有這樣一個故事。一個人在某電信公司負責一個大型系統的維護，收入雖然不菲，但時間一長，這個人就對薪資發展不太滿意，因此最終選擇了離開。結果他一離開，這大型系統立時跑的磕磕絆絆，無奈之下，這家電信公司只得以高職厚薪把這個人請了回來。可以想見為了達到這一目的，這家電信公司，無論在收入還是職位上必然都開出了讓這個人無法拒絕的條件。 這是稀缺性起作用的一個典型例子。大型系統因為關聯到龐大的使用者群體而必須要用，同時這一系統的維護沒有這個人又不行，這就使這個人的稀缺性變得非常突出。 這事其實很有意思，因為在這裡事實上是不好的軟體成就了一個人的價值和稀缺性。這雖然不是很好，但其實這類情形並不罕見。從市場的角度來看，它並不關注一個程式的內部邏輯是否清晰，是否有足夠的註釋，它只關注這東西能不能運作好。所以使用中的垃圾程式碼一樣有巨大的價值，也就是說商業上的考量對稀缺性的影響更大。 為防止上述文字被曲解，這裡補充一點說明。上述道路並非是一條非常值得模仿的道路。因為對上述那個人而言，事實上他的價值綁定於特定的一套系統，這會導致可流動性幾乎沒有，這就會限制住一個人的成就，並使未來存在很大風險。 改善稀缺性的途徑

為了改善自己的稀缺性，通常需要同時做兩個方面的工作：一是提升自己；一是順應時勢。提升自己可以讓自己稀缺這點很好理解，但如果沒有順應時勢相配合，就很容易讓這種稀缺性無法很好的實現。在2013年精通DOS程式設計的人無疑是稀缺的，可這不一定能產生價值。下面我們將從上述兩個方面對稀缺性做一點說明。 1.奔向程式世界裡的價值高地 投資大師巴菲特先生說過一句流傳很廣的話：有的企業有高聳的護城河，河裡頭還有凶猛的鱷魚、海盜與鯊魚守護著，這才是你應該投資的企業。這句話非常傳神的描述了價值高地的外在形象。 對於企業而言，護城河可以是很多東西：高難的技術（波音飛機）、難以攻破的使用者粘度（QQ）、獨佔的資源（中石油）、獨特的企業文化（蘋果）等等。 護城河使企業擁有一種無可取代的價值，從供給上看這就是營造企業自身價值的稀缺性：缺了它不行，你又沒有更多選擇。這就是價值高地，當企業在這上面時，他相對安全。也正因此，大公司最終都會試圖主導一種秩序與生態系統，只有如此大公司才能掌控稀缺性。 這道理同樣適用於個人。稀缺本身可以有很多來源，可以來源於時機，也可以來源於高度。來源於時機的稀缺性更像一種偶然，很容易被打破，往往並不具備長久的價值，相對於人的一生而言，這並非是一種有力支撐。比如：Erlang可能比較稀少，但單純的語言壁壘並沒有想的那麼高，如果真的有巨大需求，這個世界上可以在一個月間多出幾百萬Erlang程式設計師。 當一個人經營自己的稀缺性時，確實要找到一個有鱷魚、海盜和鯊魚守護的地方，這才是價值高地。當然鱷魚之類很難是你放的，這與企業不同。在這點上管理方向上和技術方向上的程式設計師所面臨的選擇和所需要採取的措施不同。 對於技術方向上的程式設計師而言，走向上述這類價值高地本身可以有兩種方法： 一是達到一定高度橫向展開。比如：程式語言，（金融）業務邏輯，外語，網路知識等組合在一起就可以成為一個高地，這裡面程式語言上一個人可能不如天才程式設計師，業務邏輯上可能不如銀行員工，外語可能不如專職翻譯，但每多一重過濾，就會導致高地的海拔拔高一分，最終轉換為稀缺性。 一是徹底的專家型道路。有的崗位可能不需要把面擴的很寬，比如做TTS，OCR的演算法，有些人甚至程式語言都可能不是瞭解的很熟，但確實可以是某一方面的專家。這同樣是一種價值高地。在這個方向上，一旦真的達到一定高度，那就不是單純的累積數量可以超越的。比如：認為100個或多少個平庸的科學家等價於一個愛因斯坦無疑的是愚蠢的。 不管是那種方向，最終都要達成這樣一種效果：你可以完整的搞定一件很有商業價值的事情，而這件事情大多數人搞不定。比如說： 我可以主導開發一款手機，因為我即懂軟體又懂硬體，也還知道如果開發一款良好的產品。現在來看，如果真牛，可以去搞定錘子的問題。 我可以把OCR的識別率提高1%。 我可以主導架起百萬級併發的網站。 我可以帶領隊伍搞定這個銀行的整個系統。 ... ... 這個時候最好不要用單純的技術觀點來衡量自己，比如我擅長Java，我會用PHP，我知道TCP/IP協議等等。不是說這沒有價值，而是說這種視角有點低端。只有能完整搞定一件事情才會與商業利益直接掛鉤，才可能有真正的稀缺性。 對於管理方向上的程式設計師，走向上述這類價值高地似乎只有一種途徑： 要努力做出讓人記得住的成績，這個成績可以是一個產品，也可以是某種業績。今時今日，提到微信相信大家都會想到張小龍。這是因為微信本身在不到兩年的時間裡吸引了2億使用者，並且口碑很好，實在是個奇蹟。 關於價值高地，有一個典型的陷阱：不含複雜度的，特屬於某個公司的經驗，往往讓人誤以為是價值高地，但其實不是，因為只要環境相對的公開，這類東西往往可以在短時間內被攻破。比如：一個公司可能定義了自己的流程，其中很多東西較為模糊，新人一做就處處碰壁。這很容易讓然誤解為掌握流程本身有較高的價值，但其實這是由於流程不完善所造成的，是特定場景下的一種偶然。這確實導致稀缺性，但基本不具備可流動性，大多時候未必是好的選擇。 需求開發算價值高地麼？

在偏敏捷的組織里程序員往往離需求很近，但在比較傳統的開發方法中，做需求的和程式設計師往往是有段距離的。做需求開發的可能不太會寫程式，寫程式的不太會寫需求。 那需求開發算價值高地麼？ 很多純粹的程式設計師可能覺得單純的文件工作沒什麼技術含量，似乎誰都能寫，因此可能認為這算不上什麼價值高地。但從商業價值來看，當一個人摸透某個行業的業務（懂技術更好），那麼這還真是價值高地。 這可以來做個類比，天貓只做平臺，各個商家賣東西，那麼天貓有價值麼？當然有價值，天貓11/11的銷售額100多億比美國的黑色星期五還高，怎麼可能沒有價值。 那為什麼天貓有價值？因為終端客戶的眼裡是先有天貓，再有各個商家，天貓壟斷了入口，所以天貓更有價值。 需求與開發的關係與此類似。當一個人做某個產品的需求時，在外人的眼裡，這個人做的需求才表徵著這個產品，透過產品才能看到程式設計師的貢獻。外部人員思考的思路是先需求開發人員再程式設計師。 其中比較極端的一種實踐是需求開發人員主導整個專案，所有其他人員在需求開發人員的領導下工作。 這個時候鑽牛角尖是沒意義的，比如：有的人可能認為沒程式設計師那有產品，這就和爭論沒店家那來天貓一樣，毫無意義。在現實中當然兩者都有存在價值，這裡討論的只是說這是否算是一塊價值高地。 2 .走在技術大潮的前面或裡面 IT世界裡，城頭變幻大王旗來的特別的快，而每一次變幻時事實上都將導致某種技術的興起或者某種技術的衰落。 當年WPS97的開發時間非常長，對此百度百科上對此的描述是：Windows有很多新東西，我們還沒有熟悉過來，微軟又升級了。很多技術資料，也很難找到。微軟掌握著Windows，而我們什麼都要靠自己從頭做起，這導致了WPS97難產。如果WPS97能在1995年推出，直接和Word6．0競爭，Word6．0肯定沒戲。 這很生動的記述了一門新技術興起時所造成的稀缺性，從側面也可看出來，在95年的時候企業對高階Windows開發人員是何等的渴望。這種稀缺性是行業週期背後的技術更迭所造成的。而在今天，藉助搜尋引擎，初入行的程式設計師也可以解決大部分Windows程式設計的問題。 面對這種技術潮流，比較合適的辦法是基於現實勇敢擁抱新技術。 基於現實是指考慮技能的可流動性，考慮實踐和學習的不可以分離特質，選擇自己認為前景好的新技術，並投入時間。但這裡面有個陷阱，一提到新技術很多人可能會聯想到新程式語言，但程式語言太基礎了，壁壘太低，並不是一個足夠大的考量區域。視角如果限在這個尺度上，看到的東西就會太多，而不容易聚焦，這時候需要把自己考量的單位適當放大一點，英文中常用Tech Stack這個詞來描述這一組技術。 比如說：LAMP(Linux+Apache +MySQL+Perl/PHP/Python)可以是一種考量單位，Windows程式設計+ASP.NET也可以是一種考量單位，大資料處理相關種種也可以是一種考量單位。 如果回望十年，我們就會發現，先有PC客戶端程式的鼎盛，接下來是網際網路的興起，再接下來則是移動客戶端的興旺。以當下而論，無疑的移動客戶端和網際網路要比傳統的PC客戶端來的更有吸引力。而在雲的時代裡，壁壘比較分明的兩套Tech Stack則是基於閉源的一系列技術（主要是由微軟提供）和基於開源的一系列技術。在這裡面如果那個Tech Stack的技術逐漸取得優勢，那麼無疑的在相應的Tech Stack中有積累的人會有比較好的稀缺性。 雖然眼下看來，兩者似乎沒有明顯差別，但在這點上，我個人認為未來開源Tech Stack會逐漸取得優勢。在Quora(quora.com)和High Scalability(highscalability.com)上，我們可以查詢到國外大部分新興的、市值超過10億美元Web2.0網站的技術架構，如：Flickr，Pinterest，Instagram等。如果用心來讀這些技術架構，就會發現他們一個根本的共同點：他們都是基於開源技術構建的。 這種不約而同的選擇背後有一定的必然性。當希望一定的定製性並且不願意支付高額成本時開源Tech Stack幾乎是一種唯一的選擇，尤其是當開源的技術有越來越多成功例項的時候，這種優勢就越來越明顯。 如果非要在客戶端（iOS，Android，WinRT)和網際網路中選擇，我個人認為網際網路比客戶端更有優勢。 技術落潮所伴隨的風險 很多人會講微軟在2002到2012這10年裡幾乎無所作為，也會談論從股票上來看如果10年前買入的是微軟股票那麼現在只能賺30~40%，而如果是買的蘋果股票那就要賺3倍多。我個人偶爾思維發散，想到的卻不只是這個，而是如果微軟再失去10年，那掛掉的不只是微軟，還有同微軟綁在一起的各種公司和個人，包括很多資深的Windows程式設計師。 在PC的世界裡微軟是無疑的霸主，但如果PC的時代過去了，那麼這個霸主如果無法轉型成功，那麼無疑也要隨之殉葬。而那個時候無數在微軟平臺上花了半生心血的人卻還都在，他們又該何去何從？ 技術大潮的興起會使潮頭的很多人稱為耀眼的明星，而某波潮水的退去，同樣會帶走與之相伴的一些人的光環。所不同的是前者轟轟烈烈，而後者寂寂無聲。 在這種情境下，還真就只能與時俱進。 檢查自己的稀缺性 從社會需要的角度檢查自己的稀缺性非常困難，因為相關的各種資料總是非常缺乏。但有個簡單的方法可以很快的讓一個人認清自己的稀缺性：假設一個畢業生很努力的學，那麼多久他可以取代你的工作？比如一個畢業生只要努力，那麼可以在一兩年取代你，而你的年紀已經接近30歲，那麼稀缺性必然非常不好。 而與這個相反，如果一個畢業生即使很努力，也要五年才有你的技術水平，同時如果沒有特定的機緣，怎麼也無法取代你，那麼即使你已經30歲，你的稀缺性也會非常好。這裡的機緣可以是指某些特別的實踐機會。 如果想比較系統的評估自己的稀缺性，那麼需要依次考慮如下問題： 1.自己所掌握的技術是即將過時的技術麼？ 技術大潮總是會定時的淘汰各種技術，不同的時間點淘汰的物件也不太相同。有的雖然不是完全淘汰，但至少他們不再像當年那麼輝煌了，如果以2013為界限而回看10年，那這樣的技術有：Flash，MFC，Delphi等。 為保持對技術動向的敏感度，定期閱讀別人的架構非常關鍵。 當然可能過時的技術不單指通用的技術，還指老舊的可能會為新解決方案所替代的系統。比如說：曾經很多公司使用Lotus Notes來做知識管理的，但很少人使用這樣的系統了。 2.自己所掌握的技能究竟有多少人會？ 考察這點時要像前文所描述的，更多的從公司的視角去考慮，而不是個人的視角。單純的會使用某個語言或者框架這種程度，稀缺性一定沒有。比如：單純的會用ASP.net開發網頁幾乎沒有較高的技術壁壘，但對資料庫的設計有相當程度的掌握、能夠較好的通過負載均衡、快取等手段保證系統的效能就可以使自己的稀缺性上個臺階。