《程序員生存定律》 李智勇

首先感謝做者能寫這樣的東西分享給你們(原做者:李智勇 V 衆投發起人,《完美軟件開發:方法與邏輯》做者)。程序員

如下是我摘了一些對本身有啓發的片斷,之前是傻傻地放在本身的雲筆記中的,不懂分享:算法

 

  • 本書中試圖用四個可控變量來定義程序人生的規律,它們分別是:自身價值---也就是你能幹什麼;自身價值上的表達力---也就是別人認爲你能幹什麼;自身價值的稀缺性---也就是在特定時空背景下,市場對某種技能的渴求程度;身處公司的特質和將來---也就是公司提供了怎樣的平臺給人發揮。本書認爲這四個變量一塊兒決定了一我的在職場中的市場價值,我的的一切選擇主要是爲了在這四個變量上有所收益,並使市場價值最大化。
  • 嘗試以寫程序的方式創建一種精確的人生模型是很是困難的。一旦試圖這樣作很容易進入一個誤區,即指望爲人生創建一個真理式的公式。好比:若是你努力,那麼你必定成功。若是你有責任感,你必定成功。若是你人品好,你必定成功。若是你讀書,那麼必定成功。若是你注意細節,那麼你必定成功。若是你時間管理作好,你必定成功。...
  • 聽說某位行爲科學家曾經總結過:上帝把全部容易的問題都留給了物理學家。言下之意是,社會學科的問題都大不易。其根本緣由在於,人生是不精確的。這裏的關鍵是要找到起關鍵做用的可控因子和權變變量。
  • 人生實際上是條曲線,其振幅則隨着時間的流逝而逐漸收窄。而一我的最終振幅的高度則同時取決於:機緣、天分和努力。家世,時代種種皆可歸爲機緣。智商、情商、體質種種皆可歸爲天分。機緣和天分皆是命數,無從左右的起。也便是說,一我的持有的,能夠打破既定命數的砝碼也只是努力而已。從人生長短的角度來看,上帝是公平的,每一個人可用時間大體相同。不一樣的則是努力的效能。
第二章 職場生存定律
  • 支撐職場的基本規則是交換,交換的兩端分別是你可創造的價值與你的職場位置(包含收入)。交換就像任督二脈間的通道同樣,越是通暢,人生也就越順風順水;堵得越死,人也就越步履維艱。
  • 若是收入水平爲 I,那麼當 S x A > I 時一我的是有選擇權的也是安全的,不然一我的對於公司而言是負資產(至少是被認爲是負資產),潛在的有被剔除的風險。一旦一我的在多家公司裏都處於這樣一種情形下時,這我的的選擇權會越來收的越窄(只有公司能夠選擇我的,我的卻沒可能選擇公司),人生也就會愈來愈被動。確實有幾個因素會
    使實現程度 A 急速膨大。這幾個因素能夠歸納爲:自身價值表達力,自身價值的稀缺性,
    公司的特質和將來。
      定律要素之一:自身價值
  1. 人創造價值的基本途徑只有兩個:一個是徹底依賴於自身的技能,另外一個則是假於他人之手。
  2. 自身價值也是公司命運的根本。吳軍先生的《浪潮之巔》
     定律要素之二:自身價值上的表達力
  1. 敏於
    事訥於言的人不少,難道他們就沒有表達力了麼?顯然不是的。一我的的過往、行止、習慣、性格等都是表達力的一部分。
  2. 程序員必然同時具有這兩方面的能力:編程技能與作員工的技能,而作員工的技能則像一個變壓器,最終放大或縮小你的真實能力。這就是表達力的功效,而作員工的技巧正是表達力的一部分。
  3. 組織行爲學這類學科中會把這個問題單獨做爲一個研究項目:印象管理(impression management),首因效應等
  4. 從長期的
    視角來看,影響自身價值表達的幾個主要因素是:資歷、自身性格特徵、借勢的程度以及權術的運用等。
    定律三:定律要素之三:自身價值的稀缺性
  1. 稀缺性自己取決於需求與供給,這樣得到稀缺性就有兩個主要的手段:一是站在需求相對恆定,供給比較稀少的位置上;一是加入需求急速膨脹,而供給有限的場景下。
  2. 稀缺性的客觀狀態是一種大勢,做爲我的基本上不可能改變,只能作選擇以對應未來。因此其背後主要隱藏的是在特定時間點作出恰當判斷的問題。並且稀缺性是有時效的。
      定律要素之四:身處公司的特質和將來
  1. 組織是利益分配的基本單位。做爲結果,無論喜歡不喜歡,組織是利益分配的基本單位,在這以後,纔是組織中的我的如何進行利益分配。在分配 iPhone 所帶來的利潤時,首先是蘋果和富士康間的利潤分配,接下來纔是蘋果內部和富士康內部。
  2. 在《史記•貨殖列傳》裏太史公寫過這樣一段話:是以無財做力,少有鬥智,既饒爭時,此其大經也。這段話裏描述的三個層次則與咱們上述描述的層次相似:謀求自身增值是無財做力的層次,加強表達力是少有鬥智的層次,而注意稀缺性和公司特質則大體是既饒爭時的層次。
  3. 咱們能夠看一個簡單且常見的例子,並用上面四個要素分析一下利弊得失:工做中老是存在簡單且重複的工做,極端的就是生產線,你可能只是須要伸縮一下手臂,只是每 3~4 秒就要來一次。在程序員的工做中不太會有生產線那麼誇張,但確實也有簡單重複性工做,好比單純的拖控件、關聯數據庫或者例行設置大量配置信息等。
    對這樣一份工做應該如何進行分析?平心而論,想完全避免簡單重複性工做是不可能的,但若是一項工做的主體部分體現爲簡單重複,而且不可能自動化,那麼這種工做從增值的角度看是沒有助益的,可歸爲技術
    路徑短,不增長自身價值的工做。稀缺性則依賴於所作工做的具體含義。好比:若是你所處理的大量配置信息深嵌在一個公司內部的各個角落(收集困難),各個配置項的含義並非很好理解,這個工做對某家公司又特別有義,那麼稀缺性反倒可能很好,但可流動性就幾乎沒有,我的利益和公司利益將結合的無比緊密。這時候公司平臺變得很關鍵。因爲選擇權已然變小(只能在特定的公司或領域),這個時候表達力就很是的重要,若是不能在表達力這樣的活動上有所突破,那我的的將來就很難明朗。這個四個要素老是同時起做用,但不一樣時期、不一樣情景下,權重會有比較大的變化,這點在後面會逐漸展開。微觀來看,每一個人的職場經歷可能都很不相同,但骨子裏起做用的始終都是這幾個因素。
  4. 時運:程序員的命運也受時運所左右,你可能能力優秀、思惟活躍,性格鮮明,表達、技術也很優秀,但若是幾回換工做卻老是碰到呆板,喜歡老實人的領導,碰到平庸的公司,就可能一直不被欣賞。這種事情既不會是今天才有,也不會在明天就馬上消失。面對這類較差的時運,最須要的旺盛的鬥志和耐性,幹別的都沒用,求神拜佛也不行。馬化騰、馬雲這些大佬當年同樣很折磨,若是馬化騰在最痛苦的時候把騰訊賣了,那就不會有今天的每一年 400多億收入,程序員也同樣,這時候要有點但行好事莫問前程的心態。但這裏有個陷阱,不少人會把我的的失誤推諉到時運身上,麻醉本身,讓本身內心好過點,這個是假的時運。
