程序員是青春飯？該何去何從？

針對工做幾年的程序員工程師，常常會遇到瓶頸，這個瓶頸不必定技術上的，也多是職業發展上的。通常技術的職業規劃會有兩個方向。

技術方向:

架構師，系統分析師，CTO

這種每每是走純技術路線，發展到最後都是在公司中深刻某一塊技術，例如存儲，MQ，通訊，等等。後面發展路線也每每是架構師/系統分析師，技術專家，高級培訓師，而後就是技術總監。

業務方向:

產品經理，項目經理，部門經理，CEO

我以爲業務方向更多的是關注項目，針對當前業務，很是瞭解業務的整個流程，而若是有些業務由於特殊性，會遇到技術難點，要麼讓公司基礎技術部提供解決方案，要麼扔給手下人去作技術調研以及技術攻堅，若是本身部門針對這個技術作出了不少成績，那麼能夠分享推廣到全公司去使用，你們都來調用你的接口，都來參閱你的文檔，可想你本身也是很是高興的。

但是我一直以爲，若是技術不懂業務，不瞭解業務痛點，沒有產品思惟，那麼也沒法針對技術作出改進、改善。業務驅動技術，根據不一樣的業務,會有特殊的技術要求，實時性高、穩定性強、多數據聚合計算等等，都考驗了程序員的技術儲備，亦或者技術攻堅水準。

這兩天讀了本書《我編程，我快樂》，第一眼看書名，我覺得是某個國內無良人士出了一本騙錢的書，可是後來看到是外國著做，國人翻譯且豆瓣評論還不錯，所以就耐心的看了下去，總體還不錯。下面針對本書寫一些心得：

作一個通才

頂尖的程序員都每每是某一個領域的專家，其餘領域大部分都是興趣所致，你能夠理解他不如專精領域那麼厲害,可是也比普通程序員要厲害的多。

咱們在項目中，每每不可能只使用一門技術，每每都是多門技術並行前進，所以多會一門技術就表明着多一種解決方式，多一個思考方向，也許新的解決方式每每比你固有的思惟更加有效，這也是爲何如今流行混合編程。

記住，是咱們選擇編程語言和技術，而非它們選擇咱們。一樣的項目下，我用ruby寫出的web應用更加迅速，30天也許就能發佈上線，而你使用java也許須要3個月。而若是你用ruby去寫通訊服務，也許你30天就能搞定，可是遠遠沒有java來的穩定。真正的大牛是針對業務場景去選擇技術，而不是在某個特定的技術框框下去完成任務，所以程序員須要作一名通才。固然這個通才指的是某個領域中的通才，切記不能好高騖遠，什麼都學，什麼都只會皮毛，那不如不學。

跳出本身的溫馨區

不少程序員都會下意識的標榜本身是一名c++程序員，java程序員，ios開發，安卓開發，php程序員等等。可是他們每每忽略了一個事實，就是你首先是一名程序員，有意無心的將本身綁定在某個領域或者某一個語言上是很是危險的事情。

衆所周知，摩爾定律，每18個月硬件行業會有一次革新。而軟件行業也同樣，當你的機器性能已經很是好，不用在關注性能自己，不用苛求運維在多分配一些內存給你，多一些帶寬給你的時候，每每性能就不是那麼重要。也許你說你用c++開發的服務性能高，可是跟開發的人力成原本對比，這點提升也許並非顯而易見的。若是你用java開發服務，那我以爲這個選擇極可能是正確的，可是若是你用java去開發一個web後臺，那我只能說，傻逼。所以跳出本身的溫馨區，去學習更多的新技術，或者不同的技術，也許你會有不同的收穫，也許你已經厭惡了面向對象編程，面向接口編程。實現某個功能，必須先去定義一個類型，或者接口的時候，或許你也能夠試試面向過程編程，或者函數式編程。這也是函數式編程近年來很火的緣由，由於隨着硬件的發展，函數式編程在之後性能不給力的缺點已經慢慢被忽略，轉而提現了他高併發的優勢。

若是你這個時候還一直強調函數式編程性能不行的固有思惟，那麼你也許該考慮本身是否是該充充電了。

舉個例子:

以前公司業務擴張，招攬了不少java程序員，可是由於咱們公司原先架構都是php的，讓那些java程序員來寫php，他們成天嗷嗷叫，痛苦不堪，我原先以爲奇怪，難道php開發比java還難麼？

