駕馭你的「職場布朗運動」

在個人博客空間內，不時會有在校學生就任業發展和學習方面的內容向我尋求幫助。同窗們因爲初入社會沒有行業經驗，加上在校所學內容又廣（但不深），因此在擇業方面很容易產生困惑。在擇業觀上，他們但願找到一個未來有前途的行業，也但願在「是選擇大公司仍是小公司」這類問題上有人給予參考意見，也有人擔憂本身的學歷對未來職業發展的影響。

 
另外，在個人工做中，也不時會有同事就本身的職業發展與我探討。他們幾乎都是對技術頗有追求的「有爲青年」和已經走上技術管理崗位的負責人。與在校學生的困惑有所不一樣的是，這些人已經選擇了通信行業，也有了好幾年的工做經驗，但卻苦於在工做中很難發揮本身的特長和精進技術，或在技術管理崗位上擔心本身未來的競爭力。此外，也有些同事對未來是走技術線仍是管理線充滿着困惑。
 
對於全部的這些迷茫也好，困惑也好，我想借這篇文章談一談本身的見解。但怎麼談呢？這類話題能夠說是老得不能再老了，但又新得不能再新— 由於每個人都具備本身的獨特性，在離開學校以前或參加工做以後又有着本身特有的經歷和感悟，於是所面臨的問題也會別具一格。
 
時至今日的職場生涯中，每當我與同事分享本身的成長經歷，總會有人爲之振奮（但願你讀這篇文章時也能感覺到），或許以個人成長經歷做爲本文的寫做主線是一個不錯的選擇！經過這篇文章，你能夠看到一個1997年畢業的大專生（畢業於南昌水利水電高等專科學校，現改名爲南昌工程學院）、一個在高二時英語還只考29分的人，是如何一步一步成爲Motorola的軟件架構師。
 
在繼續讀下去以前，讀者應認識到一點：我的觀點的獨特性與自身的成長經歷有很大的關係。所以，千萬不要盲從，而應時刻保持一種批判接受的態度。或者說，你得有本身的觀點，你（也只有你本身）得對本身的職業發展負責！另外，文章主線是自傳形式，若是你對個人成長經歷不感興趣，能夠快速地略讀，只關注文中加粗的部分。
 
故事的開始得從大學之前開始。從小受「學好數理化，走遍天下都不怕」觀念的影響，我認爲只要學好數理化就好了，因此偏科很嚴重，高二時英語還考過29分。那時也不愛讀書，高三時，別的同窗在複習，我卻在看《晶體管技術》這類電子技術書。這種狀態，直接的結果就是第一次高考落榜了。
 
落榜的那個暑假，父母爲個人出路沒少操心。在一天早晨刷牙時，當我媽對我說但願我去復讀時，我當時腦海裏想「能象表哥那樣考上大學那該多好啊！」，在這個念頭驅使下，我答應了去復讀。從那天開始，我頓悟了，真正知道本身要什麼了。在復讀的一年裏，我學到的一種重要能力是— 自學，這爲之後大學乃至職場學習打下了很好的基礎。正因如此，我想給出個人職場第一感悟：自學能力是競爭力之本。
 
通過復讀，高考總成績提升了100多分，但也只夠專科線。最終，我被南昌水利水高等專科學校錄取，專業是「供用電技術」。這個專業相信不少人不知其然，其實就是電力自動化的變種專業，其專業內容主要是電站、發電廠高電壓的繼電保護技術。
 
大學讀書期間，我開始有與人在成績上一爭高下的念頭了，加上覆讀一年所得到的自學能力，以及本身的努力，學習至關輕鬆，尤爲是隻要與電子技術沾邊的課程，都能輕鬆地拔得頭魁。三年共六個學期的學習，我拿了五個一等獎學金，一個二等獎學金。畢業時，我是系裏惟一的一名優秀畢業生。期間經過了大學英語四級考試和計算機二級考試，得到了江西省電子技能比賽一等獎。須要說起的是，在大學期間所學的與計算機相關的課程只有：《電子技術基礎》、《計算機組成原理》、《計算機軟件基礎》、《單片機技術》和《Basic編程語言》。
 
在大學期間，我完成了人生很重要的一件事 — 找好了如今的妻子。因爲她是浙江人，因此畢業時工做地點絕不猶豫地選擇了杭州。那時不少同窗的工做仍是包分配的，而我來到了杭州的人才市場進行雙向選擇，那時找一份工做仍是相對輕鬆的（注：咱們大學錄取那年的招生人數是90多萬），投出一份簡歷就找好了工做。第一個工做單位是一家不到100人、地處杭州花港觀魚對面（三臺山）的電力設備製造民企。
 
儘管選擇去這家民企後立馬到公司去作了實地調查，但因爲沒有社會經驗，加上被問的人沒如實反應，因此進入這家民企後所瞭解的狀況讓人大跌眼鏡。另外也瞭解到單位會經過一些不入流的作法控制咱們的戶口，不讓咱們跳槽（那會兒的戶口仍是至關重要的，結婚要戶口證實，有同事就由於戶口被控制而登記不了）。而咱們在進入這家單位時簽定了六年的勞動合同。在這樣的小企業幹上六年意味着什麼？！當時與家人打電話告知這一情況時，我都哭出來了（就在如今楊公堤與虎跑路交叉的、現早已不存在的一個電話亭裏，記憶猶新呀！）。
 