第三章 軟件的世界是怎樣的
  1. 規律是必須順應而不能改變的,但除此以外現實中還有一些事實也是沒法改變的,這二者都很像程序中的常量,想提升人生的高度則須要同時駕馭這二者,而不能試圖爲二者賦值。
     3.1  技術更迭偏快
     3.2  介入門檻偏低
  • 固然,後勁不足可能會把不思進取的軟件開發人員限制在某個範圍內,好比說只能作
    應用級的開發,最終讓他們等待淘汰。
     3.3  軟件和軟件差異能夠很大
  • 對方法論而言,基於這一點最關鍵的一個引伸結論是:任何一種方法論不僅要陳述本身的方法,還要陳述本身方法的適用邊界。
軟件的世界裏還有許多其它的特徵,但和我的發展相關且沒法改變主要是這裏提到的三點:技術更迭較快、介入門檻相對較低、不一樣軟件差異極大。這三者相似於全局常量,而我的努力則相似於變量,它們共同在生存定律之下起做用,影響人生的最終高度。從自我增值的角度看,最關鍵的事情是不能與這三者所帶來的效應相違背。
第四章 程序員的增值之路
  • 咱們將把增值之路分解爲三個根本步驟並分別進行討論:如何選定本身的方向、如何開始本身的學習、如何持續的進階併成爲高手。
  • 4.1 方向的選擇:技術仍是管理
    • 4.1.1 技術與管理的關鍵差別
      • 要想作出本身的那份選擇,還須要考慮三件事情:一是既定環境下技術路徑究竟有多長,也就是說作技術有前途麼;一是我的的性格適不適合作管理工做;一是作管理工做可能會有什麼負面影響。
    • 4.1.2 技術路徑長短對前途的影響
      • 類比到軟件行業裏,單純的在既定接口下實現已定義的業務邏輯就是技術路徑比較短的工做,是體力密集型的;而分析業務邏輯,控制總體架構或者去研究 TTS 的算法則是智力密集型的,技術路徑較長。
        在選擇方向時關鍵要避免的是選擇了技術方向,但身處的現實中技術方向卻路徑較短,或者喜歡管理但跑到了純粹技術流的公司裏,這種選擇其內部所蘊含的矛盾會給當事人的人生形成極大的困擾。
    • 4.1.3 什麼樣的程序員適合轉管理
      • 先天帶來的不少東西,好比性格等實在很難改變,更多時候選擇順應本身的天性比選擇對抗更加明智。
      • 在大五模型裏用五個因素來考察人格特質:
        • 外傾性(extroversion):外傾者者傾向於喜歡羣居,善於社交和自我決斷。內傾者則比較內向,膽小害羞,安靜少語。
        • 隨和性(agreeableness):高隨和性的人是合做的,熱情的和信賴他人的,低隨和性的人是冷淡的,敵對的和不受歡迎的。
        • 責任心(conscientiousness):高責任心的人是負責的,有條不紊的,值得信賴的,鍥而不捨的。低責任心的人則容易精力分散,缺少規劃性,且不可信賴。
        • 情緒穩定性(emotional stability):積極的情緒穩定性者傾向於平和,自信;而消極情緒穩定性者(神經質的人)傾向於緊張,焦慮,失望和缺少安全感。
        • 經驗開放性(Openness to experience):開放性高的人富有創造性,凡事好奇,具備藝術的敏感性;開放性低的人則保守對熟悉的事物感到溫馨和知足。
      • 總的來看,外傾性和經驗開放性好的人更適合走上管理崗位。
    • 4.1.4 管理工做的負效應
      • 管理工做和人打交道比較多,因此對人員的特質有很強的依賴性。
      • 長時間在管理崗位的話,即便是作技術出身,技術能力也會退化,溝通技能、與上級的信任程度反倒會提升。
  • 4.2 增值之路的起點
    • 4.2.1 從那裏開始編程生涯
      • 如何參與開源項目?
        蔡俊傑主編的《開源軟件之道》對開源軟件的各個方面進行了比較系統的介紹,也介紹了參加開源項目的方法。總的來看參與開源項目並無很高的門檻,須要的是用心和投入。爲了參與開源項目第一步選定項目並弄清目標開源社區的運做方法。 Apache 和 Mozilla都是開源社區,但運做方式仍是有差別的。接下來要熟悉特定的開源項目,包括產品的功能和特色、代碼規範和架構等。爲了作出具體的貢獻,那麼須要訂閱郵件列表或者新聞組來了解社區當前情況。接下來能夠嘗試提交補丁或實現新功能來解決社區中的特定問題。通常來說開源社區會把參與人員分爲幾個層次,好比:在 Apache 的運做模式中共有這樣幾種角色:開發者( Developer) ,技術專家 (Committer) ,項目管理委員會成員( ProjectManagement Committees) , Apache 軟件基金會理事會 (Board of Directors) 。當一個開發者付出足夠努力,得到足夠影響力後,項目管理委員會會授予這我的 Committer 稱號,只有 Committer才擁有對代碼庫的寫權限。若是 Committer 的貢獻足夠大,就有可能被選舉進入項目管理委員會,而項目管理委員會的主席則都是 Apache 軟件基金會的 VP 。新參與者在最開始階段必然只能是 Developer 的層次,不會具備寫權限。只有經過積極參與討論,爲社區作出了具體貢獻以後纔可能得到 Committer 稱號。這是一個持續投入的過程。固然參與社區工做,不必定非是提交代碼,也能夠幫助完善文檔、運行測試用例、報告缺陷維護網站等等。
    • 4.2.2 打牢根基 VS 速成道路
      • 那些東西能夠被認爲是編程的根基,須要在學習階段紮實的掌握?下面將經過推薦幾本書(或者說幾類書)來描述一個共通於全部程序員的最小集合。
        • 計算機體系結構:《深刻理解計算機系統》,做者是 Randal E.Bryant 和David O’Hallaron。
        • 算法和數據結構:《算法導論》,做者是 Thomas H.Cormen,Charles E.Leiserson,Ronald L.Rivest,Clifford Stein。
        • 設計原則和模式:《敏捷軟件開發:原則、模式與實踐》,做者是 Robert C.Martin。GoF 的《設計模式》
        • 軟件工程:《代碼大全》,做者是 Steve McConnell。《人月神話》
      • 《Hadoop 技術內幕》
      • 若是條件實在不容許厚積薄發,非要速成,我以爲能夠嘗試用這樣一種方法:死磕一個流行的開源程序。好比國內用的比較多的是 WordPress,那若是狠狠心花半年一年把WordPress 搞透了,技能能提高不說,對找份合適的工做也仍是頗有幫助的。
    • 4.2.3 掌握讀代碼的方法和技巧
      • 從學習的目的來看,必定要精讀必定量的經典代碼。而精讀是指每行都讀懂,不看代碼腦子裏就能勾畫出程序的基本結構。
      • 這節裏主要關注的是如何泛讀較大規模代碼,不是精讀。
        • 讀規模較大的程序前,先得把規格說明書大體弄清楚,而不能上來就讀。
        • 接下來從大往小,從面到點來看。
        • 接下來選擇出最經常使用的典型場景,而後在典型場景下考察上面的靜態結構是如何發揮
          做用的。
        • 接下來要關注進程、線程的結構。
        • 上述四步(規格、靜態結構、典型場景、進程線程)完成後,對程序的第一次泛讀完成。檢驗是否達成目標的方法能夠很簡單,若是真的基本讀懂了,這時應該可以單靠紙筆描述出程序典型場景的 Sequence 圖。
      • 有兩個基本技巧老是須要的,一個是要掌握具體程序裏內嵌的 Log 機制,要能看 Log,必要時可能還得加 Log;一個是基本調試方法。同時一個合適的代碼閱讀工具會對提高代碼閱讀速度有所幫助,好比:一款名叫 SourceInsight 的小工具中能夠把窗口分拆爲幾個部分,點擊任何方法的時候,這個方法的實現以及 Calls Graph 均可以被自動展開,這樣的小功能無疑的對閱讀代碼是有幫助的。
    • 4.2.4 從那門編程語言開始學習?
      • 學習階段學習語言的目的是爲了掌握編程的基礎概念並能更快速的學好另外一門語言。顯然這仍然是打基礎的範疇。
      • 只有一門語言是必須學的,那就是 C
  • 4.3 如何順利的成爲高手
    • 4.3.1 高手的定義和養成關鍵
      • 軟件的三個基本特徵(技術更迭快、低介入門檻、多內部分野)就像鍘刀同樣,一旦選擇出錯,就會把我的的努力切的粉碎,一點價值也留不下來。而與此相對的,則是人的黃金學習時間其實並很少---不過是畢業後的 10 年左右的時間。
      • 爲了在成爲高手這條路上走的順暢,事實上有三個關鍵點:一是要有一張全局性的地圖,以便選好方向;二是要知道都有那些坑,好繞開它,省得掉進去。三是要有足夠的熱情和動力,能堅持走下去。
    • 4.3.2 全局性的地圖
      • 清代著名學者曾對知識地圖的必要性作過很是精確的表述:凡讀書最切要者,目錄之學也。目錄明,方可讀書,不明,終是亂讀。--- 王鳴盛,《十七史商榷》目錄便是地圖
      • 契約式編程
      • 《人件》
      • 隨着待解決問題愈來愈複雜,通用的領域知識中,幾種技術每每會組成一種技術 Stack,他 們 更 需 要 被 看 作 一 組 必 須 一 起 掌 握 的 知 識 , 比 如 : LAMP(Linux+Apache+MySQL+Python/PHP)
      • 讀書無疑的能夠加速一我的增值的過程,記不得是誰說過:實踐無疑是人類最好的老師,但只靠實踐來認知世界無疑也是愚蠢的。這是很是精闢的。除此以外,要想培養大局觀,那就非讀書不可。
      • 有一本頗有名的書對培養技術的大局觀有幫助:《代碼大全》。
      • 基於上面這樣的一張地圖,咱們就能夠具體的去考慮幾條進階路徑。
        • 1. 路徑一:由程序員而架構師
          • 假設說一我的已經掌握了一門或幾門編程語言、面向對象、設計模式、可以很熟練的寫出質量較高的代碼,接下來他想成爲架構師,這個時候他須要作什麼?我我的認爲,這時候這我的首先要有一個「專業」。這個專業能夠是「金融」,「財務」,「電商」,「管理」等等。這是一種屬於某一專業的領域知識,而不是編程技術。若是把需求和最終的代碼,當作描述同一事物的一體兩面,那麼設計始終是要架起這二者間的橋樑。而架橋的時候,怎麼可能只知道一端而不知道另外一端。
          • 接下來是深化設計所須要的各類通用領域知識(UML、面向對象、性能確保等)。
          • 最後一點是,作架構設計已經相對於在作技術管理工做,至少要適當涉獵估算並能作出合適的任務分解,這樣一旦日程緊張,則能夠經過增長人手等手段來在質量、成本和進度之間進行均衡。
          • 架構師所須要達成的最終目標能夠形象的描述爲:產品經理考慮用戶和市場創建了一個模型,那麼架構師要能把這東西映射到技術的世界裏來。若是是在互聯網行業,那麼在你的主導設計下要能夠作出高併發的網站。換到其餘行業也與此相似,從產品的的角度往回看,架構師要能解決和技術相關的全部問題,主導完成商業上有價值的產品或項目的開發工做。實現手段上倒並沒有限制,能夠是購買,能夠是組織人員進行開發,只要能平衡短時間和長期利益,解決特定的問題便可。
        • 2. 路徑二:由程序員而 CodeGuru
          • 這條路線裏,程序員並不把本身擅長的領域擴的太寬,但在指定領域上會挖掘的很深。驅動、字庫、圖形庫、算法庫、OCR 等都偏向於這一領域。
          • 成爲 Guru 的最簡單方法?
            有一條成爲 Guru 的捷徑,而且可能能夠比較好的實現本身的價值:選定一個應用比較廣的,有深度的開源項目,讀通它的代碼,參與進去,在社區中累積本身的聲譽。
        • 3. 路徑三:由程序員而純管理
          • 從須要讀的書來看,這時候可能要看過 PMBOK,《項目管理修煉之道》,《管理的實踐》,《基業長青》等等。
          • 拋開機緣這類東西不論,作好管理工做有兩點很關鍵:
            • 一是要把技術工做作的相對比較好。過分務實的人容易迷失於道路,過分務虛的人則容易飄的過高而喪失根基。管理者正應該身處在這二者之間的一個平衡點。
            • 二是要可以借勢。要情商比較好,能把不少人組織在一塊兒。這個時候要知道那些東西須要規則化,那些東西須要靈活把握。過分偏向規則是教條,過分偏向靈活則是人治,平衡點始終要根據具體人員的情況,工做特質這些不可改變的事情來把握。這有點微妙。但即便
              程序員這個羣體相對簡單,但並不能推翻先人後事這類規則。這不知道是否是東方特點,當你想作管理並想推動事情的時候,終究要理清人際上的關係,不然就和可能會欲速則不達。
          • 管理者須要有產品的視角對於公司而言,產品每每由於和現金流更近而有更直接的價值,而技術之因此有價值則是由於他每每是產品構建中最關鍵的一環。因此說大多時候是技術服務於產品,而非是產品服務於技術。而過於關注於技術的程序員則每每倒置這一關係,試圖讓產品服務於技術。
    • 4.3.3 避開增值路上常見的「坑」
      • 1. 學習失去焦點
        • 這裏想代表的是,一旦誤讀了知識與目的間的因果關係,那麼學習就會失去焦點,進而形成負效應,畢竟相對於人的可承受負荷而言,這個世界上的知識不是太少,而是太多。
        • 通常的認識是隻要學習就必然有所得,因此對人生的影響必定的是正面的。但實際上這個想法是偏頗的,尤爲是在軟件行業裏。在軟件行業中,這種風險之因此異常突出,就在於前面提到過的軟件的兩個特質:更迭速度快和子領域衆多。這兩個因素致使軟件相關的知識是爆炸性增加。
        • 避免「失去焦點」這一陷阱的第一關鍵則是分類:對軟件開發進行分類,對軟件所關聯的知識也進行分類,造成本身的大局觀和總體視圖。
          • 算法領域中,最經典的書籍恐怕是 Donald Knuth 的《計算機程序設計藝術》。
          • 這裏最關鍵的就是聚焦,聚焦的根本則是要在限定時間範圍內創生價值。
      • 2. 學習與實踐相分離
        • 解決艱難問題時,天分很重要;解決複雜問題時,練習很重要。
        • 根據統計最多的 Bug 是由新手致使的。這從側面說明,能作和能作好之間的鴻溝須要大量的實踐來填平的。
      • 3. 「博」與「專」上的迷失
        • 對於大多數軟件開發人員而言,要去尋找廣博與精專間的均衡點:既不能閉上眼睛,也不能就用顯微鏡來看世界。而這一均衡點的價值則可用反木桶原理來講明:木桶原理說的是桶裏的水是由最短的一塊板決定的,但考量人的價值時倒是適用於反木桶原理,即人的價值每每由最長的一塊板決定。
        • 此外,考慮博與專平衡點時彷佛有一種特例,鑽研特定算法的人,從一開始就只往專的方向發展,並不會考慮其餘。好比:鑽研 TTS 的人,可能幾十年如一日只要專一於 TTS就完了.
        • 總的原則是要以當下工做爲根基,以實用爲目的甄選各類知識,並追求平衡點。
        • 學習軟件工程的時機與必要性簡單來說越是沒實踐經驗的人越不適合學習軟件工程,越須要規劃總體把握全局的時候越須要學習軟件工程。
      • 4. 錯過人生中的好時機
        •  學習自己無疑的是須要順應這種天然規律的。
        • 學習英語的時機和必要性總的來看,程序員學習英語是一項投資回報率相對比較好的投入。從目標上來看,程序員未必必定要口語流利,但最低要達到閱讀英文資料沒有障礙的程度。
      • 5. 中止知識更新
        • 對程序員的增值而言,人生裏最大的陷阱也許是爲安全的假象所欺騙而完全的放鬆本身。
        • 從作產品來看,要想成功,有兩個關鍵維度須要同時進行把握,一是產品的概念完整性的把握;一是用合適的手段去實現這個產品。
    • 4.3.4 給本身找一個驅動力
      • 1. 純物質上的驅動力
      • 2. 興趣的力量
        • 總的來看,興趣能夠分爲兩個層次:一個是淺層次的。好比看到一個遊戲比較酷可能想玩玩,看別人寫博客,本身也寫幾篇;另外一種則是深層次的。好比:愛因斯坦你不讓他思考,他可能感受活着就沒什麼意思了。找到後一種興趣的人是幸運的,但大多數人並無這麼幸運,因此通常所說的興趣都是前一種,尤爲是即將畢業和剛畢業不久的人
        • 我我的感受,越是靠近體力一端的工做越不可能興趣驅動,而越靠近智力一端的工做越多是純興趣驅動。
      • 3. 令人生永動的勢能
        • 若是說物質和單純的興趣不足以成爲一種長久的驅動力,那麼無疑的咱們須要繼續去尋找一種能夠令人生永動的勢能。
        • 《青春》塞繆爾·厄爾曼
        • 青春是一種進取的精神,是一種遠離頹廢追逐理想的狀態。
        • 人的思惟和慾望具備無邊界特質,只要在將來和如今之間製造一種差距,那麼就會產生無盡的勢能,人也就會不斷的前行。而製造這種差距的最佳素材每每只能是理想。
        • 這裏最後想說的是有理想、有鬥志不必定會成功,但無理想、無鬥志幾乎必定會鑄就平庸和失敗,由於細緻想來世界自己歸根究竟是理想主義者的。
        • 動機理論裏最有名的多是馬斯洛的需求層次理論,即:
          • 生理須要:包括覓食,飲水,棲身,性和其它身體須要。
          • 安全須要:保護本身免受生理和情緒傷害的須要。
          • 社會須要:愛、歸屬、接納和友誼。
          • 尊重的須要:自尊、自主和成就感;地位、承認和關注等。
          • 自我實現的須要。
        • 上面的內容則主要參照了人民大學出版的《組織行爲學》一書。
