1. 程式人生 > >程式設計師生存定律-六個程式設計師的故事(2) .

程式設計師生存定律-六個程式設計師的故事(2) .

程式設計師生存定律這系列的目錄在這裡:程式設計師生存定律--目錄

喜歡從頭瞄的,可以移步。

-------------------------------------------------------------------------------

一個關於專案經理的故事

1 專案經理的養成日記

L2001年畢業之後加入到了福建實達公司。

在今天這個公司幾乎是很少有人聽說了,但在當年實達還是在IT這片江湖裡有些地位的。當年實達的產品線非常全,有網路、有電腦還有外設。外設裡面就包含了終端、印表機和POS機。當然也還做過VCD,不過即使在2001VCD這一筆也是作為失敗案例來提的。

當年L選擇了到外部裝置公司去做鐳射印表機驅動程式。那時候實達外設試圖開發一款自己的中端鐳射印表機,因此需要全線配備軟硬體人員,正是藉助這個機會,

L加入了鐳射印表機這個團隊。

現在想來這個決定有點狂妄,不管是自己還是實達。

隨著iPad這類平板的興起,人們的列印需求越來越少,所以鐳射印表機這類東西越來越不受關注,似乎要被被強塞到舊紙堆裡了。但不管它火不火,單純從技術難度上看,這東西絕對比手機難做,雖然世界上所有做印表機的廠商加起來市值也不一定有蘋果高。

鐳射印表機包括現在的多功能一體機屬於是精密機械,機械、光學儀器、硬體、軟體、甚至圖形字型都攪在一起十分難搞,沒有絕大的投資,絕對啃不下來。鐳射印表機等利潤最豐厚的部分是面向企業的各種機型,眼下這塊市場始終在富士施樂、佳能、理光等少數幾家廠商手中,國內並沒有廠商介入這一領域很可能是和介入壁壘過高有關。在2012

年,很多日本有名的大公司都鉅虧,但做鐳射印表機的還能支援,我想這也和這一領域壁壘過高,競爭對手不多有一定關係。

當時做這個專案的時候,團隊裡的人員都很痛苦,L這個做驅動的尤其痛苦。微軟為印表機提供了標準的驅動程式叫Unidrv,如果基於這個來做,雖然也麻煩,但基本不用程式設計,主要工作是調整配置檔案。之後這個驅動負責幫你生成印表機能認識的用專門語言描述的頁面資料,那時最主流的頁面描述語言有HPPCL和著名的PostScript

但用Unidrv壞處是這樣一來你能定製的東西就非常少,很簡單的六合一功能都沒有。所以如果真的自己開發產品,那驅動程式最好要自己從頭寫。但L當時沒認識到自己寫其實是不太可能的。

L當時的水平大概是這麼個狀況:C++基本會用,但達不到很高的水準,熟讀《Windows核心程式設計》,但大部分書中講的內容沒有用過,反倒是MFC用的比較熟練,但很可惜的是做驅動的時候MFC用不上。通過了高階程式設計師考試,所以各種通用演算法和資料結構沒什麼太大問題。

而從頭做驅動需要什麼呢,你要了解Windows提供的DDI介面,要了解圖形影象、字型、頁面描述語言、色彩的知識。印表機驅動中最好做的是UI,基本上用Win32就行了,最難的是做頁面渲染,也就是把GDI描述的頁面轉換成相應頁面描述語言(PCL)描述的頁面。這一過程非常繁雜,根本不是初級程式設計師能搞定的。其中不說別的難點,一個影象二值化就能憋死很多初級程式設計師。彩色頁面打到黑白印表機上,要把彩色圖轉為用黑白兩色表示的灰度圖,這東西那那麼好弄的。

簡單來講是,L當時是兩眼一抹黑,差距太大。

可以舉個最簡單的例子來形象說明這種差距大到什麼程度:L當時基本的除錯也不會,只能用OutputDebugString()輸出用DbgViewLog,來看程式那裡有問題。有人可能很奇怪說2001年時,VC6的偵錯程式不很好用麼。祕密在於,Win98的印表機驅動是16位的,VC6完全不好使。直到後來找到SoftICE才解決了這個問題。

一邊做驅動的開發,L一邊把Unidrv搞定了,這樣基本上不耽誤其他硬體開發工作。同時L瘋狂補各種知識,單隻為了把C++搞通就啃了數本書,其中最難啃的反倒是《C++程式設計語言》,這書即厚又不好懂,那時候那明白什麼叫不充分的抽象。但回頭想來,讀這些書其實對工作幫助不大,打根基的東西總是見效慢。這就和高燒40度要趕緊掛水一樣,吃中藥慢慢熬,就是沒有立竿見影的效果。當你需要搞定向量圖形如何轉換時,設計原則、面向物件這些東西對你能不能做出來一點幫助也沒有,只有當你能做出來了,這些東西可以幫你把事情做好倒是真的。

