對於技術焦慮的一點想法
有一個公眾號是吃草的羅漢,最近看他的一篇文章,我被裡面的一小段內容吸引了,他這樣寫道:
在成長的道路上,有時你越是不喜歡的事,越會陰差陽錯的讓你遇見
在《我也可以是流浪詩人》中有幾段話,很有意思,摘錄一些分享給大家:
做你沒做過的事情,叫做成長;
做你不願意做的事情,叫做改變;
做你不敢做的事情,叫做突破;
我覺得很受用,自己似曾想過但沒想通的問題,好像有了一些答案。
聯絡一下我自己,離開搜狐暢遊之後,我就希望找到一個能夠施展拳腳的舞臺,有考慮大廠,因為不需要從0開始,如果有10分,直接可以從7,8分到達9分,如果是一個新的公司,那麼很有可能就是從3分甚至從0分開始,我已經厭倦了大廠光環的效應,也厭倦了只說不做的浮躁,如果有時候做事情隔靴搔癢,那麼我有時候就會有這種感覺,這個和公司的關係不大,而是自己在職業發展的道理上有了一些困惑。
我在給DBAplus社群的MVP獲獎感言這樣寫道,所謂迷茫就是懶,多做點實事就有目標和方向,(後面一句是洪穎幫我改得溫和委婉了些:)),那麼問題來了,該做哪些事情,該怎麼做,一系列的3W問題。
我畫個圖來說明一下,我之前從事的工作中Oracle的方面較多,但是因為工作還是有不少的機會來鞏固MySQL方向,而從技術棧上來說,資料庫方向也算是站穩腳跟了,但是從一個整體的角度來說,我只是做了其中的一部分,下面是兩個大圓圈,分別代表資料庫技術和開發技術,資料庫技術中目前的工作中能夠直接拿過來複用的就是規範和架構設計的一些東西,而且很多對我來說也需是新的思考方向和挑戰。MySQL純技術棧的內容其實算是常規,如果目前的工作業務量還沒有遠未達到瓶頸點,效能最佳化的部分還是少一些,那麼我們要鞏固的首要就是開發自動化平臺,新問題來了,資料庫開發方向目前很清晰的一個點就是自動化運維,確切的說是DB自動化運維平臺,說是重構也好,重建也好,不是完全從零開始,但是基本是從零開始的節奏。要做這個事情,得有人來帶路,大家都不知道怎麼走,站在原地討論plan A,plan B,問題肯定是解決不了的,得有人邁出來,大家都不會,你就得衝在前面,大家沒考慮的問題,你考慮到了,考慮的問題,你已經心中有數了,我覺得事情就可以幹了。
所以開發的部分就需要自己克服,而且開發web類的應用有很多的框架,開源技術方向的技術變化很快,要熟悉這種文化,要適用新的技術思想,這些都是一個過程。
當然我自己也不會給自己太多時間,拿到一個結束時間點來反推這個過程的進展,這樣雖然不一定可靠,但是方向和動力是足的。
這就到了第二類問題,面對紛繁複雜的技術和方案,該怎麼選擇。
我們大體都會碰到很多技術問題,有些是通用的,有些是具體的。他們之間的關係和區別就很重要了,要不然總是很凌亂。
我們能夠很快的做出一個應用來,但是如果分析一下核心的點,似乎很難get.
對我們很多同學來說,做技術的核心競爭力,除了豐富的業務經驗(這個需要時間的積累),技術層面的積累也是需要一個體系的。我舉一個例子,編譯原理,想必大家在大學都學過,但是包括我還有很多同學,應該都在大學完美的繞過了這個學習的痛點,有很多人在想,學習編譯原理有什麼用,答案我都給你找好了。
來自知乎的一個不錯的解答。
關於編譯原理我一直最喜歡類比的就是人體解剖 。在歐洲教會還不允許做屍體解剖的時候就有兩類人在一起偷偷摸摸的搞人體解剖:一類是醫生,從外科手術的角度來說應該比較容易理解,不解剖根本不可能知道如何做外科手術;還一類則是畫家,他們只是為了可以更好的在描繪皮膚時體現肌肉的質感,就願意冒著被教會處罰的危險來參與人體解剖。而且即使是現在,所有的現代繪畫的教育雖然不會再像醫生那樣實際操作解剖,但是肌肉層的解剖圖仍然是必修課。在我看來,完全不懂編譯原理的程式設計師,就好像是完全沒有學過人體解剖圖的畫家一樣,當然不會說一定就無法成功,不過如果有更好的基礎可以提高成功的機率。在知道底層的情況下,對上層的描繪會更加寫實,更加生動。拋開比喻,從現實的方面來說,編譯原理學過之後的益處(不考慮最後都沒有入門的情況)包括:1、可以更加容易的理解在一個語言種哪些寫法是等價的,哪些是有差異的2、可以更加客觀的比較不同語言的差異3、更不容易被某個特定語言的宣揚者忽悠4、學習新的語言是效率也會更高5、其實從語言a轉換到語言b是一個通用的需求,學好編譯原理處理此類需求時會更加遊刃有餘另外還有一點,就是一直有人說不用重複造輪子,所以不需要學習編譯原理這樣的課程。我想說的是,學編譯原理不是讓你去造輪子(大多數人的實力,學了也造不出輪子),而是要讓你知道現在一共有多少種輪子可以選擇,它們特性如何?就比如f1比賽,其實現在所有的車隊可選的輪胎都是一樣的,但不同車隊根據自己車的情況和戰術等做出的選擇就會截然不同。如果你對輪胎的理解只是它可以轉,那麼你根本無法把它的能力發揮到極限。
大學裡面幾門非常核心的課程,比如作業系統原理,資料結構,計算機組成原理,還有演算法,這些在你工作的一些年頭可能不會排上用場,但是等到了一定的階段之後,這些就是你思維的沉澱,計算機技術就是前仆後繼的貢獻中不斷積累起來的,沉澱下來的很多理論和問題處理方法,光是想肯定是想不出來的,我們得抓住幾個點或者面深入下去。有些同學說現在的大資料學起來好難,深度學習也很難,明顯理論層次就上升了一個臺階,有沒有明顯感覺到壓力。
還有一點很多年前,大家都會提到一個短板理論,把技術做得很純粹的同學會有一個很明顯的天花板,但是這些年來,短板理論也受到了挑戰,在這種需求之下,不溫不火的演算法工程師這些年來真是大紅大紫,不乏一些百萬年薪的高階職位。
有的同學說,我是DBA,這些和我也有距離,單說資料庫核心技術,Oracle核心技術2000年左右如火如荼,ITPUB上面為一些核心的不明確問題,論壇裡面能炸開鍋的討論,隨著時間的推移還有技術熱度,如今這種情況不多見了。一來是堅持技術研究的人少了,而來是熱度沒以前那麼高了,或者說錢途沒以前那麼好了。現在的MySQL技術依舊如火如荼,技術終究會越來越成熟,我可以想到幾年後,某些攻略不再是攻略,而是整合在資料庫裡很自然的最佳化方法,被詬病的問題也逐步被修復,那麼我們工作的意義和崗位存在的價值在哪裡。
一定是往前走,往上走,那個時候就不是改變了,而是突破。如果你技術基礎還不紮實,比如像看看編譯原理,不妨瞭解下編譯原理的三大經典書籍(龍書 虎書 鯨書),看看作業系統原理,還有演算法。
如果你覺得目前很舒服,不妨做些你不願意做的事情,做些改變,做些你不敢做的事情,來突破一下你自己。機會不會等著你,也不會問你準備好了嗎。來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-2148320/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 關於本書的一點想法
- 我的焦慮源於哪裡?
- 焦慮
- 騰訊全面上雲背後:程式設計師的技術焦慮和技術理想程式設計師
- “奶茅”伊利,困於中年焦慮
- 關於遊戲付費的一點想法遊戲
- 對於 CF1107E 中 dp 狀態設計的一點想法
- 一點想法
- 一個老程式猿的焦慮3
- 關於LCA的幾點想法
- 對5G技術的一點理解
- 【它山之玉】關於博士年齡的焦慮的一些安慰
- 而立之年的焦慮
- 一起教育的前進與焦慮
- 關於Camera對焦
- 用難測的期待去對抗既定的焦慮和迷茫
- 關於大資料技術的一點思考大資料
- 對於效能測試的一些想法,歡迎交流
- 程式設計師的焦慮程式設計師
- 在焦慮中等待的日子,是一種人生修行?
- 關於大語言模型時代下自學的一點想法模型
- 石頭科技的增長焦慮
- 從.NET看微軟的焦慮微軟
- 一點 Vue.observable 想法Vue
- SheerID:55%的消費者對冠狀病毒大流行感到焦慮
- 數業智慧心大陸 AI解答如何應對焦慮AI
- 一個錦囊,治好了甲方趙總的年底焦慮
- Science:感到焦慮怎麼辦?好好睡一覺
- 我收到一份《中國焦慮圖鑑》
- 關於EditText焦點監聽
- 跨過焦慮的最終法則
- 我是如何實現零焦慮的
- 機器學習的數學焦慮機器學習
- 程式設計師,停止你的焦慮程式設計師
- GSLB是什麼?談談對該技術的一點理解
- 一點技術思考
- 蕉下收割“防曬焦慮”
- 遊戲人請不要焦慮遊戲
- 程式設計師為什麼焦慮於程式語言和框架?程式設計師框架