沒有危機感的程序員,你在期望高薪從天而降?

程序員的30歲現象前端

在官場上,曾經有一個59歲現象,就是官員們會在59歲時,會使勁撈上一把。很明顯嘛,權力過時做廢,再不撈就要退休了,沒有機會了。java

在程序員的圈子裏,也有一個30歲現象。程序員幹到30歲,好不容易從碼奴混到了白領,卻再也幹不動了,還時時面臨失業的危險。30歲,是一個程序員傷不起的年齡。明天,何去何從?固然,若是你有鐵飯碗,好比在國企或政府機關,那你是沒法理解底層勞動人民的感覺的。同時也要恭喜你成爲體制內的一員,能夠一直幹到退休無憂。程序員

30歲現象人人都明白,但要給出一個定義並不容易。列舉幾個表現,也許你會以爲心有慼慼焉。面試

面臨職業瓶頸,程序寫不動,上升又困難。算法

薪水較高,加班變少,後浪追前浪,面臨失業壓力;生活壓力劇增,不敢跳槽;設計模式

招聘程序員年齡限制在30歲如下成爲行業潛規則,跳槽困難。性能優化

30 歲現象和59歲現象貌似不搭邊,其實都出於一樣的緣由:價值貶值。官員老爺在任就像皇帝,一旦退休,就成爲了平民百姓,貶值那是天然的。而程序員也同樣, 所謂三十而立,一旦到了30歲左右,因爲面臨結婚生子,一方面須要高薪撫養家庭,另外一方面卻沒法像之前那樣全身心投入到工做,性價比急劇降低;與此同時, 大批廉價的新手涌入,他們每每還使用最新的技術,老一輩程序員只能慢慢的靠邊站了。服務器

是否有不可替代性數據結構

30歲現象產生,只能程序員自身身上找緣由。架構

固然咱們也能夠產業、從社會、從政府、從制度等多方面進行分析,發現不足,這些分析未必沒有道理,可是確定沒有用,由於咱們沒法改變。所謂「命苦不能怪政府,命背不能怪社會」,從外部找緣由,只會讓咱們滿腹牢騷,成天以爲本身生不逢時,苦悶不堪。

從自身找緣由,試着問本身幾個問題:「爲何個人性價比如下降?老闆爲何要請我,給我高工資呢?一我的有價值是由什麼決定的呢?」

你也許能夠列出很長很長的答案,但我想應該均可以濃縮爲一句話:「一個的價值是由他的不可替代性決定的」。不可替代性能夠理解爲,爲了替代你老闆須要付出的代價。

由於你的可替代性高,因此性價比降低。反之,由於你不可替代性高,因此老闆會給你開高工資。不是這樣的嗎?

有一則小故事:

技師退休時告誡本身的徒弟:「少說話,多作事。」

十年後徒弟也成了技師,他找到師傅,苦着臉說:「師傅,我一直都按您的教導作,只知埋頭苦幹,可那些比我技術差的都升職了、加薪了,我仍是拿着過去的工資。」

師傅想了想,說:「你請一次假吧。若是一盞燈一直亮着,那就沒人會注意到它……」

徒弟恍然大悟,真的請了一星期假,等他回去上班時,廠長找到他說要給他加薪。原來,在他請假時,廠長發現,工廠已經離不開他了。

徒弟很高興,之後他時不時就請幾天假,每次請假後廠長都會給他加薪。一天徒弟請假後準備去上班,廠長卻告訴他:「你不用來上班了。」

徒弟苦惱地去找師傅,師傅說:「那天個人話還沒說完呢。一盞燈偶爾能夠熄滅一次,可若是它老是熄滅,性質就不同了,由於沒人會須要一盞時亮時熄的燈。」

故事中,由於徒弟的不可替代,因此廠長給他加薪;後來由於有其它的燈亮了,他被替代了,廠長不須要他了,因此被炒了魷魚。

因此咱們歸根到底仍是要提升本身的不可替代性。不然,一旦老闆以爲用較低的代價就能夠替代你,那麼你就面臨可能失業的危險了。

出路在哪裏

那程序員到了30歲,怎樣提升本身的不可替代性呢?咱們打算作一生程序員嗎?敢問路在何方?

做爲一個過來人、一個資深程序員,我以爲有幾個方向能夠選擇:

(1)成爲技術大拿

其實,作一生程序員並無什麼問題,重要的是,你必須成爲一個不可替代的程序員,也就是說,你要成爲技術大拿,可以解決普通程序員所不能解決的問題。技術大拿有兩個版本:

