都說程序員吃的是青春飯？年紀大了何去何從

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

技術方向:

架構師,系統分析師,CTO

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

業務方向:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

小編給你們推薦一個iOS技術交流羣：763164022!羣內提供數據結構與算法、底層進階、swift、逆向、底層面試題整合文檔等免費資料！但願找到更多的同行多多交流！如下資料，進羣能夠免費得到哦