儘管前途是那樣的渺茫，但帶有「優秀畢業生光環」的我仍堅信本身能作得比別人更好，由於有個人職場第二感悟：自信能讓你不同凡響，儘管有時的自信有點莫名其妙。在這個企業一開始的工做職責是電站設備的電氣設計工程師，須要用AutoCAD（到單位後學的）設計電氣圖紙，並指導工人最終完成電氣設備裝配及調試。期間，企業經營範圍擴大，須要從事電子設備的生產，所以我開始有機會接觸電子技術方面的設計工做。在兄弟單位一同事的幫助下，在一個星期內我掌握瞭如何用Tango（後來改名爲Protel，如今的名稱是Altium Designer）進行原理圖和PCB線路板設計。並且，這一個星期的設計結果最終成爲了電氣產品的一個部件。對於一個畢業不到一年的我來講，這是不小的進步。那時知道了什麼是網絡表、過孔、焊盤等，掌握了不少電子原件的工做原理（有的還本身用麪包板作實驗），明白了作電路板的大體業務流程，還能動手焊接電路板，熟練運用示波器和萬用表進行調試。那段時間，我對電子技術的興趣幫上了大忙，學習起來遠比別人快。當我精通電路原理，能自如運用示波器和萬用表調試電子產品時，別人卻還不明白個人調試動機。個人職場第三感悟：興趣是學習效率的催化劑，培養本身的職業興趣。
 
第一次真正對編程感興趣是從知道PLC（Programming Logic Controller）開始的。當時的電站設備採用了三菱的PLC，爲了配合這一電氣產品的須要，企業社招了一名懂PLC編程的工程師。因爲老闆擔憂咱們相互學技術而「翅膀變硬」，因此明確提出工程師所掌握的技能不能互通有無。當時看到這位兄弟能經過「梯形圖」改變PLC的行爲，真是以爲他太神氣了，仰慕不已。後來經過這位兄弟的私下幫助（哥們呀！），我晚上偷偷地在廠房裏面學習PLC編程。爲了得到良好的學習效果，我設定了對電氣產品的PLC程序進行重寫的目標，且最終達成了這一目標（固然，因爲這個目標不能讓老闆知道，因此個人PLC程序不能用於商用）。個人職場第四感悟：學習應給本身設置虛擬的項目目標，以作項目的形式提高學習效果，只有這樣學到的內容纔會深刻而實用，切忌無目標地學到哪算哪。
 
一年多的功夫，我成爲了某電氣產品的技術負責人，對整個產品的全部技術細節都瞭如指掌，我帶領了其餘幾個工程師實現了該產品的「自主研發」。有趣的一件事是，老闆當時並不知道我已經「翅膀硬了」，想抵賴答應過的8000元項目獎金，年輕氣盛的我在與之拍完桌子以後對其餘工程師下令：「沒有個人容許，誰也不能將電氣圖紙和電路原理圖用於生產」（由於年經，因此二！）。對抗的結果以老闆兌現承諾而了結。這時我隱約地有了個人職場第五感悟：話語權首先來自能力，而不是職位權力（公務員、國字號、壟斷企業的工程師請忽略。你懂的！）。
 
我那時還學會了CRC算法並將之運用於PLC的串口通信中，但對於計算機如何經過串口與PLC通信得到採集數據存在很大的好奇心。因而想到了學習編程語言，並計劃作一個能在計算機上實時顯示PLC所採集數據的軟件。在向PLC編程的兄弟表達了這一想法後，他給個人建議是：學習C語言比較難，Basic語言則更容易。因而，我絕不猶豫地選擇了自學C語言，由於我深信個人職場第六感悟：難學的技能一旦掌握更具競爭優點。
 
也正是從那時開始，我真正開始了成爲軟件工程師的自學旅程。那時比較幸運的是，單位專爲我配備了工做電腦，因此具有了自學的硬件條件。因爲那時Internet還不普及，學習書籍都來自浙江大學的科海書店（後來眼見着它的店面愈來愈小，這也是進入電子商務時代的一個縮影），那時隔三叉五地到科海去找書，生活最大的花費就在於購書（那時這方面的書很多是質次價高）。固然，學習的過程或多或少還得瞞着老闆。那段時間，別人午休我就編程，除了看書和作書後的習題，還一直朝實現本身的計算機監控軟件這個目標邁進（參見個人職場第四感悟）。終於有一天，我用Turbo C在DOS環境下實現了具備串口通信功能的、基於圖形界面的監控軟件（若是你用如今的眼光看那個軟件，必定會說「很土」）。當我樂此不疲地向他人演示時，你能夠想象我那時有多高興和自豪！這種小小的成功滋長了個人信心，也讓我感覺到了個人職場第七感悟：用階段性成果不斷加強本身的自信，且最終支持自信的是能力，而不是自大。嚐到了成功甜頭的我隨後拓展了本身就軟件開發方面的學習內容。那時的我已經下定決心要向軟件開發方向發展，這種選擇是由於個人職場第八感悟：作本身喜歡的事，若是那是本身的興趣最好。
 
1999年的某月，在企業拖欠了一個月工資的情形下，「蓄謀」逃離企業束縛的咱們（共19個工程師）通過幾個月的勞動仲裁後，與企業解除了勞動合同。在離開這家民企的次日，1999年11月的某天，我在浙江大立機電技術開發公司（即如今的大立科技。後面都簡稱爲大立公司）找到了第一份專職的軟件開發工做。我逃離束縛後能很快地找到新的支點，徹底得感謝個人職場第九感悟：不論身處多麼困難的環境，即便以爲前途渺茫，也不要放棄學習，不然就是「自斷筋脈」。
 