後來證實我錯了，並非php的門檻比java高,而是他們不願跳出本身的溫馨區,從心底生成了一種抵觸的想法,從而致使他們工做的並不開心,可是公司招聘你進來是爲了創造價值的,真正厲害的程序員針對各類技術都是信手拈來,而且我相信,我學習到的任何技術,在未來都是有用的，也許只是時間未到。在10幾年前,你會想到帶有GC和麪向對象編程的開發語言會如此之火麼？如今又有哪一個新興開發語言沒有這兩種東西的，因此千萬不要一直保留着本身那可憐的固有思惟,試着跳出溫馨區,也許你會看到新大陸。

對本身喜歡的事情投入100%的熱情

我有個優勢,也正是個人缺點,當我喜歡作某個事情的時候,我會投入100%的熱情,說廢寢忘食也不會過。由於這段時間內,我滿腦子都是這件事情,甚至睡覺上廁所,吃飯,走路都會想着它,這樣的優勢讓我能迅速掌握某個新技術。可是每每由於這樣,也一樣讓我產生了我是天才,學什麼都很快的錯覺,從而致使本身不少東西都學不精通就放棄了。我以爲之後須要更正這個錯誤的想法。

好比以前公司項目中有一個圖庫,全國各地的用戶上傳圖片到服務器,以爲很是簡單,可是正由於很是簡單,裏面須要涉及的東西卻很是多,各地的用戶使用的網絡環境不一致,他們的通訊節點也不一致,怎麼保證每一個人的上傳速度都是可控的。

當某個用戶忽然沒法上傳的時候,怎麼辦？難道跟用戶說我這裏好好的,別人也是好好的就你那裏不行？所以我針對每一個人的上傳記錄,作了一些記錄,記錄每一個用戶的上傳速度,上傳ip,以及上傳文件大小,還聯繫cdn服務提供方,開啓了服務日誌,記錄每一個人的上傳狀況,而且增長了動態請求分配節點,防止某個區域某個節點忽然掛了,而致使用戶沒法上傳圖片。這個系統剛上線的時候,基本上傳1萬張圖片會有100屢次的甚至1000次的失敗,而如今,隨着系統愈來愈完善,愈來愈穩定,失敗次數已經下降到了兩位數,甚至個位數。而且針對產品上也作出了相關的修改,例如友善的告訴用戶爲什麼會上傳失敗,是不支持圖片大小,仍是不支持圖片格式,千萬不要高估用戶,用戶不知道圖片有多大,也不知道本身用的單反有多厲害。曾經有個用戶上傳了個圖片一直失敗,結果我看了下那個圖片有70多M,而個人服務當時最多就支持18M,雖然知足了大部分的請求,可是個別狀況下也是會掛,最後我也修復了這個問題。

總結起這個項目,我以爲後期維護的期間,我學到的知識比開發期間多的多。所以我想說,投入100%的熱情,並鍥而不捨,我知道這是很是難的事情,也正由於如此,技術專家、資深大牛才那麼稀缺。

站在巨人的肩膀上

另一點提升本身瓶頸的方法就是借鑑前人的代碼,程序員這個行業,並不必定非要什麼都不看直接寫,也許你在有基礎的狀況下,直接開始寫,遇到問題在查找問題會來的更加容易上手。可是正由於這樣,你寫出來的代碼每每質量很是差,優化性不夠,語法囉嗦,不夠優雅,所以咱們要學會多從其餘人的代碼中汲取優勢。多逛逛開源社區,針對本身感興趣的方向去學習別人的代碼,也是進步的一種方法。最討厭某個前輩或者資深人士說,看什麼看,直接寫,這樣的說法是極其不負責任的。

作團隊最差的人

作團隊最差的人,當你以爲其餘人都比你優秀,那麼你天然而然就成爲了最差的那我的,跟比你優秀的人工做,會讓你更加的快樂,學習到更多有用的東西,也許寧作鳳尾,不作雞頭也是這麼來的。而作團隊最差的人,每每能夠有很是強的學習動力,以及很是迅速的成長空間。不然只有固步自封,100行代碼寫了一萬次,有什麼意義麼？

學習如何失敗

越早的發現問題,就能越早的彌補損失,你應該慶幸如今發現了這麼多bug,而不是上線的時候,你也應該慶幸人少的時候發現了這麼多bug,而不是用戶擁堵的時候。若是你的軟件沒有按期向你抱怨,你就不知道危險的故障隱藏在哪裏,此外帶着防護性的措施進行編程也是很重要的。出現問題的時候,纔是考驗軟件開發質量的時候,出現問題的時候,解決方法、解決思惟也是檢測工程師技術的時候,學習處理也是很是重要的。