第五章 程序員的表達力磨礪
  • 5.1 表達力的類別和做用
    •    表達力和技術技能不是一種對立關係,而是一種疊加的關係。從純量的觀點來看,疊加後的高度,纔是一我的表現出來的高度。
    •  一提表達不少人會想到溝通,尤爲是言語溝通,但這是一個很是巨大的誤解,表達力並不是只限於語言,現實亦可爲表達做證。當面對一個陌生人的時候,更多人會採用察其言觀其行的方法。這時候每每行重於言。也就是說,但凡影響一我的在他人、在組織裏的形象的東西皆可視爲一種表達。
  • 5.2 改善表達力的途徑:在本書中,咱們認爲四個因素對一我的的表達力有關鍵影響,它們分別是:資歷、性格與習慣、借勢與公司政治。
    • 5.2.1 給本身一點資歷
      • 用心來想,資歷之中主要包含了三個方面的力量:忠誠、信任與對既有規則的熟悉和對既有人員的熟悉.一我的最終表現出來的能力事實上有兩個關鍵支撐,一是能作什麼所對應的能力,一是工做意願,二者相乘纔是一我的表現出來的能力。
      • 資歷有助於體現我的能力,因此要給本身一點資歷,只在完全沒有但願的時候換工做。不然會損失掉資歷背後的力量。
    • 5.2.2 去除性格和習慣中的致命缺陷
      • 性格決定人緣,而人緣影響溝通成效,最終影響一我的的表達力。
      • 1. 人情練達
        • 傲氣與狂妄的差異:程序員是須要有點傲氣的,一點傲氣都沒有的程序員每每就會失去對技術的追求並失去對本身的信任。這在技術上是很致命的。但狂妄則是走向滅亡的前兆,要引發警覺。
      • 2. 有條件的順應環境
        • 作點事情其實遠比想的麻煩,即便是在開明的公司裏面,惟有抱怨最容易,但抱怨什麼也換不來。
      • 3. 去除致命的壞習慣
        • 忽視細節
        • 推卸責任
    • 5.2.3 善用借勢
      • 1. 借勢的價值
      • 2. 借勢的具體方法
        • 關於 Instagram 如何成功想必有不少細節,但從公開報道來看,技術上的完美借勢是很關鍵的一個緣由。這從其開發團隊所遵循的原則就能夠看出來:
           Keep it very simple(極簡主義);
           Don’t re-invent the wheel (不重複發明輪子);
           With proven and solid technologies when you can (能用就用靠譜的技術);
          兩個技術水平差很少的人,一個信奉什麼都從頭造,一個信奉儘量用現有靠得住的技術,那麼無疑的從「表現力」的角度看,後者佔優。
    • 5.2.4 瞭解一點「政治」
      • 1. 程序員躲不開「政治」
        • 爲何大公司的錢不能隨便要?
        • 這裏面的規律能夠簡單描述爲一旦一個公司發展起來後,內部必然伴隨着某種勢力格局,這種勢力格局就會衍生出政治。只有在公司初創,高速成長期,這類氛圍纔可能比較淡薄.道理很簡單,打仗的時候首先考量的是一個將軍是否是能征善戰,和平時期則不僅要考慮一我的是否是能征善戰。
      • 2. 可參考的「政治」手段
        • 印象管理:印象管理講的是如何控制本身的表現面。當進行這類印象管理時每每須要必定程度的自我監控。總的來看原則卻並不複雜:誠實的宣傳本身,更多的得到承認。
        • 常見的權術手段
          • 合法性。
          • 理性說服。
          • 鼓舞式訴求。
          • 商議。
          • 交換。
          • 我的式訴求。
          • 逢迎。
          • 施壓。
          • 聯盟。
        • 從代碼裏你能夠看到政治麼?純粹的程序員從代碼裏只看到技術,因此大多時候會抱怨:誰寫了這麼垃圾的代碼?但懂點微觀經濟學的程序員則會在技術以外從代碼中看到利益糾葛,看到人心世道。爲何世界上會有這麼多垃圾代碼,這絕對不僅是由於技術不行。若是世界只由技術因素主宰,那麼按理說只要一個軟件存在的時間足夠長,投入的人力足夠多,代碼必定會變的足夠好。但事實偏偏與這相反,存在時間越長的代碼每每越垃圾。這能夠簡單理解,既存的代碼表徵着一種市場價值,若是改了它那麼一旦形成的損失誰來負責?程序員來負責?總經理來負責?沒人來負責,那麼只能破壞邏輯清晰性來保證穩當性,代碼天然就會變得愈來愈垃圾。因此說這裏首先是利益糾葛問題。這是很是有意思的一個課題,由於改好代碼長期有收益,短時間必然有風險 --- 再牛的人也沒辦法保證本身的修改毫無誤差。宏觀來看,保證好代碼真的很簡單:找一幫有責任心的很牛的人,讓他們不考慮市場因素的持續進行重構,那代碼必然越變越好。而關鍵則是,若是你是 CEO ,你願意這麼幹麼?因此說在市場經濟裏面,每每並無純粹的技術。這樣一來,政治的存在也就不是什麼值得奇怪的事情了。固然開源極可能是例外的。
  • 5.3 檢查本身的表達力
    • 假設有一個你很想作的項目要開始了,你的技術能力是足夠的,你想在這個項目裏承擔比當前責任範圍更大的工做,這時候在有競爭者的前提下你有多大把握得到參與這個項目的機會?這個時候若是答案是絕對沒問題,那麼表達力上大體是沒什麼問題的。若是是沒可能,那麼表達力上是頗有問題的,須要作點檢討.
    • 若是想系統的作個檢查,那就要按照上述所說逐項進行檢查:
      • 本身換工做的頻度是否是過高了?
      • 本身是否是個惹人厭煩的人?
      • 本身有沒有一點影響力?
    • 怎麼斷定本身是缺表達力,仍是缺技術力,則並非很難的事情。大多數人只要在夜深人靜的時候仔細想一想過往,大體就能夠找出答案。若是答案仍然模糊,那麼能夠作張表,給本身的技術力在公司裏排排位置,若是已經排的很靠前,而且掌握前面所說的知識地圖中大部分知識,但職業路徑卻不暢,那基本上是缺表達力了。