在大立公司所參與的第一個軟件項目，是使用Visual C++從事Windows某變電站圖像監控桌面軟件的開發。儘管我以前自學過C++語言，但那時並未徹底掌握面向對象編程，尤爲是其中的多態。我在該桌面軟件中借鑑微軟的示例軟件DrawCli，獨立地實現了電子地圖功能。正是經過掌握這個示例軟件的設計與實現，我真正領悟到了面向對象設計的好處。也經過該圖像監控桌面軟件的開發經歷，掌握了Windows VxD驅動開發、socket通信、多線程編程、圖像處理（銳化、僞彩處理、圖像字符識別和圖像對比等）、ODBC數據庫編程（用的是SQL Server）等。
 
這裏要插一個與我妻子相關的小故事。她是我大學的同班同窗，畢業之後進了諸暨供電局從事農網預算工做。我在第一家民企工做時，時常往返於兩地，有時以爲非常辛苦。另外，妻子在供電局安逸的工做環境下，時常會開玩笑說老了要是下崗了都不知能幹什麼。在我進入大立公司不到一年的時間裏，我向公司提出了能否讓她到公司來從事軟件開發工做。當時在我妻子沒有任何面試和編程經驗（她當時只自學了譚浩強老師的《C程序設計》和一本C++的書，忘記書名了）的狀況下，公司讓她過來了，我想這是緣於公司對個人器重（這裏要謝謝龐總和章總兩位老總！）。天然，我成了妻子學習編程的老師。個人岳父岳母當時對於妻子放棄供電局的工做盡管不捨，但仍是尊重了咱們的想法，謝謝他們的開明。支持咱們作出這一決定，除了爲了解決兩地分居問題，還有咱們的職場第十感悟：長期安逸的工做意味着未來更大的風險。
 
在妻子進入大立公司不久，由我擔綱了新版圖像監控軟件的從新開發，這是我第一次擔任軟件項目負責人。在這個項目上，我能夠從技術層面盡情發揮，將我在老版本軟件上所看到的設計不足徹底克服。也正是經過這個軟件項目，個人面向對象編程能力有了很大的提升，並且完整地作過了一個軟件產品。用我如今的眼光來看：那時的開發工做除了引入了版本控制軟件外，是徹徹底底的做坊式軟件開發；至於管理技能的提升，也能夠說是微乎其微。
 
2000年末，大立公司由於業務拓展的須要，需開發嵌入式圖像監控系統（系統中的前端產品是後來數字硬盤錄象機的前身）。爲此，公司社招了一位比我年長十歲的資深硬件開發工程師，他在進公司時已經有基於AMD的Elan SC520 x86嵌入式微控制器的硬件開發經驗。他在進公司之初與章總交談時指出：「作這類嵌入式產品，須要軟件功底很是強的人」，章總的回答是：「你放心好了，我必定找一個最好的人與你搭檔」（章總後來告訴個人）。是的，所找的那我的就是我！而其實那時我只有用Visual C++從事Windows桌面軟件的開發經驗，可見公司領導對我能力之信任！個人職場第十一感悟：機遇很重要，但你得有能力才能抓住它。
 
我當時所面臨的技術挑戰，讀者能夠想象。要知道，在2000年時基於x86微控制器的嵌入式系統的開發人員國內還不多。個人自學能力、電子愛好的興趣在這種挑戰面前又幫了大忙。其實，作嵌入式系統開發最主要的是參考各類資料以便掌握各種技術細節，這得經過大量地閱讀芯片手冊、用戶手冊，以及研究AMD在其官網上所提供的示例程序。在這個過程當中，就技術困惑堅持探究和養成各類好的工做習慣（思考習慣、筆記習慣、總結習慣、閱讀習慣）很是重要。個人職場第十二感悟：職場首先比拼的不是智商，而是堅持與好習慣。
 
我獨自完成了該嵌入式前端產品上的軟件開發工做。其中包含的大體技術內容有：從編程的角度精通x86處理器架構； PCI、IDE硬盤、網卡、串口、閃存等總線或外設的驅動；實時操做系統內核的移植工做；MINUX操做系統的文件系統的移植； XINU操做系統的TCP/IP協議棧的移植工做。移植工做每每會碰到各類技術細節問題，等移植工做完成，對被移植模塊的實現和背後的原理也已瞭如指掌。正應如此，這一時期的工做讓我對操做系統的實現原理有了很深的理解。
 
除了軟件方面的進步，我在大立公司時的硬件知識也獲得了很強擴充。不只能輕鬆地閱讀數字電路原理圖，還自學了VHDL語言，使得拿到邏輯器件CPLD的VHDL程序就能調試軟件（經過VHDL程序，能夠了解編程所需的譯碼端口、相關信號的操做時序等）。還學會了如何使用邏輯分析儀輔助軟件調試工做。前面提到的這位兄長式硬件工程師調侃我說：「你讓我看到了中國軟件的但願！」，而我將這話當成了對本身的鼓勵。另外，這期間還考入了浙江大學專升本的通信工程專業，給本身充電（2001年入學，2004年畢業， 獲 多學期 「優秀學生」和「優秀畢業設計」）。

 
因爲大立公司是浙江省測試技術研究所的子公司，它或多或少帶有事業單位的氣息。加上公司的技術舞臺有限，以及妻子也在同一家公司工做，我於2003年4月份左右離開了大立公司。在我離開以前，浙江省科委已批覆了公司的申請，分配給我一套福利房。在我離開之時，房子仍在建，很多同事對於個人離職非常不解，也勸我拿到房再走。但我有個人職場第十三感悟：當短時間利益與長遠利益沒法得兼時，選擇長遠利益。
 