做了一年多後,大家都發現這活實在不是一個人能幹的,團隊中就又加了2個人,所以L勉強算是個小頭目了。但即使如此,整體進展仍然不太好,這和公司的策略有關,這家公司的核心產品,其實是針式印表機,並不是針式印表機,實達有著自主研發的整套針式印表機技術。而鐳射印表機實際上處在摸石頭過河的狀況,但偏偏這是個資本密集,技術密集的領域,這樣一來,進展不順也就在情理之中了。現在想來最好的解決方法其實是買套程式碼,在上面定製。等到Win2000成為作業系統的主流,藉助DDK的例子,這個問題一定程度上得到了解決。

說到這裡要拋開技術,說下大環境,要不然無法說明L的幸運。當時實達集團有三家子公司:實達網路專攻網路裝置,如Modem、路由器等,實達裝置專攻外設,如終端、印表機和Pos,實達電腦則主攻PC

當時這三家公司是冰火三重天的狀況:實達網路日子很好過,發展也很快;實達外設則穩步發展;實達電腦則活的很不容易。整體來看實達實際上是處在下滑期,頂著ST的帽子讓公司很難受,新的利潤增長點又沒找到,尤其是電腦部分,利潤是必然是越來越薄。

在實達的三年裡L的工資竟然沒有一點調整,不過L當時沒太注意這些,還是在研究驅動。借Win2000 DDK的啟發,發現在列印處理器那個環節可以做很多事情,這樣針對頁面的各種操作就都可以自己來做了。

正當L把這個工作作出點進展的時候,家裡出了點事情,於是跳槽,到了蘇州一家也是做印表機驅動的公司。這純粹是種幸運而不是種安排,如果不是家裡有事,L未必會換工作,而在開始衰落的公司裡做非主營專案真未必是什麼好事情。

在此前整整三年裡,L理清了印表機驅動的體系結構,打下了語言、平臺的各種基礎,確定了基本開發方法,找到了適合的二值化演算法,但真沒做出什麼太大的貢獻。

換到蘇州這家公司後,藉助過去的經驗,職位有所提升,是以LeaderTitle入職的,實際上是專案經理。不過一進公司,L很吃驚,當年從頭開發驅動不過也就三個人,這裡維護現有驅動搞了快20號人,主要做的事情就是修改現有的驅動程式,每次程式碼變更量不大。絕對的八旗子弟。

不過麻煩事也出現了,以前那有那麼多報告,現在需求的確認,日程的確認,合同的確認,記錄的跟蹤,問題的總結全都要做。一天到晚大事沒有小事不斷,會議數目直線上升。再加上外語這一層障礙,還經常出現說半天對方還沒明白的狀況。

L信奉適者生存,開始積極轉型,把PPT寫好,把Excel寫好,文件裡不能有小錯誤,讀專案管理書籍,讀估算書籍,把口語練好。過往的技術經驗和基礎還是很有幫助的,這讓L可以比較快的把握各種需求的規模、難度等。

直到有一天,原來的老大離職了,L被提升成了部門經理,開始帶自己的隊伍。

公司由於處在成長期,團隊的規模也就在不斷擴大,而L的責任範圍也就隨之逐漸擴張。這時候L的工作又發生了變化,以前是關注一個專案,現在要關注多個專案,也要關心兄弟們的士氣。

L這時候技術基礎還行,也試圖堅持寫程式碼,可發現挺難的只能負責那種時限不是很嚴的,獨立性比較強的模組,因為你不知道接下來會發生什麼,出差、來客人、兄弟們吵架、流程出問題、臨時分配的其它工作等等。

在經歷了最初的幾次失敗之後,L的隊伍逐漸成熟,專案成功的機率逐步提高。現在L比較自信,認為自己是一個比較合格的經理了。雖然不能講任何一個專案到手裡之後,都能保證它絕對成功,但至少可以儘可能保證它成功的機率較高。

可惜的是,L發現自己累積的技術基礎一點點荒廢,基本程式雖然看的懂,但寫起程式來變的很慢,每一行程式碼呼叫每一個方法都要去仔細查詢幫助文件。

2 感悟程式人生

我們還是回到之前一直提到的幾個維度:

價值 實現程度(表達力,稀缺性,公司平臺)職場成就

L的經歷可以看出來,技術是根本,即使你想做管理,即使你學了可能用不上那麼那怕是當敲門磚用,你也要在恰當的領域裡有一定的技術基礎,這是價值的根本。要不然你可能沒有做管理的機會。

任何一個企業招一個人都希望這個人能儘快為公司創造價值,這點和大學絕對不一樣,企業不負責再培養你四年。因此,一個人很難對企業說:我什麼都不會,我就會做專案管理,你招我吧。一般人很難遇到這麼瘋狂的企業。

第二點是你加入處在那個階段的公司非常關鍵,如果L一直堅守在第一家公司,L是不可能有所提升的。原因很多,但其中最關鍵的一點是在整個產品線中,驅動程式是在一個配套的地位上,而在第二家公司驅動程式則是公司最核心的業務,這點影響非常大。

