1. 程式人生 > >35歲是程式設計師工作的終點!?(二)

35歲是程式設計師工作的終點!?(二)

“35歲是程式設計師工作的終點。”這句話到底是什麼意思呢?

猜想二:心態
35歲的程式設計師因為年齡和履歷的增長導致心態不再端正

那些令人糾結的困惑

人生是一場馬拉松,在漫長的征途中,難免有很多困惑。困惑就像枷鎖,使我們步履蹣跚,困惑就像死鎖,讓我們停滯不前。

接下來我將總結自己在工作中碰到和看到的一些典型困惑。這些困惑或者長期困擾本人,或者困擾我身邊的同事和朋友。當這些困惑被釋然之後,大家都感覺如重獲釋,為下一階段的征程提供滿滿的正能量。人生就像一場旅途,不必在乎目的地,在乎的,應該是沿途的風景,以及看風景的心情。良好的心態是技術之旅最好的伴侶。期望通過這個解惑之旅,讓大家擁有一個愉快的心情去感受漫長的學習旅途。

學無止境嗎

必須要承認一個殘酷的現實:人的生命是有限的,知識卻是無限的。用有限的生命去學習無限的知識是不可能完成的任務。一想到此,有些工程師不免產生一些悲觀情緒。如果方法得當並且足夠勤奮,悲傷大可不必。

雖然,人類的整體知識體系一直在擴張。但是就很多重要的工程細分領域,基礎理論並不高深。計算機的很多重要領域,工程師有能力在有限時間內抓住核心要害。

比如,密碼學被認為是門非常高深的學科,但是一大類密碼技術的基礎是數論中一個非常簡單的理論——素因數分解:給出兩個素數,很容易算出它們的積,然而反過來給定兩個素數的積,分解的計算量卻非常驚人。

“一致性”算得上是計算機領域裡面最經典的難題,它是所有分散式系統的基礎,從多核多CPU到多執行緒,從跨機器到跨機房,無所不在,幾乎所有的計算機從業人員都在解決這個問題,但是Paxos給出了一個很優雅的解決方案。

許可權管理是很多工程師的噩夢,但如果你能搞定“Attribute Based Access Control(ABAC)”和“Role-Based Access Control(RBAC)”,也能達到相當高度。
另外,技術學習是一場對抗賽,雖然學無止境,超越大部分對手就是一種勝利。所以,以正確的學習方式,長時間投入就會形成核心競爭力。

沒有絕對高明的技術,只有真正的高手

致力於在技術上有所成就的工程師,都夢想有朝一日成為技術高手。但技術高手的標準卻存在很大的爭議。這是一個有著悠久歷史的誤解:以某種技術的掌握作為技術高手的評判標準。我經常碰到這樣一些情景:因為掌握了某些技術,比如Spring、Kafka、Elasticsearch等,一些工程師就自封為高手。有些工程師非常仰慕別的團隊,原因竟是那個團隊使用了某種技術。

這種誤解的產生有幾個原因:首先,技多不壓身,技術自然是掌握的越多越好,掌握很多技術的人自然不是菜鳥。其次,在網際網路時代來臨之前,資訊獲取是非常昂貴的事情。這就導致一項技能的掌握可以給個人甚至整個公司帶來優勢地位。網際網路時代,各種框架的出現以及開源的普及快速淘汰或者降低了很多技能的價值,同時降低了很多技術的學習門檻。所以,在當前,掌握某項技能知識只能是一個短期目標。懷揣某些技能就沾沾自喜的人需要記住:驕傲使人退步。

所謂麻雀雖小,五臟俱全。如果讓你來做造物主,設計麻雀和設計大象的複雜度並沒有明顯區別。一個看起來很小的業務需求,為了達到極致,所需要的技術和能力是非常綜合和高深的。真正的高手不是拿著所掌握的技術去卡客戶需求,而是傾聽客戶的需求,給出精益求精的方案。完成客戶的需求是一場擂臺賽,真正的高手,是會見招拆招的。
在這裡插入圖片描述Java企業級電商專案架構演進之路 Tomcat叢集與Redis分散式和Java深入微服務原理改造房產銷售平臺,需要完整Java全套資料可以掃下方微信碼免費領取
在這裡插入圖片描述專案效果展示圖