在大立公司工做期間，很但願本身能入職UTStarcom這樣的通信企業（那時的UTStarcom是多麼地輝煌！）。計劃離開大立公司之際，我向UTStarcom提交了求職簡歷。此次求職開始好像很順利，但到我真正入職UTStarcom的過程卻非常曲折。
 
一開始當我收到UTStartcom的面試通知時，可能太但願能進入這個公司了，在沒有很深刻了解這個崗位的前提下，就去面試了，且立刻拿到了Offer。但後來才瞭解到，我拿到的是生產部測試開發崗位，與實際研發部門是有區別的。 當時很糾結   — 這是我想進的公司，但卻不是我想要的崗位。若是拒絕生產部的Offer，我頗有可能與UTStarcom無緣。考慮再三，我仍是選擇了拒絕（參見個人職場第十三感悟）。並從新向研發部門投了簡歷。

 

通過度日如年的一個多月等待（那會兒恰好發生了SARS疫情），在以爲入職UTStarcom研發部門無望的狀況下，我入職了另一家小公司。使人意外的是，在入職那家公司的次日，我收到了UTStarcom研發部門的面試通知。在HR面試的那一輪中，HR對我說，「你是我所面試的人中最有工做激情的」。那時的技術面試官中，其中一位是我往後入職後的上司 — 夏青（如今是恆生電子通信事業部的總經理），他是個人伯樂。因爲個人學歷問題，在技術面試經過後，別人只要一位VP面試經過就行，我卻須要兩位。個人職場第十四感悟：學歷是很重要的敲門磚，即使你的能力很強；學歷儘管很重要，但能力纔是最終的通行證。
 
2003年6月份左右，我正式入職UTStarcom研發部，從事小靈通基站控制器（後面簡稱爲基站控制器）的軟件開發工做，也今後踏入通信行業。在入職之初，因爲自認爲對於操做系統的原理很精通，又完整地作過軟件項目，有點飄飄然，以爲本身是個「小×××」。然而，入職後一接觸工做就發現，內容沒有想象的那麼簡單！
 
首先，基站控制器的軟件規模比我之前主導開發的項目要大不少，並且須要熟悉通信行業的相關信令。其次，儘管我那時精通x86處理器，基站控制器用的倒是PowerPC 8250，這意味着我得從新掌握它。再次，實時操做系統用的是前美國軍方的、開源的RTEMS，那是我第一次接觸。最後，UTStarcom的工做語言是英語，寫文檔和郵件都得用英語。儘管我那時能無障礙地閱讀MSDN和各種芯片手冊，但要着手寫，倒是一大挑戰（口語不做要求，由於不需直接接觸老外）。
 
一入職所分配的工做是網元網管部分告警抑制軟件模塊的開發。儘管PowerPC處理器和RTEMS操做系統技術細節的掌握與否並不影響平常開發工做，但我仍將掌握它們做爲本身的努力目標，由於個人職場第十五感悟：技術細節掌握得越深，解決問題時就越能遊刃有餘。
 
那時工做時間應付平常開發工做，業餘時間則先將精力集中放在熟讀PowerPC 8250處理器相關的技術手冊上（晚上還得上夜大）。加起來超過2000頁的英文資料，我讀了很多於3遍。隨着時間的推移，當我對PowerPC 8250處理器頗有感受以後，我將工做重點轉移到了熟悉RTEMS操做系統的實現細節上。先處理器後操做系統的學習安排，是基於我以往在x86處理器上的工做經驗而得出的，也是由於個人職場第十六感悟：技能的發展應採起深度先於廣度且交替進行的方式，只有這樣，面對大量的新知識才能更淡定。
 
RTEMS是一個類UNIX的實時操做系統，也正由於接觸這個操做系統我才意識到了本身在軟件設計能力上存在很大的提高空間。儘管我對操做系統的實現原理成竹在胸，但卻無力於構建一個象RTEMS那樣優雅的操做系統，也真切地體會到了RTEMS的設計之美。那時基站控制器上運行的RTEMS操做系統是由美國的新澤西研發中心移植好的，杭州研發中心只需在之上作應用開發。爲了就RTEMS操做系統得到更好的學習效果，我又一次運用了個人職場第四感悟，設定了本身完成RTEMS新版本移植這一目標。
 
RTEMS新版本的移植工做雖不在公司的平常工做範圍內，但卻獲得了上司的支持。因爲那時RTEMS還在開發新的功能，並非很穩定，在移植過程當中碰到各類奇怪的問題，有些問題還與GNU的binutils工具集有關（binutils中包括nm、ld、objdump等工具。RTEMS是用GCC編譯的）。在沒法確認是GNU工具集的問題以前，我甚至還向Wind River公司（其知名產品是VxWorks實時操做系統）尋求過幫助，由於那時用的是它的JTAG仿真器。移植工做雖曲折，但最終仍是成功了（我所移植的版本並無運用到產品中，後來的同事又作過了RTEMS4.6.0pre4的移植，且運用於產品中）。這一移植經歷，讓我對GNU的binutils、RTEMS操做系統的實現有了更爲深刻地掌握。
 
在UTStarcom工做的前期，我大多從事的是RTEMS操做系統相關的代碼維護工做，工做內容除了OS內核，還包括FTP、Telnet等協議。直到中期轉爲作E-Box產品的互聯網接入模塊的開發工做。
 