1.所以發現問題第一時間提出,在開發和測試中,越早發現錯誤,形成的問題就越小,越早發現而且暴露本身犯下的錯誤,形成的負面影響也就越小。

2.接受批評,也許這個問題並非跟你有直接關係,也許只是間接關係,也許壓根跟你不要緊。可是當出現問題的時候,咱們第一時間須要的是解決方案,而不是互相甩鍋,咱們的目標是在最短的時間內解決修復問題,在誰來負責這個問題上糾纏不清的後果就是拖延解決問題的時間。

3.尋求幫助,當咱們遇到困難的時候,必定要學會跟團隊成員互相溝通,尋求解決方案,而不是由於責任感和自尊心而掩飾問題,以及拖延問題。沒有人不會犯錯,越是及早的解決問題,越是能減小問題帶來的負面影響.

說「不」

在團隊中,常常會遇到需求方給你提出某個需求,也許你以爲這個需求不合理,可是仍是礙於同事的面子抽時間給他完成這個需求，這個時候你在同事的眼裏也許就是負責的好同事。可是也許你遇到的只是一個不動腦子,或者壓根只是抱着試一試態度的產品經理。沒有通過完整的調研,只是拍拍腦殼以爲用戶可能會喜歡這個產品,沒有作出需求調研就話了一個prd給你扔了過來。若是項目表現不錯,你的努力受到了你們的承認,那麼皆大歡喜。可是若是這個項目最後仍是失敗了，那麼你付出的努力也會白白浪費,也許這個項目仍是你抽空閒時間,大晚上熬夜寫的。

因此在需求方提出需求的時候,你必定要問他,作這個功能的意義是什麼？你有數據作出支撐麼？這個功能對咱們現有的產品會有什麼影響以及正面做用？沒有數據支撐的需求一概說不。我手上事情還沒作完,就由於你一個拍腦殼想出來的點子,就讓我陪你一塊兒瘋？記住,戰術上的努力並不能彌補戰略上的懶惰,若是方向從一開始就是錯誤的,那麼爲何要一直錯誤下去？及早回頭,回頭是岸,也許有人會說,互聯網就是不斷迭代,不斷試錯的過程,那請問你在進行以前有通過詳細的規劃麼？有詳細的數據支撐麼？如何看出你這個需求就是很是緊急,如何看出你這個需求一上線就會有N多的人樂此不疲的使用的？若是沒有,請你先去想清楚再來講話。試水的前提是我大概知道這個水有多深,而不是一無所知,否則爲何沒有人去試海？試洋？

上面都是從業務上面來講的，下面說說技術上。

當你的項目經理問你是否能完成這個任務的時候,你模棱兩可的說能夠,也許行,好像行,也許你的項目經理只是詢問下你需不須要幫助,又也許你的項目經理聽了你的回答,會跟大老闆拍板保證,這些都是創建在他對你的信任上的。或許你只是想表現的不那麼弱,或許你只是想在你上司面前表現一下,我不是部門最菜的。可是這種信任是慢慢積累起來的,若是有一次你讓他失望了，兩次讓他失望了,甚至三次,那麼這種新人就會崩塌,你能夠說"我不肯定我能hold住這個項目,這是一次挑戰,但我想要試一試。"這就是很是好的答案。提早告知你上司這個項目會遇到的風險點,以及不肯定因素,我想他更願意給你更多的時間去調研,去整理整個項目的技術難度。

勇於說"不"的人作出的承諾更可信,也更有份量,我不知道並不表明我不可靠,某個領域內的專家對於他們不知道的事情,老是敢於認可。

價值僵固

正如上面所說的跳出本身的溫馨區同樣,價值僵固依舊也很可怕,不少前輩都喜歡對後輩們諄諄教導,一部分前輩會把本身踩過的坑,遇到過的問題告訴你,你吸收了這些話,那麼之後能少走不少彎路。可是若是這個前輩的思想已通過時,或者已經落伍了呢？他的成功經驗每每還停留在他們本身的那個時期,他們以爲本身的成功能夠複製,但他們每每忽略了風向,站在風口,豬也能飛,若是有個公司的CTO跟你說他是學delphi起家的,讓你去學,你信麼？你要知道delphi在二十世紀初,在C/S那個年代但是很是火的,而如今,你出去找工做,估計都找不到。因此能夠聽信前輩們的一些話,可是也不能全聽,每一個人都須要有本身的判斷力,以及獨立思考的想法,這是很是重要的。