不做專案就無法成長嗎

在專案中學習是最快的成長方式之一,很多工程師非常享受這個過程。但是一年到頭都做專案,你可能是在一家外包公司。對於一個做產品的公司,如果年頭到年尾都在做專案,要不然就是在初步創業階段,要不然就是做了大量失敗的專案,總之不算是特別理想的狀態。正常情況,在專案之間都會有一些非專案時間。在這段時間,有些同學會產生迷茫,成長很慢。

專案真的是越多越好嗎?答案顯然是否定的。重複的專案不會給工程師們帶來新的成長。不停的做專案,從而缺乏學習新知識的時間,會導致“做而不學則殆”。真正讓工程師出類拔萃的是專案的深度,而不是不停地做專案。所以,在專案之間的空檔期,工程師們應該珍惜難得的喘息之機,深入思考,把專案做深,做精。

如何提高專案的深度呢?一般而言,任何專案都有一個目標,當專案完成後,目標就算基本達成了。但是,客戶真的滿意了嗎?系統的可用性、可靠性、可擴充套件性、可維護性已經做到極致了嗎?這幾個問題的答案永遠是否定的。所以,任何一個有價值的專案,都可以一直深挖。深挖專案,深度思考還可以鍛鍊工程師的創造力。期望不停地做專案的人,就像一個致力於訓練更多千里馬的人是發明不出汽車的。鍛鍊創造力也不是一蹴而就的事情,需要長時間地思考。總之,工程師們應該總是覺得時間不夠用,畢竟時間是最寶貴的資源。

職責真的很小嗎

很多時候,一個工程師所負責系統的數量和團隊規模與其“江湖地位”正相關。但是,江湖地位與技術成長沒有必然關聯。提升技術能力的關鍵是專案深度以及客戶的挑剔程度。專案越多,在單個專案中投入的時間就越少,容易陷入膚淺。特別需要避免的是“ 在其位不謀其政”的情況。團隊越大,在管理方面需要投入的精力就越多。在管理技巧不成熟,技術眼界不夠高的前提強行負責大團隊,可能會導致個人疲於應付,團隊毫無建樹。最終“ 一將無能,累死三軍”,效果可能適得其反。

從技術發展的角度來說,技術管理者應該關注自己所能把控的活躍專案的數量,並致力於提高活躍專案的影響力和技術深度。團隊人數要與個人管理能力、規劃能力和需求把控能力相適應。一份工作讓多個人來幹,每個人的成長都受限。每個人都做簡單重複的工作,對技術成長沒有任何好處。團隊管理和專案管理需要循序漸進,忌“拔苗助長”。

一定要當老大嗎

有一些工程師的人生理想是做團隊裡的技術老大,這當然是一個值得稱讚的理想。可是,如果整個團隊技術能力一般,發展潛力一般,而你是技術最強者,這與其說是幸運,不如說是悲哀。這種場景被稱之為“武大郎開店”。 團隊裡的技術頂尖高手不是不能做,但為了能夠持續成長,需要滿足如下幾個條件:

1.首先你得是行業裡面的頂尖專家了——實在很難找到比你更強的人了!
2.其次,你經常需要承擔對你自己的能力有挑戰的任務,但同時你擁有一批聰明能幹的隊友。雖然你的技術能力最高,但是在你不熟悉的領域,你的隊友能夠進行探索並擴充套件整個團隊的知識。
3.最後,你必須要敏而好學,不恥下問。

否則,加入更強的技術團隊或許是更好的選擇,最少不是什麼值得驕傲的事情。

Java同行願更進一步者,來者不拒資料免費放送
在這裡插入圖片描述