E-Box是一個企業級電話交換產品，其中還存在一塊基於ADSL的互聯網接入數據板（與如今的ADSL貓功能同樣），用於實現企業網對互聯網的數據接入功能，這一數據板使用的是VxWorks5.5.0實時操做系統（PNE 2.0），處理器是Intel的XScale IXP425。那時VxWorks的IP協議棧仍是基於BSD的，但Wind River對之作了必定加強。這段時期個人工做重點全在IP協議棧上（《TCP/IP詳解》這套書幫上了大忙）。這一時期的開發經歷，讓我對PNE的Bridge、FastPath、MUX、PPPoE協議、Radix路由算法和VLAN協議很熟悉，也學會了用SmartBit儀器和Chariot軟件作網絡性能測試。總之，讓我對IP（v4）協議棧方面的知識和軟件實現有了長足的進步。
 
E-Box產品數據板上的開發工做進行了半年後，管理層決定放棄，因而我被調到了E-Box產品的軟件平臺組。那時平臺組恰好面臨一個比較麻煩的問題 — 在命令行上運行reboot命令後，有時會出現整個系統掛起，而不是指望的重啓。平臺組的同事花了一個多星期的時間仍沒有解決這一問題。
 
進入平臺組之際，一樣是在沒有任何人安排的狀況下，我本身主動承擔解決reboot命令功能異常的工做。在個人職業生涯中，我一直熱衷於去解決別人難以解決的技術問題，由於個人職場第十七感悟：越難的技術問題，其所蘊藏的知識越豐富，也越具學習價值。通過一天半的時間，問題被解決了。其根源在於，reboot以前沒有禁用CPM協處理器。我能那麼快地解決這一問題，徹底是由於以前熟讀過PowerPC 8250處理器的資料。
 
我在UTStarcom工做的後期，致力於ACE在E-Box產品中的一些應用，藉助ACE的網絡通訊功能幫助實如今Windows平臺上經過Visual Studio調試E-Box產品。我在《專業嵌入式軟件開發》一書的《可開發性設計，一種高效且經濟的開發模式》一章中所闡述的內容其實就是這一工做經歷的總結與延伸。
 
另外，我還在E-Box產品上作過難度比較大的一個特性是，利用PowerPC 8250的MMU功能在VxWorks操做系統上實現了對任務棧的保護 — 當一個任務被調度而處於運行狀態時，它的棧就處於可讀寫狀態，而其餘任務的棧全處於只讀狀態（VxWorks5.5.0內核中，尚未RealTime Process的概念，這一律念是從6.0開始有的，因此那時我所作的這一特性很具實用性）。經過這一特性，能夠有效地防止任務棧被意外篡改（好比野指針操做），即使出現篡改也能儘早發現根源。這個功能的實現過程須要調試VxWorks內核，那時VxWorks的源碼雖對公司提供，但Wind River公司對所提供的GNU的binutils作了特殊處理，使得沒法爲內核代碼生成調試所需的信息，結果是沒法對內核進行源碼級程序調試。因爲我以前的RTEMS操做系統移植經歷讓我對binutils很是熟悉，經過使用必定的方法（說來話長了）繞過了Wind River公司所設置的障礙，成功地實現了對VxWorks的源碼級程序調試。
 
在職場中，我不時能成功解決複雜問題和克服技術障礙。個人職場第十八感悟：每次積累的點滴知識，必定會在未來不知不覺地發揮效能。
 
2006年4月份左右，我離開了UTStarcom。在UTStarcom所學到的，不僅是前面所介紹的那些技術知識，更讓我知道了軟件開發的「正規軍」是怎樣的，與小公司相比，UTStarcom的軟件開發流程要正規得多；也經歷了英文寫做的「擠牙膏」時期過渡到輕鬆時期（好友周海東在個人英語學習中幫了很多忙）；看到了好友于善成如何經過大量閱讀成爲一個知識淵博的人（他的閱讀量如今還是個人學習榜樣）；還有上司夏青的技術敏感度到如今仍讓我爲之稱道，是我職場至今所見過的二位具備良好技術敏感度的技術管理者之一（另外一位是我在Motorola工做期間認識的，後面會談到他）；團隊實力之強使得開發出的E-Box產品在我離開UTStarcom後不時能聽到正面的評價。
 
對了，我在大立公司工做時期，就很注重軟件設計文檔的編寫，並且在我離開之時，不只完善了全部文檔，還爲後繼同事作了全面的培訓。我始終堅守個人職場第十九感悟：經過文檔化的方式傳承知識給後繼者是你的基本責任，由於你做爲後繼者時也但願如此，這也是對本身負責的一種表現（文檔的重要性請參見《該死的「代碼就是文檔」》一文）。在UTStarcom工做期間，我進一步造成了將本身的技術想法寫成文章與你們分享的習慣（那時同事賀旭東稱我爲「做家」，而我則稱他爲「點評家」），也由於本身在嵌入式軟件開發技術上的長期點滴積累，開始有了寫書的想法。
 
離開UTStarcom後，我入職了杭州華數集團旗下的雷科通技術（杭州）有限公司。公司當時的意向是安排我負責某寬帶接入產品的軟件開發工做。在這個公司，儘管只有兩個月的時間但也作了些事。除了一個月內完成了寬帶接入產品以太網交換芯片在VxWorks操做系統上的驅動開發，並使得產品支持VLAN功能外，還解決了好幾個影響整個產品系統穩定性的嚴重遺留缺陷。這兩個月的工做不光讓我在技術團隊中很快地樹立了本身的威望，也使得公司高層管理者真切地看到了個人能力而在我提出離開時極力地挽留。這短暫兩個月的工做經歷帶給我職場第二十感悟：別人對你價值的承認，其實不是簡單地根據你的自身能力，而是根據你對他人和團隊的貢獻。
 