第六章 程序員的稀缺性營造
  • 稀缺性同時受兩個維度上的力量影響:一個是自身的努力,好比前文所提到的增值和表達力;一個是大環境的變化以及對這種變化的適應。
  • 6.1 稀缺性可帶給你什麼
  • 6.2 改善稀缺性的途徑
    • 6.2.1 奔向程序世界裏的價值高地
      • 投資大師巴菲特先生說過一句流傳很廣的話:有的企業有高聳的護城河,河裏頭還有兇猛的鱷魚、海盜與鯊魚守護着,這纔是你應該投資的企業。這句話很是傳神的描述了價值高地的外在形象。
      • 無論是那種方向,最終都要達成這樣一種效果:你能夠完整的搞定一件頗有商業價值的事情,而這件事情大多數人搞不定。
    • 6.2.2 走在技術大潮的前面或裏面
      • 若是回望十年,咱們就會發現,先有 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)和互聯網中選擇,我我的認爲互聯網比客戶端更有優點。
  • 6.3 檢查本身的稀缺性
    • 若是想比較系統的評估本身的稀缺性,那麼須要依次考慮以下問題:
      • 本身所掌握的技術是即將過期的技術麼?爲保持對技術動向的敏感度,按期閱讀別人的架構很是關鍵。
      • 本身所掌握的技能究竟有多少人會?。好比:單純的會用 ASP.net開發網頁幾乎沒有較高的技術壁壘,但對數據庫的設計有至關程度的掌握、可以較好的經過負載均衡、緩存等手段保證系統的性能就能夠使本身的稀缺性上個臺階。
    • 軟件相關的知識實在是太龐雜,無法設計一條惟一的道路,但稀缺性好很差卻能夠大體評定:考慮一下一個新畢業生達到本身這個高度,須要多久。若是和新畢業生三年後所能達到的高度類似,那就怎麼也不是稀缺性好的位置。