一 是程序員增強版。你仍然是一個程序員,但你是一個很牛的程序員,憑藉多年的積累,你在知識廣度和深度方面均已不是等閒之輩。從彙編到java,你樣樣精 通。你在乎數據結構和算法,對系統的優化有獨到看法,對設計模式如 數家珍,你還有完備的工具箱和本身的專用類庫。其實,增強版程序員有很是獨特的價值,惋惜的是,在現實中卻不多見,由於對任何一個公司而言,人才老是很稀缺的。老闆的眼睛是雪亮的,他怎麼會對你這種技術大牛視而不見呢,在你尚未成爲真正的 大拿以前,早已經被任命爲系統架構師、項目經理或者更高的職位了。所以,你想守住本身的一畝三分地,清閒的作本身的大拿,每每是不可能的。

二 是程序員升級版。雖然你的內在仍然是一個程序員,但你的職位已經升級了,你成爲了系統分析師或系統架構師。這是很是天然和現實的選擇。程序員與系統分析師或架構師之間並有鴻溝,只需一步而已,你就能夠從崎嶇山路駛向寬闊的大馬路。但這一步卻並不容易,須要幾年時間不斷思考、學習、實踐,才能化蛹成蝶。

(2)成爲行業專家

行業專家也是一個公司不可缺乏的角色,他們對公司的行業知識、業務流程和細節瞭如指掌。行業專家通常並非從外部招聘的一個只懂業務、不懂技術的超人,而往 往是從程序員通過多年的摸爬滾打成長起來的。做爲從程序員成長起來的行業專家,你每每還肩負系統分析師之職。在公司裏,對業務有通常瞭解的人不少, 但專 家級別的每每不多,爲了後30年的職業生涯,你必須成爲專家。

(3)朝管理方向發展

向管理方向發展的第一步,通常是被任命爲項目經理。在大部分IT公司裏, 項目經理是最小的管理崗位了,可能你不會以爲有太多驚喜,工資也沒有大的提高,但這個轉變,能夠說會成爲你一輩子中最重要的轉變之一。

不 要小看了項目經理。有人說,項目經理是一個古老的職業。也人有人說,21世紀是項目管理的世紀。事實上,從人類有組織以來,就一直有項目管理,之前的項目 經理多是部落首領,一次集體打獵、一次攻城拔寨,均可以視爲一個項目。項目管理的知識能夠應用到咱們生活的方方面面,大至登月計劃的實施,小至家庭聚會 的組織,都離不開項目管理。

一個優秀的項目經理,不只須要高智商,還須要高情商。能夠不誇張的說,若是你能勝任項目管理,你就能夠勝任戰術層的全部管理崗位,甚至你有家庭生活質量,也會提升到新層次。

然而,要成爲一名優秀的項目經理,並非一件容易的事情。能夠說,須要必定的天分,有些人無師自通,有些人卻永遠也學不會。程序員屬於高智商人羣,情商卻每每存在不足,這注定了只有少數程序員可以成長爲項目經理,成爲優秀的項目經理,則很是稀少了。

如何讓本身成爲大牛

那麼知道了即將面臨的危機,也知道了出路,如何去完成呢?怎麼樣成爲技術大牛?

這裏有幾個認知上的誤區:

拜大牛爲師

知乎上有人認爲想成爲技術大牛最簡單直接、快速有效的方式是「拜團隊技術大牛爲師」,讓他們平時給你開小竈,給你分配一些有難度的任務。我我的是反對這種方法的,主要的緣由有幾個:

大牛很忙,不太可能單獨給你開小竈,更不可能天天都給你開1個小時的小竈;並且一個團隊裏面,若是大牛平時常常給你開小竈,不免會引發其餘團隊成員的疑惑,我我的認爲若是團隊裏的大牛若是真正有心的話,多給團隊培訓是最好的。然而作過培訓的都知道,準備一場培訓是很耗費時間的,課件和材料至少2個小時(還不能是碎片時間),講解1個小時,大牛們一個月作一次培訓已是很高頻了。

由於第一個緣由,因此通常要找大牛,都是帶着問題去請教或者探討。由於回答或者探討問題無需太多的時間,更多的是靠經驗和積累,這種狀況下大牛們都是很樂意的,畢竟影響力是大牛的一個重要指標嘛。然而也要特別注意:若是常常問那些書本或者google可以很容易查到的知識,大牛們也會很不耐煩的,畢竟時間寶貴。常常有網友問我諸如「jvm的-Xmn參數如何配置」這類問題,我都是直接回答「請直接去google」,由於這樣的問題實在是太多了,若是本身不去系統學習,每一個都要問是很是浪費本身和別人的時間的。並且大牛很少,不太可能每一個團隊都有技術大牛,只能說團隊裏面會有比你水平高的人,即便他天天給你開小竈,最終你也只能提高到他的水平。

業務代碼同樣很牛逼