入職2006年初在杭州成立的Motorola研發中心的故事得從面試開始。在入職雷科通不久，我收到了獵頭的電話，雖然那時並無換工做的想法，但也沒有拒絕獵頭投簡歷。隨後我收到了Motorola的面試電話。那次面試過程記得很清楚，由於那是我所經歷的第一次英語口語技術面試。雖然工做中從沒有鍛鍊過英語口語，好在對於本身作過的技術知識很熟悉，也常常須要查閱英文資料，因此對於所作過的內容還能用英語勉強解釋清楚。在面試的最後，我對印裔技術面試官說，「如今個人英語口語很差，但我相信只要有合適的環境，能很快地提升」。印裔技術面試官最後將我領到HR那，說了一聲「Yes」 — 個人技術面試經過了！
 
面試結束的次日，收到了Motorola HR的電話，告知Offer的相關信息（個人入職級別是E09，E09及以上的人在整個Motorola杭州研發中心佔比大約爲10%）。那時因爲並無換工做的想法，因此拒絕了Offer。想法很簡單，由於曾在UTStarcom這樣的公司呆過了，因此對外企的工做並非很嚮往，反而認爲在雷科通這種小公司更能施展。在我拒絕了Motorola的Offer後，我將這件事告訴了身邊的同事，他們的反饋幾乎都是「你應當去Motorola」。
 
幸運的是，另外一名HR再一次致電給我，試圖說服我加入Motorola。她當時說「你一旦加入Motorola，之後離開時所看到的就是HP或IBM這樣的大公司」，也正是這句話打動了我。以後的經歷證實，加入Motorola是很正確的一個選擇！
 
2006年7月6日，我正式入職Motorola杭州研發中心。加入的初期是大量的內部培訓，培訓內容包括技術方面的、流程方面的和英語。Motorola有着成熟的企業文化，經過培訓可讓工程師很快地融入企業，令人行事象是Motorolan（摩托羅拉人）。在經歷了約半年的培訓和學習後，2006年末，我開始參與WiMAX產品線上的CLA中間件軟件項目。
 
儘管我在CLA項目上沒有具體的工做（好比，沒有缺陷修復工做會分配給我，也沒有新的特性開發工做會掛在個人名下），但對整個團隊所從事的技術工做都得負責。個人平常工做主要是設計方案評審、代碼審查、幫助或帶領團隊解決技術難題等。
 
在CLA項目上工做了一個月左右，2007年春節以後，我被第一位派到Motorola的芝加哥研發中心作爲期二個月的現場技術支持。以前儘管在公司有過英語培訓，但要很好地聽與說仍是存在很大的障礙，加上芝加哥那邊一塊兒工做的是口音較重的印度人和巴基斯坦人，挑戰能夠想象。在芝加哥研發中心除了作現場技術支持，還得爲後續人員的到來作鋪墊。好比，租好房子、車子，準備好生活所需的一些家當（當時由於預算有限，咱們住的是公寓，還得本身燒飯）。那段時間雖然由於語言的問題倍感壓力，但在全英文的環境中，個人據說能力進步也明顯。以後差很少每一年一次的出國，見到之前認識的外國同事，總會有人對我說「Your English is getting better」。對於自認爲英語據說能力不行的同仁，請記住個人職場第二十一感悟：英語的據說能力只要有合適的環境，並敢於張嘴練習的狀況下能快速地提升，沒必要擔憂。
 
CLA軟件在技術上屬於運行於Linux操做系統上的一箇中間件，它存在多個進程用於幫助通信設備網元（包括WiMAX基站和接入網關）實現網管功能。因爲軟件架構的特色，使得CLA團隊不時會碰到因爲其餘團隊沒有用好CLA而產生的技術問題，這類問題開始大多難以定位是屬於CLA的、仍是不屬於CLA的，於是查錯過程很低效。在CLA項目的後期，我但願經過引入新的軟件設計方案幫助團隊提升軟件的查錯能力，並改善軟件質量。引入新設計須要增長不少代碼，如何讓管理層不擔憂由此而引入更多的缺陷是我着力這事時首先要考慮和解決的問題。
 
在這種背景下，我在CLA項目引入了單元測試，寄但願於經過單元測試提升新增代碼的質量，以使管理層更具信心而得到他們強有力的支持。最終結果代表，在新增了近一萬行代碼的狀況下，代碼在最終發佈後總共只發現了一個軟件缺陷。這個項目上的工做經歷讓我第一次真正嚐到了單元測試的甜頭，在《專業嵌入式軟件開發》一書中，就單元測試方面的內容不少源於我在這一項目上的成功經驗。我在CLA上新增設計中的AED（Abnormal Exiting Detection）功能，在我離開CLA項目以後，還幫助團隊發現了很隱蔽的多線程問題。當經過AED功能發現這一問題的同事高興地跑過來對我說這個功能管用時，個人高興勁寫滿了整張臉。這個項目的經歷，也讓我更加堅信個人職場第二十二感悟：在軟件開發活動中，應設法經過有效的技術途徑去解決工程困境。
 
2009年初，Motorola杭州研發中心迎來了一個重量級項目 — WiMAX產品線的接入網關ASN-GW，我被安排到該項目，角色是軟件開發架構師。初期個人架構師一職只是杭州研發中心單方面的角色安排，而非全球性的（當時該產品由美國、印度和中國三個研發中心共同參與）。
 