第三點是做可流動區域小的工作時,要特別當心。短期來看L運氣還好,大致解決了自己的生存發展問題,但其實如果以20年為尺度來看,問題仍然存在,對印表機驅動從業人員的需求永遠不可能像對網站開發人員那麼強烈,其劃定的區域也就非常有限。實際上這點在L的同事身上有了一定體現:你做的事情相對比較生僻,而你在這一領域上又沉澱了很久,一旦走出這個領域,又只有年紀大的劣勢,而沒有優勢,這會導致一個人非常艱難。但以L而言,確實又因此而受益,正因為此領域有經驗的人員稀少,L才有機會獲得較快的提升。

第四點是一定要避免加入處於衰落期的公司。假設說,領域想對比較生僻,但公司能夠為此支付一定的溢價,那也是有得有失。只要沒有欺騙,當事人因為合適的薪資而選擇了一個流動性不好的工作,這合情合理,風險理應由自己承擔。但關鍵是L的第一家公司處在衰落期,三年不調整工資基本等價於降薪。如果L不是碰巧離開了,那麼純經濟的角度看損失還是要大,一旦正好趕到房價暴漲後買房,那對人生的影響就不是一點半點。

第五點則是關於管理技能的可流動性。雖然說管理技能的大部分是共通的,但由於L的技術背景是驅動開發,L將很難成為電商類專案的經理人。

L的經歷裡還潛藏著一個冷幽默,當L不會做驅動的時候,他被分配去做驅動;當L不會做專案經理的時候,他被分配去做專案經理;當L不會做部門經理時,他被分配去做部門經理。大致上是在做自己能力不足以匹配的事情,L的人生仍然再繼續,不知道此後的人生是否仍然會符合這條規律。

一個技術牛人的成長經歷

1 杭州李雲的技術牛人之路

李雲是《專業嵌入式軟體開發》一書的作者,後來去了阿里,阿里併購了UC後,老李應該在主要負責UC瀏覽器的開發,大家可以去微博上找他。為了為後來人提供參考,把自己的經歷非常詳細的寫了下來,在我看來,李雲的經歷非常的有價值,因此在這裡與大家做一點分享。因篇幅太長,引入的時候去掉了部分內容,下面是李雲的故事。原文參見:http://blog.csdn.net/hzliyun/article/details/8144320

故事的開始得從大學以前開始。從小受“學好數理化,走遍天下都不怕”觀念的影響,我認為只要學好數理化就行了,所以偏科很嚴重,高二時英語還考過29分。那時也不愛讀書,高三時,別的同學在複習,我卻在看《電晶體技術》這類電子技術書。這種狀態,直接的結果就是第一次高考落榜了。

落榜的那個暑假,父母為我的出路沒少操心。在一天早晨刷牙時,當我媽對我說希望我去復讀時,我當時腦海裡想“能象表哥那樣考上大學那該多好啊!”,在這個念頭驅使下,我答應了去復讀。從那天開始,我頓悟了,真正知道自己要什麼了。在復讀的一年裡,我學到的一種重要能力是自學,這為以後大學乃至職場學習打下了很好的基礎。正因如此,我想給出我的職場第一感悟:自學能力是競爭力之本。

經過復讀,高考總成績提高了100多分,但也只夠專科線。最終,我被南昌水利水電高等專科學校錄取,專業是“供用電技術”。這個專業相信很多人不知其所以然,其實就是電力自動化的變種專業,其專業內容主要是電站、發電廠高電壓的繼電保護技術。

大學讀書期間,我開始有與人在成績上一爭高下的念頭了,加上覆讀一年所獲得的自學能力,以及自己的努力,學習相當輕鬆,尤其是隻要與電子技術沾邊的課程,都能輕鬆地勝出。三年共六個學期的學習,我拿了五個一等獎學金,一個二等獎學金。畢業時,我是系裡唯一的一名優秀畢業生。期間通過了大學英語四級考試和計算機二級考試,獲得了江西省電子技能比賽一等獎。需要提及的是,在大學期間所學的與計算機相關的課程只有:《電子技術基礎》、《計算機組成原理》、《計算機軟體基礎》、《微控制器技術》和《Basic程式語言》。

在大學期間,我完成了人生很重要的一件事 --- 找好了現在的妻子。由於她是浙江人,所以畢業時工作地點毫不猶豫地選擇了杭州。那時很多同學的工作還是包分配的,而我來到了杭州的人才市場進行雙向選擇,那時找一份工作還是相對輕鬆的(注:我們大學錄取那年的招生人數是90多萬),投出一份簡歷就找好了工作。第一個工作單位是一家不到100人、地處杭州花港觀魚對面(三臺山)的電力裝置製造民企。