知乎上有的回答認爲寫業務代碼同樣能夠很牛逼,理由是業務代碼同樣能夠有各類技巧,例如可使用封裝和抽象使得業務代碼更具可擴展性,能夠經過和產品多交流以便更好的理解和實現業務,日誌記錄好了問題定位效率能夠提高10倍……等等。

業務代碼同樣有技術含量,這點是確定的,業務代碼中的技術是每一個程序員的基礎,但只是掌握了這些技巧,並不能成爲技術大牛,就像遊戲中升級打怪同樣,開始打小怪,經驗值很高,越到後面經驗值越少,打小怪已經不能提高經驗值了,這個時候就須要打一些更高級的怪,刷一些有挑戰的副本了,沒看到哪一個遊戲只要一直打小怪就能升到頂級的。

成爲技術大牛的路也是相似的,你要不斷的提高本身的水平,而後面臨更大的挑戰,經過應對這些挑戰從而使本身水平更上一級,而後如此往復,最終達到技術大牛甚至業界大牛的境界,寫業務代碼只是這個打怪升級路上的一個挑戰而已,並且我認爲是比較初級的一個挑戰。

因此我認爲:業務代碼都寫很差的程序員確定沒法成爲技術大牛,但只把業務代碼寫好的程序員也還不能成爲技術大牛。

上班太忙沒時間本身學習

不少人認爲本身沒有成爲技術大牛並非本身不聰明,也不是本身不努力,而是中國的這個環境下,技術人員加班都太多了,致使本身沒有額外的時間進行學習。

這個理由有必定的客觀性,畢竟和歐美相比,咱們的加班確實要多一些,但這個因素只是一個須要克服的問題,並非不可逾越的鴻溝,畢竟咱們身邊仍是有那麼多的大牛也是在中國這個環境成長起來的。

對於這種回答也是真的不知道該如何回答了,那些比你厲害的人難道不用上班?天天就很閒?

項目怎麼又延期,你說「沒有時間」;

怎麼不學習英語,你說「沒有時間」;

一塊兒去操場跑步,你說「沒有時間」那你的時間都花在哪裏去了?你的收穫是什麼?

我只能說不要用你身體的勤奮,掩蓋你精神的懶惰,剛看完一本書,名字叫做:「《哪有沒時間這回事》」

你老是很忙,可是你忙來忙去的一點收穫也沒有,或者說忙的沒有效率,爲何不想一想本身的時間都忙去哪了?知道本身有不少的地方作的很差,可是老是不能抓住一個去改正?這本書,給了一個很重要的提示,也是時間管理過程當中咱們容易忽略的一個重要的點,那就是——早睡早起。

分享個人經驗

做爲一名java程序員如何成爲大牛、架構師呢?

1、源碼分析

源碼分析是一種臨界知識,掌握了這種臨界知識,能不變應萬變,源碼分析對於不少人來講很枯燥,生澀難懂。

源碼閱讀,我以爲最核心有三點:技術基礎+強烈的求知慾+耐心。

我認爲是閱讀源碼的最核心驅動力。我見到絕大多數程序員,對學習的態度,基本上就是這幾個層次(很偏激哦):

一、只關注項目自己,不懂就baidu一下。 二、除了作好項目,還會閱讀和項目有關的技術書籍,看wikipedia。 三、除了閱讀和項目相關的書外,還會閱讀IT行業的書,好比學Java時,還會去了解函數語言,如LISP。 四、找一些開源項目看看,大量試用第三方框架,還會寫寫demo。 五、閱讀基礎框架、J2EE規範、Debug服務器內核。 大多數程序都是第1種,到第5種不光須要濃厚的興趣,還須要勇氣:我能讀懂嗎?其實,你可以讀懂的

耐心,真的很重要。由於你極少看到閱讀源碼的指導性文章或書籍,也沒有人要求或建議你讀。你讀的過程當中常常會卡住,而一卡主可能就陷進了迷宮。這時,你須要作的,多是暫時中斷一下,再從外圍看看它:如API結構、框架的設計圖。

下圖是我總結出目前最應該學習的源碼知識點:

沒有危機感的程序員,你在期望高薪從天而降?

2、分佈式架構

分佈式系統是一個古老而寬泛的話題,而近幾年由於 「大數據」 概念的興起,又煥發出了新的青春與活力。除此以外,分佈式系統也是一門理論模型與工程技法並重的學科內容。相比於機器學習這樣的研究方向,學習分佈式系統的同窗每每會感受:「入門容易,深刻難」。的確,學習分佈式系統幾乎不須要太多數學知識。

分佈式系統是一個複雜且寬泛的研究領域,學習一兩門在線課程,看一兩本書可能都是不能徹底覆蓋其全部內容的。