第七章 程序員的公司選擇
  • 在武俠的世界裏,幫派自己藉助了我的的力量而成其威名,但反過來我的卻又由於幫派的力量而被烘托的更高。若是咱們把公司類比爲幫派,把程序員類比爲一衆江湖人士,那麼幫派和成員間這種異化、同化的過程就幾乎在每個程序員的身上均可以看到。牛頓說過一句廣爲流傳的話:若是說我比別人看得更遠些,那是由於我站在了巨人的肩上。選擇在什麼樣的公司裏工做,幾乎等價於選擇站在什麼人的肩膀上。再形象點講就是選錯了公司等價於輸在起跑線上。
  • 7.1 給公司分類
    • 7.1.1 分類的方法
      • 分工所處位置的視角:幫派間是有食物鏈的.相似的關係也存在於公司與公司之間,但這時這種關係則是有產業分工時公司所處的位置所決定的。
      • 這種鏈條的一個根本特徵是上游的企業人少但分享的利潤更高,固然其承擔的創新風險也更大。
      • 行業的視角
        • 很難講那個行業相對另外一個行業具備絕對優點,但有兩點須要額外注意:一是軟件是否是公司的主營業務對發展空間每每會造成必定限制。製造業的工廠裏也作軟件,但不太可能選幾個作軟件的去作廠長,金融公司里程序員也很難發展成爲總裁。另外一點是有的子行業處在成熟期,發展相對平緩,而有的子行業則處在高速發展期,發展很迅速。
      • 時間軸的視角
        • 選擇發展期的公司仍是選擇成熟期的公司上,要依賴於我的選擇。一般來說選擇成熟度較高,市場地位較高的大公司會比較好,便於作技術積累。
      • 核心競爭力的視角
      • 地域的視角
      • 公司文化的視角
      • 人生中的關鍵選擇與公司分類:程序員的一輩子中會有幾回很是關鍵的選擇。第一次關鍵選擇每每是你畢業後加入了什麼樣的一個公司。第二次關鍵選擇是畢業後的 3~5 年。。此次選擇極可能是關於換工做換行業,也多是關於選擇持續作技術仍是轉到管理方向,或者二者都有。 3~5 年間,不一樣人的累積能夠差到很懸殊的地步,上面的兩類選擇只對其中表現比較優秀的纔有現實意義。沒有積累的,每每既沒有選擇管理的機會,也沒有換工做換行業的機會,或者說即便換工做也只是表面的變化,而工做的內涵則很難變化。由於這段時間必定程度上仍是在打基礎,因此多少還有轉換子行業的機會,在此以後就很是困難了。第三次選擇是畢業後 10 年左右。此次選擇是關於保持生活現狀,仍是打破現狀,進行冒險。比較優秀的人在這個時候,每每會有必定成績,極可能算是比較中層的位置。但接下來的生活極可能變得重複性比較強。這時一我的能夠選擇換一種活法,仍是持續本身現有的工做和生活風格。固然就像武俠的世界中有沒有品級的高手同樣,這世界上也老是有例外和英雄豪傑,大學生也能夠創業,開創本身的商業帝國。上面只是正常的情形罷了。
    • 7.1.2 具體類別的點評:外包行業
      • 若是讓我來排個順序則首先是知名的獨立軟件開發商(ISV),其次是前景比較好的獨立軟件供應商,接下來纔是作高端外包業務的公司,作低端外包業務的公司大多時候不是什麼好的選擇,由於對我的成長不利。
      • 傑克•韋爾奇 《贏》
      • 外包的根本目的就是節約成本,不是爲了創新等高附加值工做,也就是說經過把附加值低的工做轉移到人力成本相對便宜的地區來下降成本是外包的根本目的。這是一種無可避免的潮流,A 公司作了,A 就能夠大幅拉低成本,B 和 C 也就必須得跟進。
    • 7.1.3 具體類別的點評:互聯網行業:若是說 IT 行業是朝陽行業,那互聯網絕對是朝陽中的朝陽。在這個領域中咱們看到了門戶網站,看到了搜索引擎,看到了社交網絡,看到了各類雲平臺和大數據,但故事應該遠未終結。將來究竟出現什麼樣的產品很難預測,但將來的產品會和互聯網緊密相關這點錯的可能性很低。因此在行業選擇上加入一家以互聯網業務爲核心的公司是不錯的選擇,從發展的角度看很同等條件下要比加入通訊、金融這樣的行業更有優點一點。假如一我的想創業,那這就更是一種必然選擇,互聯網是智力密集型的工做,須要必定資本,但對資本的要求並不高,幾我的拉到風險投資後,假設網站開始創業怎麼也比研發路由器開始創業更適應於通常人一點。這裏面在分類上有一個微妙的地方須要注意,搜索引擎、大數據、社交網絡能夠認爲是互聯網,但挪到互聯網上的 ERP 也仍是 ERP,不能算是互聯網行業,這個差異很大,考察公司的時候要注意。
    • 7.1.4 具體類別的點評:外企
      • 什麼叫透明天花板?職業路徑被封死在某個高度如下,但這種封鎖在可見制度層面又不存在,這就是透明天花板,每每是作到必定高度的人對此感覺的更爲清晰。
    • 7.1.5 具體類別的點評:受非市場因素影響大的公司
      • 這個類別的公司特徵是能夠由於特別的機會(某個大單或某項特別資助)在短期蓬勃發展,但接下來又極可能會在短期轟然倒下。我我的傾向於認爲應該規避這類公司,由於這類公司一般並不會把精力放在產品的開發上,而會放在非市場因素的經營上,這對我的成長並非頗有利,尤爲是走技術方向的人。一旦公司出現危機,那麼我的反倒可能會所以陷入困境。
  • 7.2 選擇公司的方法
    • 7.2.1 使工做和本身的根基契合
      • 不契合首先形成一種浪費,其次會對本身的職業路徑造成障礙。這種選擇錯位,大體能夠有兩種表現。
        • 把本身升級使用,這種情形下公司大多時候不幹,因此狀況很少,但把本身置身在前行無路的情況下卻極可能。與上述例子相比,把本身降級使用由於種種緣由反倒更常見,因此我的主要力爭避免的是別把本身降級使用。
    • 7.2.2 當前可獲得什麼、未來可獲得什麼
      • 對短時間目標和長期目標的平衡能夠從四個維度上進行考察:收入、發展、安穩和興趣。收入、發展、安穩和興趣這四個維度所致使的可能選擇每每是矛盾的。但若是非要給這四個因素按權重排個優先級的話,更合理的結果是:興趣>發展>賺錢和安穩。後二者純屬是我的選擇,很難清晰區分。
      • 在進行其餘說明前,須要補充的一點是這裏說的興趣不是那種很快會來很快會走的興趣,而是說可以伴隨本身一輩子的偏好。興趣之因此大於發展是由於人生要想有高度,必須持續的投入,而要想在一輩子中持續的投入,沒有一個關鍵支撐,那是不可能的。而沒有一種持續的投入,最終可達到的高度就會被限定在必定尺度如下。
      • 而這裏面很可怕的一個陷阱是一旦你選擇了某個領域好比金融,再想跨越到其餘的領域好比說遊戲,那成功概率極低。所以興趣是大於發展、安穩與賺錢的權重。但這裏有個極容易被誤解的東西,那就是雖然興趣很是關鍵,但實際上大多數人其實並無真的興趣,而會把一時的喜愛誤認爲興趣,這種興趣由於會在時間軸上頻繁變化而毫無價值,過多考慮這種興趣會讓本身走入誤區,爲本身形成損傷。這時候要對本身有個清醒的認識,若是本身不是一個對興趣很是執着,而是作什麼都還能夠接受的人,那麼就能夠把興趣的優先級放在較低的位置上。發展之因此大於安穩和賺錢,道理也很簡單。年紀越小,將來越重要,沒有我的價值的提升,將來既不會賺到錢,也不會安穩。
      • 平衡這四點以後,就能夠找到一些大多時候都適用的選擇方法:
        • 知名軟件公司在大多時候在這四個方面能夠達成很好的均衡,是首先考慮的對象。
        • 軟件不是主營的公司在一個或多個方面都有負面影響應該盡力迴避。(我如今就在這樣的公司,幹這樣的活,有共鳴)在《軟件隨想錄》裏 Joel 說的更直接:千萬不要去幹什麼內部軟件,那會把你榨乾。
        • 衰落期的公司、分工上處在下游的公司、無核心競爭力的公司並不是優選。
        • 越有夢想,越想快速成長,就越適合在一線城市工做。
      • 感覺大公司中主營業務的威力?李開復先生的《世界因你不一樣》裏面提到了 .NET 開發在微軟內部扭曲變形的過程:在 2000 年的時候,微軟決定啓動 .NET 計劃,那時候規劃中的 .NET 和咱們如今看到的 .NET 並不相同,那時的目標是基於瀏覽器能夠運行全部的應用軟件,和今天的雲計算概念很是類似(注意這是 2000 年),電子郵件、即時通信、登陸、 Office 、高質量的打印、機器翻譯、人工翻譯等都會被整合到網絡之中。但一旦開始行動時,李開復先生遭遇了「人的問題」(便是政治問題),待整合的團隊有三個: IE 、 MSN Explore 、 NetDocs ,其中 MSN Explore 和 IE 是死對頭, MSN Explore 和NetDocs 由於使用不一樣技術有過節,與此同時,龐然大物 Office 團隊則由於 NetDocs 意圖取代 Office 而恨之入骨。這種複雜的關係致使從各個團隊抽調人員很是困難,最終只有 MSN Explore 被整合到了李開復先生這邊,但這個團隊只有 100 多人,根本沒法開始 .NET 的宏偉計劃。正在這時微軟的一個一個強勢人物:吉姆•阿爾欽回到了公司。吉姆•阿爾欽是 Windows團隊的負責人,1995 年開始一直負責 Windows98 和 XP 的開發,他是 Windows 的狂熱擁護者,一回來就把.NET 計劃批評的一無可取。他說:大家知不知道是誰在付大家薪水?是 Windows!個人血液裏流的是視窗的四色血液。大家呢!難道是冷血的?「他又到蓋茨的面前威脅若是公司執意而行,他就辭職。在強勢威脅後,阿爾欽經過 Windows 的遠景說服了比爾蓋茨。最終結局是取消原來的.NET 計劃,重點仍是 Windows,接下來就啓動了著名的 Vista 的開發。---上面的案例參照《世界因你不一樣》縮略而成。上述這樣的一個案例落在不一樣的人眼裏,看到的東西應該不一樣,多是政治的力量,也多是其餘。這裏我想強調的則是強勢部門的力量。吉姆•阿爾欽這我的爲何有這麼大的影響力?緣由可能有不少,但其中必定繞不開的一條是他所負責的 Windows 是微軟的根基所在,是主營業務。在公司之中每每能夠有不少產品線,但這些產品線每每並不是均攤權重,而是要有君臣佐使。這種差別每每會成爲內部資源分配、職位晉升的影響因素。在這種情形下,無疑的主營業務相關人等會被重點關注。
  • 7.3 小結
    • 讓咱們再回到最開始時提到的問題:是去大公司好呢,仍是去小公司好呢?是去用ASP.net 作 ERP 的公司好呢,仍是去作 Mobile 應用的公司好呢?這時答案已經比較清楚了。對於前者,顯然是去知名的大公司比較好。對於後者,同等條件下,首先考慮下那個與本身的興趣契合的比較好,也就是說本身指望在那個行業裏作長期發展。接下來要考慮迴避掉無核心競爭力的公司。
    • 從起薪看公司的差別