儘管選擇去這家民企後立馬到公司去做了實地調查,但由於沒有社會經驗,加上被問的人沒如實反應,所以進入這家民企後所瞭解的情況讓人大跌眼鏡。另外也瞭解到單位會通過一些不入流的做法控制我們的戶口,不讓我們跳槽(那會兒的戶口還是相當重要的,結婚要戶口證明,有同事就因為戶口被控制而登記不了)。而我們在進入這家單位時簽訂了六年的勞動合同。在這樣的小企業幹上六年意味著什麼?!當時與家人打電話告知這一狀況時,我都哭出來了(就在現在楊公堤與虎跑路交叉的、現早已不存在的一個電話亭裡,記憶猶新呀!)。

儘管前途是那樣的渺茫,但帶有“優秀畢業生光環”的我仍堅信自己能做得比別人更好,因為有我的職場第二感悟:自信能讓你與眾不同,儘管有時的自信有點莫名其妙。在這個企業一開始的工作職責是電站裝置的電氣設計工程師,需要用AutoCAD(到單位後學的)設計電氣圖紙,並指導工人最終完成電氣裝置裝配及除錯。期間,企業經營範圍擴大,需要從事電子裝置的生產,因此我開始有機會接觸電子技術方面的設計工作。在兄弟單位一同事的幫助下,在一個星期內我掌握瞭如何用Tango(後來更名為Protel,現在的名稱是Altium Designer)進行原理圖和PCB線路板設計。而且,這一個星期的設計結果最終成為了電氣產品的一個部件。對於一個畢業不到一年的我來說,這是不小的進步。那時知道了什麼是網路表、過孔、焊盤等,掌握了很多電子原件的工作原理(有的還自己用麵包板做實驗),明白了做電路板的大致業務流程,還能動手焊接電路板,熟練運用示波器和萬用表進行除錯。那段時間,我對電子技術的興趣幫上了大忙,學習起來遠比別人快。當我精通電路原理,能自如運用示波器和萬用表除錯電子產品時,別人卻還不明白我的除錯動機。我的職場第三感悟:興趣是學習效率的催化劑,培養自己的職業興趣。

第一次真正對程式設計感興趣是從知道PLCProgramming Logic Controller)開始的。當時的電站裝置採用了三菱的PLC,為了配合這一電氣產品的需要,企業社招了一名懂PLC程式設計的工程師。由於老闆擔心我們相互學技術而“翅膀變硬”,所以明確提出工程師所掌握的技能不能互通有無。當時看到這位兄弟能通過“梯形圖”改變PLC的行為,真是覺得他太神奇了,仰慕不已。後來通過這位兄弟的私下幫助,我晚上偷偷地在廠房裡面學習PLC程式設計。為了獲得良好的學習效果,我設定了對電氣產品的PLC程式進行重寫的目標,且最終達成了這一目標(當然,由於這個目標不能讓老闆知道,所以我的PLC程式不能用於商用)。我的職場第四感悟:學習應給自己設定虛擬的專案目標,以做專案的形式提升學習效果,只有這樣學到的內容才會深入而實用,切忌無目標地學到哪算哪。

一年多的功夫,我成為了某電氣產品的技術負責人,對整個產品的所有技術細節都瞭如指掌,我帶領了其他幾個工程師實現了該產品的“自主研發”。有趣的一件事是,老闆當時並不知道我已經“翅膀硬了”,想抵賴答應過的8000元專案獎金,年輕氣盛的我在與之拍完桌子之後對其他工程師下令:“沒有我的允許,誰也不能將電氣圖紙和電路原理圖用於生產”。對抗的結果以老闆兌現承諾而告終。這時我隱約地有了我的職場第五感悟:話語權首先來自能力,而不是職位權力。

我那時還學會了CRC演算法並將之運用於PLC的串列埠通訊中,由於對計算機如何通過串列埠與PLC通訊獲得採集資料存在很大的好奇心,所以想到了學習程式語言,並計劃做一個能在計算機上實時顯示PLC所採集資料的軟體。在向負責PLC程式設計的兄弟表達了這一想法後,他給我的建議是:學習C語言比較難,Basic語言則更容易。於是,我毫不猶豫地選擇了自學C語言,因為我深信我的職場第六感悟:難學的技能一旦掌握更具競爭優勢。

也正是從那時開始,我真正開始了成為軟體工程師的自學之路。那時比較幸運的是,單位專為我配備了工作電腦,所以具備了自學的硬體條件。由於那時Internet還不普及,學習書籍都來自浙江大學的科海書店(後來眼見著它的店面越來越小,這也是進入電子商務時代的一個縮影),那時隔三叉五地到科海去找書,生活最大的花費就在於購書(那時這方面的書不少是質次價高)。當然,學習的過程或多或少還得瞞著老闆。那段時間,別人午休我就程式設計,除了看書和做書後的習題,還一直朝實現自己的計算機監控軟體這個目標邁進(參見我的職場第四感悟)。終於有一天,我用Turbo CDOS環境下實現了具有串列埠通訊功能的、基於圖形介面的監控軟體(如果你用現在的眼光看那個軟體,一定會說“很土”)。當我樂此不疲地向他人演示時,你可以想象我那時有多高興和自豪!這種小小的成功助長了我的信心,也讓我得到了我的職場第七感悟:用階段性成果不斷增強自己的自信,但最終支援自信的是能力,而不是自大。嚐到了成功甜頭的我隨後拓展了自己軟體開發方面的學習內容。那時的我已經下定決心要向軟體開發方向發展,這種選擇是因為我的職場第八感悟:做自己喜歡的事,如果那是自己的興趣最好。 