總的來講,分佈式系統要作的任務就是把多臺機器有機的組合、鏈接起來,讓其協同完成一件任務,能夠是計算任務,也能夠是存儲任務。若是必定要給近些年的分佈式系統研究作一個分類的話,我我的認爲大概能夠包括三大部分:

分佈式存儲系統 分佈式計算系統 分佈式管理系統 下圖是我總結近幾年目前分佈式最主流的技術:

沒有危機感的程序員,你在期望高薪從天而降?

3、微服務

當前微服務很熱,你們都號稱在使用微服務架構,但究竟什麼是微服務架構?微服務架構是否是發展趨勢?對於這些問題,咱們都缺少清楚的認識。

爲解決單體架構下的各類問題,微服務架構應運而生。與其構建一個臃腫龐大、難以馴服的怪獸,還不如及早將服務拆分。微服務的核心思想即是服務拆分與解耦,下降複雜性。微服務強調將功能合理拆解,儘量保證每一個服務的功能單一,按照單一責任原則(Single Responsibility Principle)明確角色。 將各個服務作輕,從而作到靈活、可複用,亦可根據各個服務自身資源需求,單獨佈署,單獨做橫向擴展。

下圖是我總結出微服務須要學習的知識點:

沒有危機感的程序員,你在期望高薪從天而降?

4、性能優化

無論是應付前端面試仍是改進產品體驗,性能優化都是躲不開的話題。

優化的目的是讓用戶有「快」的感覺,那如何讓用戶感覺到快呢?

加載速度真的很快,用戶打開輸入網址按下回車當即看到了頁面

加載速度並無變快,但用戶感受你的網站很快

性能優化取決於多個因素,包括垃圾收集、虛擬機和底層操做系統(OS)設置。有多個工具可供開發人員進行分析和優化時使用,你能夠經過閱讀 Java Tools for Source Code Optimization and Analysis 來學習和使用它們。

必需要明白的是,沒有兩個應用程序可使用相同的優化方式,也沒有完美的優化 java 應用程序的參考路徑。使用最佳實踐而且堅持採用適當的方式處理性能優化。想要達到真正最高的性能優化,你做爲一個 Java 開發人員,須要對 Java 虛擬機(JVM)和底層操做系統有正確的理解。

以上五大知識體系是我從業多年總結出來的經驗,都是當前最主流的技術。想學習這些技術的朋友能夠加羣:454377428。羣裏會分享這些技術知識點供你們學習免費下載

下圖是我總結性能優化應該學習理解的幾大知識體系:

沒有危機感的程序員,你在期望高薪從天而降?

5、Java工程化

工欲善其事,必先利其器,無論是小白,仍是資深開發,都須要先選擇好的工具。提高開發效率何團隊協做效率。讓本身有更多時間來思考。

「大話架構」阿里架構師分享的Java程序員須要突破的技術要點

沒有危機感的程序員,你在期望高薪從天而降?

注:加羣要求

一、具備1-5工做經驗的,面對目前流行的技術不知從何下手,須要突破技術瓶頸的能夠加。

二、在公司待久了,過得很安逸,但跳槽時面試碰壁。須要在短期內進修、跳槽拿高薪的能夠加。

三、若是沒有工做經驗,但基礎很是紮實,對java工做機制,經常使用設計思想,經常使用java開發框架掌握熟練的,能夠加。

四、以爲本身很牛B,通常需求都能搞定。可是所學的知識點沒有系統化,很難在技術領域繼續突破的能夠加。

5.阿里Java高級大牛直播講解知識點,分享知識,多年工做經驗的梳理和總結,帶着你們全面、科學地創建本身的技術體系和技術認知!

6.小號或者小白之類加羣一概不給過,謝謝。

目標已經有了,下面就看行動了!記住:學習永遠是本身的事情,你不學時間也不會多,你學了有時候卻可以使用本身學到的知識換得更多自由自在的美好時光!時間是生命的基本組成部分,也是萬物存在的根本尺度,咱們的時間在那裏咱們的生活就在那裏!咱們價值也將在那裏提高或消弭!Java程序員,加油吧

若是你以爲這幾方面都合適,那你還有幾條出路:

一是塌塌實實混日子。

說老實話,作老實人,辦老實事,拿老實的工資,這種員工公司也是很是須要的,通常不會遭遇炒魷魚的命運;二是轉行或者創業。

因 爲這個行業已經再也不適合你,已經沒有更大的發展前途,只能轉行。若是能夠轉行,未必是壞事,也許在新的環境中,能夠激發出更強的能量,創造出一番事業來。 至於創業,那就更具備挑戰性了,建議你在創業以前,已經成爲了一名優秀的項目經理。試想,若是轉不動一個項目,如何能轉動一個公司?

相關文章
相關標籤/搜索