在ASN-GW項目上與我一同共事的經理，是曾在Motorola美國研發中心呆了近十年、後來臨時轉到國內來工做的華人李亮（後面簡稱亮，習慣了）。他以前在美國工做時作過架構師、軟件發佈經理（Release Manager）等職，是一個對技術頗有敏感度的管理者（我前面提到過的兩位有技術敏感度的管理者之一）。我在此以後的成長，徹底離不開他的支持與信任，以及他爲我所創造的職場發展環境，能與他共事讓我倍感榮幸和感激。
 
我從亮身上學到的第一個內容是如何與美國管理層打交道。整體說來，Motorola在軟件開發管理方面非常四平八穩，其管理存在兩大特點，一是爭奪項目的全部權（Ownership），另外一個是質疑（Challenge）。前者使得各團隊職責清晰，不容易出現突發問題或情況找不到負責人；後者使得團隊在工做中有所做爲，不至於讓人渾水摸魚。在面對美國團隊的質疑時，我之前看到的大多管理者都很緊張，總想一味地達到美國方面的要求，但亮在這方面的表現卻明顯不一樣。他告訴咱們（包括Team Lead），「若是美國提的要求不合理，直接與他們‘掰’」。後來我認識到，美國方面作事其實很講邏輯，只要咱們對於他們所質疑的問題能給出合理的解釋，不少異常事件根本就沒什麼大不了。個人職場第二十三感悟：不要用沉默的方式一味地迎合別人的要求，力排衆議或許纔是做爲的表現。
 
參與ASN-GW的呼叫處理子系統的開發工做後，整個團隊經歷了大約半年的成長痛苦。痛苦的根源，一是對WiMAX無線接入技術相關的國際標準不熟悉，另外則是對ASN-GW產品的現有實現不瞭解，並且產品的複雜度的確很大（其中一個技術指標是：必須達到99.999%的容錯能力）。在半年的痛苦期中，我很重要的一個工做職責是幫助團隊成長，做爲亮這類管理層與基層工程師間的橋樑。好比，爲團隊起草《開發者指南》和《測試指南》這樣的文檔，且要求和引導工程師經過文檔化的形式沉澱經驗與教訓，以便提升工做效率（雖然文檔化方法的實施過程須要我不斷地提醒，但這一方法被證實在這種時期頗有效）；我也會在例會上絕不留情地指出工程師的哪些行爲影響了工做效率。個人職場第二十四感悟：流程、文檔的做用，不僅是引導咱們作完事，更能規範咱們的行爲和幫助培養工做習慣。
 
亮在項目進展的過程當中，一直向美國方面主張杭州團隊必須設置架構師一職，也正是因爲亮的一再爭取，美國方面最終努力地幫助我向這個方向發展，不斷爲我分派屬於架構師工做的任務（如更新產品架構模型、參與需求管理、參與系統設計文檔的評審、完成新特性開發工做評估等）。亮那時告訴我，我應是杭州研發中心第一個真正從事架構師工做的人。
 
剛接觸架構師方面的工做時，其實仍是不大自信的，儘管我那時掌握了軟件架構師所需的基礎技術技能（好比，個人軟件設計能力很強、UML從1998年開始接觸加上以後的持續學習因此功底也很好），但對於軟件研發管理方面的內容，以及WiMAX無線接入技術知識的系統性認識仍是相對單薄的。那時與美國同事接觸下來的感受是，他們的綜合能力都很強，彷佛隨便一我的都知道如何作架構師，很多人有作GSM、iDen和CDMA產品的經驗，並且長期工做於無線接入技術領域。隨着更多地參與架構師方面的工做，不只逐漸創建了自信，對Motorola的軟件研發管理也有了更爲深刻地認識與理解。所看到的不只僅是產品技術自己的複雜度，更有開發活動運做管理方面的複雜度。最終，我成爲了整個ASN-GW產品的架構師。
 
在2009年，我考入了浙江大學的MBA，同時還開始着手寫本身的×××做《專業嵌入式軟件開發》。在以後長達近兩年的工做、學習和寫做的三重壓力下，我在時間管理上有很大的進步，抗壓能力也獲得了很好的鍛鍊，這時個人職場第十二感悟（指其中的堅持）又讓我最終渡過了這段最爲艱難的時期。（注：《專業嵌入式軟件開發》一書其實不僅專一於嵌入式，其中絕大部份內容是C/C++開發人員應當掌握的。當時書名中採用「嵌入式」三個字徹底是由於給書定位的須要，懼怕書名不具體而令人難以選書。固然，也正由於「嵌入式」三個字，令人以爲面太窄了。有利有弊吧！該書在各大網上書店都歸類於「軟件工程及軟件方法學」，而非「嵌入式系統」）
 
2010年中期，NSN宣佈收購我所在的Motorola網絡部門，收購活動直到2011年的4月份才結束。同時因爲WiMAX市場的不景氣，美國很多系統架構師轉到了FDD-LTE產品線上，我也由於這一緣故擔任了大約半年的系統架構師，主要負責WiMAX技術的移動性與網絡安全方面的工做。
 
2012年7月份，由於WiMAX產品線裁人，我轉到了NSN的WCDMA產品線。也今後開始離開了Motorola的研發管理環境，而真正步入了NSN的研發管理環境。
 