1999年的某月,在企業拖欠了一個月工資的情形下,“蓄謀”逃離企業束縛的我們(共19個工程師)經過幾個月的勞動仲裁後,與企業解除了勞動合同。在離開這家民企的第二天,199911月的某天,我在浙江大立機電技術開發公司(即現在的大立科技。後面都簡稱為大立公司)找到了第一份專職的軟體開發工作。我逃離束縛後能很快地找到新的支點,完全得感謝我的職場第九感悟:不論身處多麼困難的環境,即使覺得前途渺茫,也不要放棄學習,否則就是“自斷筋脈”。

在大立公司所參與的第一個軟體專案,是使用Visual C++從事Windows某變電站影象監控桌面軟體的開發。儘管我之前自學過C++語言,但那時並未完全掌握面向物件程式設計,尤其是其中的多型。我在該桌面軟體中借鑑微軟的示例軟體DrawCli,獨立地實現了電子地圖功能。正是通過掌握這個示例軟體的設計與實現,我真正領悟到了面向物件設計的好處。也通過該影象監控桌面軟體的開發經歷,掌握了Windows VxD驅動開發、socket通訊、多執行緒程式設計、影象處理(銳化、偽彩處理、影象字元識別和影象對比等)、ODBC資料庫程式設計(用的是SQL Server)等。

在妻子進入大立公司不久,由我擔綱了新版影象監控軟體的重新開發,這是我第一次擔任軟體專案負責人。在這個專案上,我可以盡情發揮,將我在老版本軟體上所看到的設計不足完全克服。也正是通過這個軟體專案,我的面向物件程式設計能力有了很大的提高,而且完整地做過了一個軟體產品。用我現在的眼光來看:那時的開發工作除了引入了版本控制軟體外,是不折不扣的作坊式軟體開發;至於管理技能的提高,也可以說是微乎其微。

2000年底,大立公司因為業務拓展的需要,需開發嵌入式影象監控系統(系統中的前端產品是後來數字硬碟錄象機的前身)。為此,公司社招了一位比我年長十歲的資深硬體開發工程師,他在進公司時已經有基於AMDElan SC520 x86嵌入式微控制器的硬體開發經驗。他在進公司之初與章總交談時指出:“做這類嵌入式產品,需要軟體功底非常強的人”,章總的回答是:“你放心好了,我一定找一個最好的人與你搭檔”(這是章總後來告訴我的)。是的,所找的那個人就是我!而其實那時我只有用Visual C++從事Windows桌面軟體的開發經驗,可見公司領導對我能力之信任!我的職場第十一感悟:機遇很重要,但你得有能力才能抓住它。

我當時所面臨的技術挑戰,讀者可以想象。要知道,在2000年時基於x86微控制器的嵌入式系統的開發人員國內還很少。我的自學能力、電子愛好的興趣在這種挑戰面前又幫了大忙。其實,做嵌入式系統開發最主要的是參考各種資料以便掌握各類技術細節,這得通過大量地閱讀晶片手冊、使用者手冊,以及研究AMD在其官網上所提供的示例程式。在這個過程中,就技術困惑堅持探究和養成各種好的工作習慣(思考習慣、筆記習慣、總結習慣、閱讀習慣)非常重要。我的職場第十二感悟:職場首先比拼的不是智商,而是堅持與好習慣。

我獨自完成了該嵌入式前端產品上的軟體開發工作。其中包含的大致技術內容有:從程式設計的角度精通x86處理器架構; PCIIDE硬碟、網絡卡、串列埠、快閃記憶體等匯流排或外設的驅動;實時作業系統核心的移植工作;MINUX作業系統的檔案系統的移植; XINU作業系統的TCP/IP協議棧的移植工作。移植工作往往會碰到各種技術細節問題,等移植工作完成,對被移植模組的實現和背後的原理也已瞭如指掌。正應如此,這一時期的工作讓我對作業系統的實現原理有了很深的理解。

除了軟體方面的進步,我在大立公司時硬體知識也得到了很強擴充。不僅能輕鬆地閱讀數位電路原理圖,還自學了VHDL語言,使得拿到邏輯器件CPLDVHDL程式就能除錯軟體(通過VHDL程式,可以瞭解程式設計所需的譯碼埠、相關訊號的操作時序等)。還學會了如何使用邏輯分析儀輔助軟體除錯工作。前面提到的這位兄長式硬體工程師調侃我說:“你讓我看到了中國軟體的希望!”,而我將這話當成了對自己的鼓勵。另外,這期間還考入了浙江大學專升本的通訊工程專業,給自己充電(2001年入學,2004年畢業,獲多學期“優秀學生”和“優秀畢業設計”)。