第八章 六個程序員的故事
  • 8.1 一個 40 歲程序員的無奈
  • 8.2 一個普通碼農的退場過程
    • 一、能進大公司就別去小公司,在大公司裏你能接受真正正統軟件開發教育,比到小公司當個什麼啥都幹,啥都不精的主管強。二、不斷的學習,注意技術積累和更新,那是你惟一的資本。三、作軟硬件結合方面的開發,單片機的開發,嵌入式系統的開發,比較有前途並且門檻高。但凡基於數據庫的開發,無論是.NET 平臺的,J2EE 平臺的,VC,DELPHI,PB,VB 都是扯淡,其核心價值是開發人員的經驗而不是技術自己。由於真正的核心技術都在國外,中國沒有,我發現無論那種語言,最好用的類庫或組件都是老外寫的。四、要有個好點的學歷,別像我同樣。畢竟是個高學歷的行業,學歷低人家都瞧不起你,你的發展也頗有限 。30 歲以前,可考慮弄個高程,CCNA,數據庫管理員之類比較有含金量的證書打扮打扮本身,過了 35 歲其實意義就不大了。
  • 8.3 一個關於項目經理的故事
  • 8.4 一個技術牛人的成長經歷(杭州李雲)
    • 李雲是《專業嵌入式軟件開發》一書的做者
    • 我想給出個人職場第一感悟:自學能力是競爭力之本。
    • 個人職場第二感悟:自信能讓你不同凡響,儘管有時的自信有點莫名其妙。
    • 個人職場第三感悟:
      興趣是學習效率的催化劑,培養本身的職業興趣。
    • 個人職場第四感悟:學習應給本身設置虛擬的項目目標,以作項目的形式提高學習效果,只有這樣學到的內容纔會深刻而實用,切忌無目標地學到哪算哪。
    • 個人職場第五感悟:話語權首先來自能力,而不是職位權力。
    • 個人職場第六感悟:難學的技能一旦掌握更具競爭優點。
    • 個人職場第七感悟:用階段性成果不斷加強本身的自信,但最終支持自信的是能力,而不是自大。
    • 個人職場第八感悟:作本身喜歡的事,若是那是本身的興趣最好。
    • 個人職場第九感悟:不論身處多麼困難的環境,即便以爲前途渺茫,也不要放棄學習,不然就是「自斷筋脈」。
    • 個人職場第十一感悟:機遇很重要,但你得有能力才能抓住它。
    • 個人職場第十二感悟:職場首先比拼的不是智商,而是堅持與好習慣。
    • 個人職場第十三感悟:當短時間利益與長遠利益沒法得兼時,選擇長遠利益。
    • 個人職場第十四感悟:學歷是很重要的敲門磚,即使你的能力很強;學歷儘管很重要,但能力纔是最終的通行證。
    • 個人職場第十五感悟:技術細節掌握得越深,解決問題時就越能遊刃有餘。
    • 個人職場第十六感悟:技能的發展應採起深度先於廣度且交替進行的方式,只有這樣,面對大量的新知識才能更淡定。
    • 在個人職業生涯中,我一直熱衷於去解決別人難以解決的技術問題,這是由於個人職場第十七感悟:越難的技術問題,其所蘊藏的知識越豐富,也越具學習價值。
    • 在職場中,我不時能成功解決複雜問題和克服技術障礙。這與個人職場第十八感悟是分不開的:每次積累的點滴知識,必定會在未來不知不覺地發揮效能。
    • 我始終堅守個人職場
      第十九感悟:經過文檔化的方式傳承知識給後繼者是你的基本責任,由於你做爲後繼者時也但願如此,這也是對本身負責的一種表現。
    • 我職場第二十感悟:別人對你價值的承認,其實不是簡單地根據你的自身能力,而是根據你對他人和團隊的貢獻。
    • 對於自認爲英語據說能力不行的同仁,請記住個人職場第二十一感悟:英語的據說能力只要有合適的環境,並敢於張嘴練習的狀況下能快速地提升,沒必要擔憂。
    • 個人職場第二十二感悟:在軟件開發活動中,應設法經過有效的技術途徑去解決工程困境。
    • 我從亮身上學到的第一個內容是如何與美國管理層打交道。整體說來,Motorola 在軟件開發管理方面非常四平八穩,其管理存在兩大特點,一是爭奪項目的全部權(Ownership),另外一個是質疑(Challenge)。前者使得各團隊職責清晰,不容易出現突發問題或情況找不到負責人;後者使得團隊在工做中有所做爲,不至於讓人渾水摸魚。在面對美國團隊的質疑時,我之前看到的大多管理者都很緊張,總想一味地達到美國方面的要求,但亮在這方面的表現卻明顯不一樣。他告訴咱們(包括 Team Leader):「若是美國提的要求不合理,直接與他們‘掰’」。後來我認識到,美國方面作事其實很講邏輯,只要咱們對於他們所質疑的問題能給出合理的解釋,不少異常事件根本就沒什麼大不了。個人職場第二十三感悟:不要用沉默的方式一味地迎合別人的要求,力排衆議或許纔是做爲的表現。
    • 儘管咱們常將「職業規劃」掛在嘴邊,實際上職場發展真的是一種「布朗運動」。你不知道下一站會是哪、也不知道後面將要從事什麼工做、更不清楚後面會碰到怎樣的老闆。在衆多不肯定因素面前,或許參照我一路走來所總結出的職場感悟能讓你不斷地朝好的方向發展。
  • 8.5 一個創業者的十年
    • 不是創業很差,而是說輸不起的人不適合創業,而很不辛大部分人實際上是輸不起。
    • 戴志康和他的 Discuz!
      • 創業的初期,技術、資金、人脈、主意等等,均可以當作是一個個籌碼,創業者所主要要作的就是要把你的籌碼轉換爲持續不斷的現金流。隨着現金流的不斷放大,這我的的創業故事也就愈來愈成功。
      • 在考慮創業前,在考慮巨大收益前,要考慮本身是否是付得起創業的基本代價。
  • 8.6 一個女程序員的編程之旅
    • 工做與生活的關係:工做與生活究竟應該是怎麼樣的一種關係?這又是一個沒有也不該該有惟一答案的問題。人生不少事實際上是個可伸縮的模型。理想重要麼?固然很重要,但當餓到必定程度時,對絕大多數人,理想就沒有饅頭重要。工做比生活重要麼?生活比工做重要麼?一這麼考慮問題,腦子必然永無寧日。若是把活着定義爲生活,那麼工做實際上是生活的一部分。一我的最好的時光每每是在工做中度過的。但工做確實和家庭生活有對立的一面。人的時間就那麼多,一邊花的時間多,一邊的時間必然就少。若是咱們相信吃飯是人生最關鍵的事情,也相信貧賤夫妻百事哀這樣的俗語,在沒有完全的財務自由以前,家庭裏至少要有一我的要工做優先。這很功利,但沒辦法。當代中國,家庭的基本模式幾乎是固定的:兩個獨生子女組成家庭,一旦有了孩子以後,要麼一人不工做,要麼從父母雙方得到幫助。而隨着上一代人的老去,自身的責任必然加劇。在這事兒上大部分人選擇權真的不大,必須工做優先,這是一種現實約束。在這個步驟裏,家庭要爭取本身的選擇權,無疑的爭取到了財務自由的家庭是幸運的,他們能夠從新規劃本身的生活模式。這個時候仍然能夠選擇繼續工做,但意義已經不一樣,並不是是由於外部的什麼壓力才這麼作,更主要的是由於本身想這麼作才這麼作。這是一種值得指望的狀態。從這個角度看,在人生這個舞臺上,年輕的時候一我的所扮演的角色是帶着面具的,只有財務自由後的演出纔是本色出演。
  • 8.7 觀罷六段人生,體驗是非成敗
結束語
相關文章
相關標籤/搜索