真感謝你花時間讀到這！儘管咱們常將「職業規劃」掛在嘴邊，實際上職場發展真的是一種「布朗運動」。你不知道下一站會是哪、也不知道後面將要從事什麼工做、更不清楚後面會碰到怎樣的老闆。在衆多不肯定因素面前，或許參照我一路走來所總結出的職場感悟能讓你不斷地朝好的方向發展。
 
做爲結尾，我想就幾則網友在個人博客空間的留言進行回答，這樣你也能看到職場感悟是如何被運用的。
 
問：李老師，我如今主要還在校學習，主攻方向是J2EE，課餘時間在自學Android，有時候花不少時間在Android上面，內心很矛盾，到底哪一個發展得更好，能夠指導一下嗎？
 
答：在面對當前紛繁複雜、層出不窮的技術時，學習應運用個人職場第十六感悟：技能的發展應採起深度先於廣度且交替進行的方式，只有這樣，面對大量的新知識才能更談定。我想借助下圖，讓讀者更好地理解這一感悟。

 

大致上，技能的發展是在橫向廣度與縱向深度上進行的。上圖中，從A點發展到B點存在兩條路徑，分別用黑線與紅線表示，其中紅線所表達的路徑更可取。實際上，不管有多麼不一樣的技術，它們發展到最後有不少相通性。採用深度發展優先的方式，能讓咱們在短時間內所關注的技術焦點相對小，使得學習過程不容易焦躁。相反，採用廣度優先的方式，儘管在短時間內會讓咱們以爲學識很廣，但因爲各門技能都不深刻，因此學習過程容易煩躁。在這種狀況下，即便想要深刻也很容易由於瞭解的面太廣、知道要學的內容太多而懼怕不前。
 
須要注意，現實中，從A點發展到B點應是一個深度與廣度發展交替上升的階梯。上圖是爲了說明方便而作了適當的簡化。
 
回到開始的問題，就目前的形勢來看選擇Android或許更好。但不管選什麼，必定不要患得患失，而應在所選擇的技術上作至關長時間的縱向發展。不然幾年下來，發現本身什麼都沒有學好，很容易打擊本身的信心。
 
問：我仍是正在大三的學生，並不是計算機專業，可是對嵌入式比較有興趣。 如今也不明白本身去公司到底是幹什麼，就是本身想學哪就學下哪？自學的路，有時候確實很艱辛！有什麼比較系統的學習方法嗎？感受如今學得很雜，在實驗室，畫畫電路板，學學Linux。 腦殼裏的東西一片混亂！求指導！
 
答：你已經走在了個人前面，我是在工做崗位上才學到你如今所學的內容。至於之後要幹什麼，不是你如今能擔憂好的。放好心態，「兵來將擋，水來土淹」；沉下心來，打好基礎。
 
爲了得到好的學習效果，請不要忘記個人職場第四感悟：學習應給本身設置虛擬的項目目標，以作項目的形式提高學習效果，只有這樣學到的內容纔會深刻而實用，切忌無目標地學到哪算哪。
 
對於嵌入式軟件開發的系統性學習方法，得作下廣告了，向你推薦個人《專業嵌入式軟件開發》一書。花時間把這本書啃透，我相信你能應付不少平常開發工做。（注：有讀者反映讀過這本書後出去面試很輕鬆，但尚未人反映讀後工做很輕鬆，期待後面有人有這樣的反饋）
 
問：李老師，你好！我是一名大一的學生，喜歡編程。學習C語言已經有一段時間了。可是，我感受我仍是寫不出來一段精彩的代碼。我在學習的時候老是敲別人的代碼。可是我想改變這種處境。我該怎麼辦呢？很迷茫啊！
 
答：Oops! 我尚未就這一問題提出過職場感悟，如今補上個人職場第二十五感悟：在模仿中不斷前行，最終造成屬於本身的方法和思想。
 
我相信每一個人都會經歷你所說的這一時期，這是正常的。也是由於咱們所掌握的技能在深度上還不夠。靜下心來好好地學，總有一天你會（忽然間）擺脫這一困境的。相信我！
 
問：李老師，如今有各類關於「去大公司，仍是小公司」的觀點，你是如何看的呢？
 
答：選擇大公司或小公司的討論歷來就不絕於耳。支持大公司的人認爲：公司的條件好，所得到的培訓機會也多、正規；支持小公司的人則持：公司人少，一人多職，鍛鍊的機會多。以個人工做經歷，能夠確定的是，我不會告訴你只去大公司或只去小公司。
 
其實，職場發展是一個螺旋上升的過程，我認爲應在大、小公司都乾乾。若是一我的只在小公司幹過，雖然能鍛鍊成多面手，但他獲許不知道「正規軍」是怎樣，眼界會很窄；若是一我的只在大公司幹過，他作事可能相對專業，但也更可能落入工做範圍窄的地步，之後出去的話適應性會差些。
 
你能夠選擇先進小公司，而後加入大公司，這樣就有機會經過對比了解大公司是如何解決在小公司曾碰到的問題或困境，這種對比是一種啓發思考 的 好 途徑。一旦在大小公司都幹事後，對於之後的公司選擇必定會更有想法。對於大公司，我建議你選擇到外企工做一段時間，除了有機會到國外瞭解他們是如何的「水深火熱」外，還能看到國人在作事專業性方面的巨大提高空間。

 
推薦閱讀
《 致IT同仁 — IT人士常犯的17個職場錯誤 》

《 軟件工程師所需掌握的「終極技術」是什麼？ 》
《技術敏感度 — 基層技術管理者必備》

《走技術線，仍是技術管理線？》