由於大立公司是浙江省測試技術研究所的子公司,它或多或少帶有事業單位的氣息。加上公司的技術舞臺有限,以及妻子也在同一家公司工作,我於20034月份左右離開了大立公司。在我離開之前,浙江省科委已批覆了公司的申請,分配給我一套福利房。在我離開之時,房子仍在建,不少同事對於我的離職很是不解,也勸我拿到房再走。但我有我的職場第十三感悟:當短期利益與長遠利益無法得兼時,選擇長遠利益。

在大立公司工作期間,很希望自己能入職UTStarcom這樣的通訊企業(那時的UTStarcom是多麼地輝煌!)。計劃離開大立公司之際,我向UTStarcom提交了求職簡歷。這次求職開始好像很順利,但我真正入職UTStarcom的過程卻很是曲折。

一開始當我收到UTStartcom的面試通知時,可能太希望能進入這個公司了,在沒有很深入瞭解這個崗位的前提下,就去面試了,且馬上拿到了Offer。但後來才瞭解到,我拿到的是生產部測試開發崗位,與實際研發部門是有區別的。 當時很糾結 — 這是我想進的公司,但卻不是我想要的崗位。如果拒絕生產部的Offer,我很有可能與UTStarcom無緣。考慮再三,我還是選擇了拒絕(參見我的職場第十三感悟),並重新向研發部門投了簡歷。

經過度日如年的一個多月等待(那會兒剛好發生了SARS疫情),在覺得入職UTStarcom研發部門無望的情況下,我入職了另外一家小公司。令人意外的是,在入職那家公司的第二天,我收到了UTStarcom研發部門的面試通知。在HR面試的那一輪中,HR對我說:“你是我所面試的人中最有工作激情的”。那時的技術面試官中,其中一位是我日後入職後的上司 — 夏青(現在是恆生電子通訊事業部的總經理),他是我的伯樂。由於我的學歷問題,在技術面試通過後,別人只要一位VP面試通過就行,我卻需要兩位。我的職場第十四感悟:學歷是很重要的敲門磚,即便你的能力很強;學歷儘管很重要,但能力才是最終的通行證。

20036月份左右,我正式入職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還在開發新的功能,並不是很穩定,在移植過程中碰到各種奇怪的問題,有些問題還與GNUbinutils工具集有關(binutils中包括nmldobjdump等工具。RTEMS是用GCC編譯的)。在無法確認是GNU工具集的問題之前,我甚至還向Wind River公司(其知名產品是VxWorks實時作業系統)尋求過幫助,因為那時用的是它的JTAG模擬器。移植工作雖曲折,但最終還是成功了(我所移植的版本並沒有運用到產品中,後來的同事又做過了RTEMS4.6.0pre4的移植,且運用於產品中)。這一移植經歷,讓我對GNUbinutilsRTEMS作業系統的實現有了更為深入地掌握。

UTStarcom工作的前期,我大多從事的是RTEMS作業系統相關的程式碼維護工作,工作內容除了OS核心,還包括FTPTelnet等協議。直到中期轉為做E-Box產品的網際網路接入模組的開發工作。

E-Box是一個企業級電話交換產品,其中還存在一塊基於ADSL的網際網路接入資料板(與現在的ADSL貓功能一樣),用於實現企業網對網際網路的資料接入功能,這一資料板使用的是VxWorks5.5.0實時作業系統(PNE 2.0),處理器是IntelXScale IXP425。那時VxWorksIP協議棧還是基於BSD的,但Wind River對之做了一定增強。這段時期我的工作重點全在IP協議棧上(《TCP/IP詳解》這套書幫上了大忙)。這一時期的開發經歷,讓我對PNEBridgeFastPathMUXPPPoE協議、Radix路由演算法和VLAN協議很熟悉,也學會了用SmartBit儀器和Chariot軟體做網路效能測試。總之,讓我在IPv4)協議棧方面的知識上和軟體實現上有了長足的進步。

E-Box產品資料板上的開發工作進行了半年後,管理層決定放棄,於是我被調到了E-Box產品的軟體平臺組。那時平臺組剛好面臨一個比較麻煩的問題 --- 在命令列上執行reboot命令後,有時會出現整個系統掛起,而不是期望的重啟。平臺組的同事花了一個多星期的時間仍沒有解決這一問題。

進入平臺組之際,同樣是在沒有任何人安排的情況下,我自己主動承擔解決reboot命令功能異常的工作。在我的職業生涯中,我一直熱衷於去解決別人難以解決的技術問題,這是因為我的職場第十七感悟:越難的技術問題,其所蘊藏的知識越豐富,也越具學習價值。經過一天半的時間,問題被解決了。其根源在於,reboot之前沒有禁用CPM協處理器。我能那麼快地解決這一問題,完全是因為之前熟讀過PowerPC8250處理器的資料。

我在UTStarcom工作的後期,致力於ACEE-Box產品中的一些應用,藉助ACE的網路通訊功能幫助實現在Windows平臺上通過Visual Studio除錯E-Box產品。我在《專業嵌入式軟體開發》一書的《可開發性設計,一種高效且經濟的開發模式》一章中所闡述的內容其實就是這一工作經歷的總結與延伸。