我老弟跟我說,他想考公務員,我說爲何？你知道公務員作什麼的麼？你知道公務員是怎麼工做的麼？他說不知道。他父母讓他考的,以爲夠穩定,他父母對公務員的認知還停留在他們那個時期,穩定,工資高,工做舒服,壓力小。可是隨着公務員的人流愈來愈多,公務員已經不像之前那麼吃香,福利沒有那麼好,競爭壓力也很是大,幾萬我的去爭取幾十個崗位,這尼瑪比高考難多了好麼？

現現在,高考制度只是幫你走入社會的敲門磚,相對而言最公平的一種人才方式,可是這種方式之後,未來確定會改變。而大部分學生都不知道高考意味着什麼,對本身的未來意味着什麼,甚至不少人爲了進入某個大學,而匆匆報了個本身都不知道是什麼的專業,就去上課了。有的人及時醒悟,他們是幸運的,而有的人一路走到黑,你說是他們本身運氣差？仍是當今的人才篩選體制不夠完善呢？

再舉個例子,不少人說外國的數學物理很簡單,可是他們每每坐進觀天。外國人教育的思想是興趣引導,若是你沒有興趣,那麼只讓你學習些基礎知識就好,若是你有興趣,甚至未來會進入這個行業,那麼授課的難度也會加深,由於興趣是學習的源動力,而壓迫式教育不是。這不得不說是咱們這一代的悲哀,可是我相信將來會越來越好,愈來愈完善。

不知不覺寫了這麼多，主要本身想說的話也太多,可能有些囉嗦,耐心看到這裏的人,也是厲害。

總之我以爲不少程序員進入這個行業都是興趣所致,也有部分人是由於想要找一個合適,體面的白領工做而進入這個行業,可是,在這個行業裏面厲害的,就是那種真正專一技術自己的人,他們每每都是稀缺人才,可遇不可得的厲害人物,而這些人大部分都有幾個特色。

1.從不制定本身的職業規劃,我寫代碼徹底就是興趣所致(任性)。

2.我制定項目技術方案是根據項目業務需求自己,而不是單單從技術的角度出發,所以程序員在應對大部分場景和工做需求中,廣度比深度更加劇要,可是若是你想要專精某個單一領域的知識,而且成爲專家,那麼深度就比廣度重要的多,而這種人才一樣難得。

3.跳出本身的溫馨區,大牛會寫的代碼有不少。從c,c++,java,到php,ruby,python,js再到go,swift,haskell,erlang統統信手拈來,並非別人天賦有多強,而是人家能適應新技術,跳出本身的溫馨區,慢慢積累,致使看起來比別人厲害的多,你要相信,憑現現在大部分人的努力程度,還遠遠輪不到拼天賦的時候。

4.投入100%的熱情,大牛寫代碼不是爲了錢,而是本身喜歡。

5.學會處理人際關係,以及表達自我想法,溝通能力,也是程序員須要掌握的一件事情,由於你的上司看重你的表現的,每每不是你實現某個功能的細枝末節,而是你對於整個項目的把控,以及溝通。他須要的只是結果,而不是過程,所以每每溝通能力強的資深程序員,最後都會往高層去發展,慢慢轉爲管理層,而若是你只是想要安靜的寫代碼,不想被這些無聊的事情干擾的話,那麼你能夠忽略這一點。作一個技術資深大牛，可是你要知道,這個行業不少資深大牛每每都是溝通能力強,技術高深的體現,除非你是求伯君,一我的單幹的蘭博式英雄。可是隨着年代發展,團隊式工做已是主流,你沒法一我的去單一的實現某個任務或者功能。團隊式開發針對開發效率,項目進度,項目複雜度,以及成本控制都比單一人員要好,而團隊式協做就代表,你必需要有最基本的溝通能力。

若是讓我在職業規劃上作出一種選擇,我但願技術走廣而不深的路線,業務上也同時齊頭並進。雖然整理文檔,寫項目彙報總結這些文檔會讓我痛苦不已,可是我以爲這纔是我應該走的路,也是最適合個人路。不過,也許過一段時間,我就不這麼想了。