另外,我還在E-Box產品上做過難度比較大的一個特性是,利用PowerPC 8250MMU功能在VxWorks作業系統上實現了對任務棧的保護 --- 當一個任務被排程而處於執行狀態時,它的棧就處於可讀寫狀態,而其他任務的棧全處於只讀狀態(VxWorks5.5.0核心中,還沒有RealTime Process的概念,這一概念是從6.0開始有的,所以那時我所做的這一特性很具實用性)。通過這一特性,可以有效地防止任務棧被意外篡改(比如野指標操作),即便出現篡改也能儘早發現根源。這個功能的實現過程需要除錯VxWorks核心,那時VxWorks的原始碼雖對公司提供,但Wind River公司對所提供的GNUbinutils做了特殊處理,使得無法為核心程式碼生成除錯所需的資訊,結果是無法對核心進行原始碼級程式除錯。由於我之前的RTEMS作業系統移植經歷讓我對binutils非常熟悉,通過使用一定的方法(說來話長了)繞過了Wind River公司所設定的障礙,成功地實現了對VxWorks的原始碼級程式除錯。

在職場中,我不時能成功解決複雜問題和克服技術障礙。這與我的職場第十八感悟是分不開的:每次積累的點滴知識,一定會在將來不知不覺地發揮效能。

20064月份左右,我離開了UTStarcom。在UTStarcom所學到的,不只是前面所介紹的那些技術知識,更讓我知道了軟體開發的“正規軍”是怎樣的,與小公司相比,UTStarcom的軟體開發流程要正規得多;也經歷了英文寫作的“擠牙膏”時期過渡到輕鬆時期(好友周海東在我的英語學習中幫了不少忙);看到了好友于善成如何通過大量閱讀成為一個知識淵博的人(他的閱讀量現在仍是我的學習榜樣);還有上司夏青的技術敏感度到現在仍讓我為之稱道,是我職場至今所見過的二位具有良好技術敏感度的技術管理者之一(另一位是我在Motorola工作期間認識的,後面會談到他);團隊實力之強使得開發出的E-Box產品在我離開UTStarcom後不時能聽到正面的評價。

說到這裡有補充一點,我在大立公司工作時期,就很注重軟體設計文件的編寫,而且在我離開之時,不僅完善了所有文件,還為後繼同事做了全面的培訓。我始終堅守我的職場第十九感悟:通過文件化的方式傳承知識給後繼者是你的基本責任,因為你作為後繼者時也希望如此,這也是對自己負責的一種表現。在UTStarcom工作期間,我進一步形成了將自己的技術想法寫成文章與大家分享的習慣(那時同事賀旭東稱我為“作家”,而我則稱他為“點評家”),也因為自己在嵌入式軟體開發技術上的長期點滴積累,開始有了寫書的想法。

離開UTStarcom後,我入職了杭州華數集團旗下的雷科通技術(杭州)有限公司。公司當時的意向是安排我負責某寬頻接入產品的軟體開發工作。在這個公司,儘管只有兩個月的時間但也做了些事。除了一個月內完成了寬頻接入產品乙太網交換晶片在VxWorks作業系統上的驅動開發,並使得產品支援VLAN功能外,還解決了好幾個影響整個產品系統穩定性的嚴重遺留缺陷。這兩個月的工作不光讓我在技術團隊中很快地樹立了自己的威望,也使得公司高層管理者真切地看到了我的能力而在我提出離開時極力地挽留。這短暫兩個月的工作經歷帶給我職場第二十感悟:別人對你價值的認可,其實不是簡單地根據你的自身能力,而是根據你對他人和團隊的貢獻。

入職

相關推薦

程式設計師生存定律-程式設計師故事2

程式設計師生存定律這系列的目錄在這裡:程式設計師生存定律--目錄喜歡從頭瞄的,可以移步。-------------------------------------------------------------------------------一個關於專案經理的故事1 專案

程式設計師生存定律-程式設計師故事1

程式設計師生存定律這系列的目錄在這裡:程式設計師生存定律--目錄喜歡從頭瞄的,可以移步。-------------------------------------------------------------------------------此前的章節基本上是在分析並試圖

程式設計師生存定律-程式設計師故事2 .

程式設計師生存定律這系列的目錄在這裡:程式設計師生存定律--目錄 喜歡從頭瞄的,可以移步。 ------------------------------------------------------------------------------- 一個關於專案經理的故

程式設計師面試的幾常見的問題1

1.什麼是面向物件?對於面向物件,它是java程式的一種程式設計思想。那麼它有四種基本特徵:抽象、封裝、繼承、多型抽象:抽象可以分為抽象類和抽象方法;抽象類①使用abstract關鍵字來定義抽象類②抽象類能被繼承③抽象類不能例項化(即不能建立抽象類的例項,但是可以先例項化抽象

程序猿生存定律-程序猿的故事3

orm 收益 轉換成 國內 合集 並不會 就會 依然 公式 程序猿生存定律這系列的文件夾在這裏:程序猿生存定律--文件夾喜歡從頭瞄的,能夠移步。-----------

黑馬程式設計師——————使用NIO對檔案進行復制2

由於檔案複製到檔案和檔案複製到資料夾的程式碼具有重複性,所以兩者方法可結合在一起。 分析: 1,複製到資料夾程式碼多了一層判斷: f(!targetFile.exists())targetFile.mkdirs(); 2,當targetFile為檔案時,targetFile

第五神奇的電梯2

clas 錯誤 輸出 註意 blog 報錯 遠的 配置 選擇 經過兩天的痛苦,我終於把電梯計劃進行了一點推進,終於有完成了三個類,下面我來介紹一下這三個類。 新增的類 控制中心類:控制中心主要用於存放處理,請求,改變電梯的目標和方向,通知乘客開門了,等等。 電梯類:註意

JavaSE——三特殊的類2

String類(下) 1.字串查詢 從一個完整的字串之中可以判斷指定內容是否存在,查詢方法如下: No. 方法名稱 型別 描述 1. public boolean

用wxpython來做自己的第一介面小工具2

本節我們需要新增panel ,你可以理解為面板。一個大主介面,需要有一個或者更多面版。各種控制元件:按鈕/輸入框/靜態文字 什麼的都是放在這個面板上的 先來看第一節成功之後的程式碼: class testFrame(wx.Frame): def

易混淆概念2

(原標題:人工智慧、機器學習和深度學習之間的區別和聯絡) 有人說,人工智慧(AI)是未來,人工智慧是科幻,人工智慧也是我們日常生活中的一部分。這些評價可以說都是正確的,就看你指的是哪一種人工智慧。 今年早些時候,Google DeepMind的AlphaGo打敗了韓國

工作2-5年java程式設計師,這技術棧讓你輕鬆漲薪50%

      工作多年以及在面試中,我經常能體會到,有些面試者確實是認真努力工作,但坦白說表現出的能力水平卻不足以通過面試,通常是兩方面的原因:   1、“知其然不知其所以然”。做了多年技術,開發了很多業務應用,但似乎並未思考過種種技術

程式設計師生存定律書摘

做好管理工作有兩點很關鍵: 一是要把技術工作做的相對比較好。 二是要能夠借勢。如何開始自己的管理工作? 1.瞭解現有系統的狀況,包括規格、程式碼規模、程式碼質量、程式碼內部結構、工作流程、問題所在等。比如說:很可能這類系統缺乏一種整體設計,是靠單純的增加程式碼的量堆積出來的,程式碼冗餘非常厲害,資料庫的表也建

程式設計師生存定律

               

程式設計師生存定律--如何儘快變的稍微專業一點

程式設計師生存定律這系列的目錄在這裡:程式設計師生存定律--目錄喜歡從頭瞄的,可以移步。-------------------------------------------------------------------------------1 掌握讀程式碼的方法和技巧不

程式設計師生存定律-打造屬於自己的稀缺性

程式設計師生存定律這系列的目錄在這裡:程式設計師生存定律--目錄喜歡從頭瞄的,可以移步。-------------------------------------------------------------------------------假設說你想在江湖裡謀求一定的地

程式設計師生存定律--細論軟體這個行當的根本特徵

程式設計師生存定律這系列的目錄在這裡:程式設計師生存定律--目錄喜歡從頭瞄的,可以移步。------------------------------------------------------------------------------規律是必須順應而不能改變的,但除

程式設計師生存定律--管理向左,技術向右

程式設計師生存定律這系列的目錄在這裡:程式設計師生存定律--目錄喜歡從頭瞄的,可以移步。-------------------------------------------------------------------------------一個程式設計師在考慮增值時無法

程式設計師生存定律--程式人生的出口

 程式設計師的人生出口很多人非常想知道自己的未來是什麼樣子的,迫切到一定程度甚至會找算命先生。如果並不是想得到一個精確結果,這事兒其實並沒有想的那麼難。程式設計師的人生看起來五花八門,可以是Windows系,可以是Android系,可以是iPhone系等等,但如果為之做點抽象

程式設計師生存定律——成長路上常見的坑

1. “博”與“專”上的迷失 假設說一個人的學習已經聚焦,並且學習的內容和自己實際參與的專案也相吻合,那麼是不是就沒有問題了?很不幸,答案仍然是否定的,在任何一個子領域裡,仍然需要進一步去考慮“博”與“專”的均衡。 對於軟體開發而言,設計是再常見不過,再簡單不過的一個詞了。可如果把視角拔高一點

讀書筆記-《程式設計師生存定律

《程式設計師生存定律》 1 程式設計的根基:  計算機體系結構-深入理解計算機系統 Randal E.Bryant  演算法和資料結構-演算法導論  Thomas H.Cormen  設計原則和模式-敏捷軟體開發:原則、模式與實踐  Rovert C.Martin