【萬字箴言】技術焦慮的減法與解法

作者介紹

楊建榮，DBAplus社群聯合發起人，現任競技世界資深資料庫工程師，Oracle ACE、YEP成員，超8年資料庫開發和運維經驗，擅長資料管理、資料遷移、效能最佳化，目前專注於開源技術，運維自動化和效能最佳化。持Oracle 10G OCP、OCM、MySQL OCP認證，《Oracle DBA工作筆記》作者。

“筆者的話：作為一個IT人，我們勢必都會有技術焦慮，如何脫離油膩的技術生活，讓自己有一個清晰的規劃，今天就和大家簡單聊聊我的想法。”

有一天走在路上，腦袋裡突然冒出一個詞：三十而立，可我的詩依舊還在遠方。三十歲左右，是一個讓人焦慮的年紀，而抬頭看看，全世界都在焦慮，所以本文我將先對焦慮做減法，再來看看技術焦慮的解法。

技術焦慮的由來

對於焦慮，美國著名心理學家羅洛?梅在他的代表作《焦慮的意義》這樣形容：

如果你在馬路上，看到一輛疾駛的汽車迎面而來時，我們會感到恐懼，心跳加速，快速橫穿馬路到達安全地帶；

而當我們處於朝不同方向疾駛的汽車流，被困在馬路中央時，我們心跳加劇卻又無所適從，心裡產生一種深深的空洞感，這就是焦慮。

簡單來說，感覺到威脅、找不到突破口，內心空洞，這就是焦慮。技術生活何嘗不是如此，我簡單問了幾個朋友，他們對於技術焦慮的看法如下，我簡單做了標註。

怕自己學到的不是有用的，或者說會很快被淘汰的技術，又或者是不值得花費大量時間學習的技術。——找不到突破口

年齡大了，職業發展是個焦慮點。——感覺到威脅，內心空洞

剛畢業時想學各種各樣的新技術並進行實踐，有段時間突然靜下來發現幾乎一無所成，只是知道一些名詞和方案，如何落地推進都沒真正實踐。——找不到突破口，內心空洞

33歲的人了，還是丟不下技術。——感受到威脅，內心空洞

一直有個擔憂，看到大家分享了很多技術方案，但這眾多的技術方案也容易讓一些同學迷失自我，不知道該從哪入手，如何選擇。——找不到突破口

目前沒有一個清晰的技術規劃，很容易在繁華技術方案中迷失自我。都知道適合自己的是最好的，適合自己未來2~3年規劃的是最佳，但實際上還是東一榔頭西一棒槌。——內心空洞

如果一定要給這三點給一個更通俗的解釋，可以歸納為焦慮的三個階段：認知、認慫、認命。有時發現，我們很多人更願意去說去想，而不是去做。那怎麼解？下面從問題入手，來看看對策。

一．“感覺到威脅”的解法

1、要有一個清晰的規劃

凡事預則立，不預則廢，制定計劃是給自己的一個心理暗示。給自己一個階段性目標，然後把它做分解，拆分成為自己能夠實現的一些任務。

規劃做多久？短則一週，多則兩年。我們都是心智成熟的人了，就不用再灌什麼雞湯了。去新公司面試時，一般也會問一下你的職業規劃，但我覺得很多人都沒想明白。我們做了計劃都很難保證達成目標，但如果沒有計劃，結果更可想而知。就好比資料庫中執行SQL都需要有執行計劃，執行計劃也有很多的效能差別，比如下面的3個表關聯，就有這麼多的執行路徑可供選擇。

計劃制定了，還要有一個規劃和章法，哪些是優先的，哪些可以排後。

如果你畢業有五年了，會明顯發現有規劃和無規劃的身邊同學差別其實還是蠻大的。所以有些同學一邊刷著段子和電影，一邊感慨世事不公、懷才不遇，其實你缺的是一個規劃並付諸實施。

2、我和技術焦慮的故事

在《我也可以是流浪詩人》中有幾段話，很有意思，摘錄一些分享給大家：

做你沒做過的事情，叫做成長；

做你不願意做的事情，叫做改變；

做你不敢做的事情，叫做突破；

我覺得很受用，自己似曾想過但沒想通的問題，好像有了一些答案。

聯絡一下我自身，我希望找到一個能夠施展拳腳的舞臺，有考慮大廠，畢竟有光環效應，不需要從0開始，如果以10分來估算，直接可以從7、8分到達9分，而如果是一個新的公司，那麼很有可能就是從3分甚至從0分開始。我已經厭倦了大廠光環效應，也厭倦了只說不做的浮躁，如果有時做事總是隔靴搔癢，我就會有一種感覺，所謂的技術焦慮和公司的關係不大，而是自己在職業發展的道路上存在困惑和問題。

我在給DBAplus社群的MVP獲獎感言這樣寫道：“所謂迷茫就是懶，多做點實事就有目標和方向”，那麼問題來了，該做哪些事情，該怎麼做，一系列的3W問題。先畫個圖說明一下。

我之前從事的工作中Oracle方面較多，但因為工作還是有不少的機會來鞏固MySQL方向，所以從技術棧上來說，資料庫方向也算是站穩腳跟了，這可以說是成長。

但從一個整體的角度來說，我只是做了其中的一小部分，下面是兩個大圓圈，分別代表資料庫技術和開發技術，資料庫技術中目前的工作中能夠直接拿過來複用的就是一些規範和架構設計的東西，而且這裡面還有很多對我來說是新的思考方向和挑戰。MySQL純技術棧的內容其實算是常規，如果目前的工作業務量還遠未達到瓶頸點，效能最佳化的部分少一些，那麼我們首要鞏固的就是開發自動化平臺。

新問題來了，資料庫開發方向目前很清晰的一個點就是自動化運維，確切的說，是DB自動化運維平臺，說是重構也好、重建也好，不是完全從零開始，但基本是從零開始的節奏。要做這個事情，得有人來帶路，大家都不知道怎麼走，站在原地討論plan A、plan B，問題肯定是解決不了的，得有人邁出來，大家都不會，你就得衝在前面，大家沒考慮的問題，你考慮到了；考慮的問題，你已經心中有數了，這事情就可以幹了，這就是改變。

我做事喜歡結果導向，喜歡快速迭代，能10分鐘搞定，絕對不願意花15分鐘。但是技術行當，還得耐得住寂寞。因為很多事情10分鐘搞不定，可能100分鐘，1000分鐘也搞不定，但這不代表我們真搞不定，需要花一些時間，花一些額外的代價來補課。水到渠成的時候，自己也得到了成長，這就是突破。

3、把握核心競爭力

對很多同學來說，做技術的核心競爭力，除了豐富的業務經驗（這個需要時間的積累），技術層面的積累也是需要一個體系的。

比如一個工作10多年的老司機和剛工作的新手，處理一個簡單問題的時候，大家的表現都差不多，很可能新手精力更充沛，做得更快，但一旦有了一些緊急的情況時，新手就會手足無措，這就是經驗的價值。經驗的價值在現在的大環境下空間也在不斷壓榨，以前的獨門秘籍和攻略隨著知識積累和痛點的積累，都會逐步解決，所以要去做更有難度和價值的事情，這些都是經驗的積累和鋪墊，時間是個好東西，它會不斷證明你有多幼稚。

我眼中的工程師模型是這樣的，簡單三個特徵：鷹眼（眼光犀利），獅心（內心強大），繡花手（做事認真細緻）。

還有一個方向就是技術積累，在學習計算機的時候，我們知道：程式=演算法+資料結構，但這一點在如今的時代，大家好像都忽略了。我舉一個例子，編譯原理想必大家在大學都學過，但包括我還有很多同學，應該都在大學完美地繞過了這個學習的痛點，有很多人在想，學習編譯原理有什麼用，這裡答案我都給你找好了。

（來自知乎的一個不錯的解答）

關於編譯原理我一直最喜歡類比的就是人體解剖 。在歐洲教會還不允許做屍體解剖時就有兩類人在一起偷偷摸摸搞人體解剖：一類是醫生，從外科手術的角度來說應該比較容易理解，不解剖根本不可能知道如何做外科手術；還一類則是畫家，他們只是為了可以更好地在描繪皮膚時體現肌肉的質感，就願意冒著被教會處罰的危險來參與人體解剖。而且即使是現在，所有的現代繪畫的教育雖然不會再像醫生那樣實際操作解剖，但肌肉層的解剖圖仍然是必修課。

在我看來，完全不懂編譯原理的程式設計師，就好像是完全沒有學過人體解剖圖的畫家一樣，當然不會說一定就無法成功，不過如果有更好的基礎可以提高成功的機率。在知道底層的情況下，對上層的描繪會更加寫實，更加生動。

拋開比喻，從現實的方面來說，編譯原理學過之後的益處（不考慮最後都沒有入門的情況）包括：

可以更加容易地理解在一個語言種哪些寫法是等價的，哪些是有差異的；

可以更加客觀地比較不同語言的差異；

更不容易被某個特定語言的宣揚者忽悠；

學習新的語言是效率也會更高；

其實從語言a轉換到語言b是一個通用的需求，學好編譯原理處理此類需求時會更加遊刃有餘另外還有一點，就是一直有人說不用重複造輪子，所以不需要學習編譯原理這樣的課程。

我想說的是，學編譯原理不是讓你去造輪子（大多數人的實力，學了也造不出輪子），而是要讓你知道現在一共有多少種輪子可以選擇，它們的特性如何。好比F1比賽，其實現在所有的車隊可選的輪胎都是一樣的，但不同車隊根據自己車的情況和戰術等，做出的選擇會截然不同。如果你對輪胎的理解只是它可以轉，那麼你根本無法把它的能力發揮到極限。

大學裡面幾門非常核心的課程，比如作業系統原理、資料結構、計算機組成原理、演算法，這些在你工作的一些年頭可能不會排上用場，但等到了一定的階段之後，這些就是你思維的沉澱，計算機技術就是在前仆後繼的貢獻中不斷積累起來的，沉澱下來的很多理論和問題處理方法，光想肯定是想不出來的，我們得抓住幾個點或者面深入下去。有些同學說現在的大資料學起來好難，深度學習也很難，因為理論層次上升了一個臺階，會明顯感覺到壓力。

4、技術短板理論

很多年前大家都會提到一個短板理論，把技術做得很純粹的同學會有一個很明顯的天花板。

很多做技術的同學會在一定的年齡之後糾結是做技術還是做管理，會有一個技術線和管理線。如果可以，我還是建議以技術為主線做一些管理工作，不要偏離一線，讓能聽見炮聲的人來指揮這句話還是有道理的，技術圈的人比較執擰，基本都是以技術服人，純靠管理很難推進。

三十年河東，三十年河西，技術不斷的發展，解決了很多痛點，這些年來短板理論也受到了挑戰，在這種需求之下，不溫不火的演算法工程師這些年來真是大紅大紫，不乏一些百萬年薪的高階職位。但如果細細看下面的圖，會發現只是某一方面夠強，需要付出更多。換句話說，要突破短板瓶頸，你得在某一方面已經非常強大，要不就很容易被雞湯。

5、換工作這件事情

三十歲後，人生逆襲的天花板開始收窄；其它賽道也會收緊閉合，很多時候我們只看得到自己眼前的那條。

技術圈內也有不少朋友，現在大都成了行業內的中流砥柱，會時不時有招人需求，我也會幫忙推薦一些朋友。每每想起招聘需求，很多時候的JD都是他們得自己根據一些需要來臨時補充。說簡單一些，那就是技術過硬，人要靠譜。

技術過硬這一點無可置疑，但我也有一些不同的意見。從我的感受來看，現在的公司面試已有了非常大的變化，早期的面試可能還有筆試、若干流程，還有些公司有一些辯論會之類的，說白了是一些輔助——加分。

現在的很多公司對待新人也不會有一個相對平滑的培訓週期、逐步的角色替換過程，有些加急的場景中，可能今天入職，這周或者下一週就直接上手。所以招人都是要直接上來就能用的，都不願意去培訓新人。換做另外一個極端，那就是很多新人還經不起培養就離職了，對公司來說更加得不償失，所以這是一個偽命題，重重矛盾但又相對合理。在這一點上，除了薪資，求職者更需要明白公司的文化（比如加班文化）是否適合你。Business is business。

而人靠不靠譜還是很難面試出來的，我們只能根據聊天來判斷他的性格，透過一些細節來看他是否誠實，透過幾分鐘幾十分鐘確實是很難的，這些都是偏主觀的判斷了。

市場行情都會變化，看到別人很滋潤，不心動是假的，所以焦慮也會時不時冒出來，讓人上火。其實不管外面是金三銀四，對於自己，你得清楚自己的一個基本規劃，向錢看or向前看，都要看，但是不要輕易迷失，千萬不要因為逃避而離職，那麼問題可能就是一種複製和延續而不是解決，哪個公司都有大大小小的問題，我們工作的本質就是要不斷解決問題。

6、份內份外的事情

什麼是份內的事情？就是你的本職工作；什麼是份外的事情？一種是把本職工作做得更好，或者是協調團隊產生更大的價值，份外的事情最大的特點就是你做了沒人喝彩，不做也沒人指責你，所以事情說小了是份內的，說大了是份外的，以至於我們在工作裡面做事情會分得很清楚，有了流程控制，至少出問題不會甩鍋甩到我這裡，要不就怪流程不完善。

但對於個人來說，份外的事情變成份內，是一種成長，比如你只會資料庫，去嘗試瞭解一些系統層面、儲存層面、核心層面的東西，也不是壞事，在這個基礎上去深入理解業務，能夠讓自己的眼界更加寬廣，考慮問題的角度更加全面，而不是一些孤立的點，還是需要用一個整體的眼光來看待分析和解決。所以我們有時候叫全棧，有時候叫做轉型。當然從技術角度來說，技術問題都不是問題，但是實際解決的時候，會有一些出入，很多問題到最後發現已經完全偏離了原來的方向，就是我們看待問題的角度不對。

業內份外的事情變為份內，Devops就算一個比較典型的，原本風光無限的DBA需要掌握一些其它技能：系統運維、系統開發等，敏捷運維在這個時候提出來不是憑空想出來的。很多重複性的工作需要得到簡化，很多複雜的工作若替代不了的，可能要麼直接被廢棄，要不推翻重來。這個過程有點類似於行業洗牌，能夠堅持在最後的，始終是那些擁抱變化的人。

份內份外的事情都是解決問題，解決了問題大家相安無事，其樂融融，解決不好，也是能夠把傷害和影響降到最低的一把標尺。哪些事情我是本著人情來做的，哪些事情不能因公徇私，可能就是這麼個理吧。

如果你覺得目前很舒服，不妨做些你不願意做的事情，做些改變，做些你不敢做的事情，來突破一下你自己。因為機會不會等著你，也不會問你準備好了沒。

7、能堅持下來的都是少數

有很多人向我取經，說職業生涯如何規劃，技術方向如何選擇，堅持了一段時間之後我們就失去了聯絡。因為我知道，做一件事情，能堅持下來的都是少數。你去面試，說我很專注，但這一點很難證明，如果捫心自問，這些年來自己堅持了哪些事情，好與不好，每個人心裡都會有一杆秤來衡量。

上面這個圖怎麼理解呢？其實是知乎一個有名的遊戲，即100個人每個人手裡有1塊錢，大家隨機交換，看最後每個人手裡剩下多少錢。經過真實的模擬，發現了一套理論。如果透過SQL來模擬，也是分分鐘搞定的，可以看到，絕大多數人都是原地踏步，只有極少數的人能夠走出這個圈子來。

左邊的圖是1000人的樣本，100次測試之後，手裡剩下0塊，1塊的佔絕大多數，基本是70%的比例，而能夠突破的人（有2塊，3塊）是少數（15%），卓越的人更少（5%），右邊的圖是允許你來透支，樣本是100人，得到結果和左邊是相似的。不知大家看到這個圖，內心是怎樣的感受，我個人覺得這些數字給我上了生動的一課。

工作生活都是如此，我們身邊有很多錦上添花的人，但雪中送炭的很少，做一件事情，要達到專注，不能鑽牛角尖，按照既定的目標來實現，方為上策。

二、“找不到突破口”的解法

1、理清技術方向和脈絡

技術圈的更新是極其快的，基本上不到半年就會有一些工具和方案出來。如果讓一個開發工程師寫一下自己接觸過的技術，估計能寫滿一頁A4紙。有了動力和方向，面對紛繁複雜的技術和方案，該怎麼選擇？

在混亂之中，我們要理清下面的幾個問題：

你瞭解自己的行業嗎，比如資料庫行業，技術的發展趨勢怎麼樣？

你關注的技術領域裡，有哪些好的解決方案可供參考，比如資料庫的高可用方案

這些領域中，有哪些行業先鋒，他們有沒有分享，部落格或者文章可供參考。

那些方案你用了嗎，自己做過測試或者生產實踐嗎？

新技術總是會滯後於實際的應用，穩中求進，不能一味大躍進。

欲事之無繁，則必勞於始而逸於終。實際落實下去時，發現碰到的問題很多，都需要一一克服，稍不注意就會成為瓶頸點，而且Web開發類的應用有非常多的框架，開源技術方向的技術變化很快，要熟悉這種文化，要適用新的技術思想，這些都是一個過程。

那這個怎麼來解？當然我也不會給自己太多時間，拿到一個結束時間點來反推這個過程的進展，這樣不一定可靠，但方向和動力是足的。王陽明說：想，都是問題，做，才是答案，道理說得已經很透了。

我們大體都會碰到很多技術問題，有些是通用的，有些是具體的。他們之間的關係和區別就很重要了，要不然總是很凌亂。他們大體的關係如下圖所示：

很快就會發現，我們能夠很快做出一個應用來，但如果分析一下核心的點，似乎很難get到。

2、學習效果金字塔

對於學習效果，可以參考下面的學習金字塔。這是美國緬因州的國家訓練實驗室研究成果，它用數字形式形象顯示了：採用不同的學習方式，學習者在兩週以後還能記住內容（平均學習保持率）的多少。

第一種學習方式——“聽講”，這種我們最熟悉最常用的方式，學習效果卻是最低的，兩週以後學習的內容只能留下5%。

第二種，透過“閱讀”方式學到的內容，可以保留10%。

第三種，用“聲音、圖片”的方式學習，可以達到20%。

第四種，是“示範”，採用這種學習方式，可以記住30%。

第五種，“小組討論”，可以記住50%的內容。

第六種，“實際演練”，可以達到75%。

最後一種在金字塔基座位置的學習方式，是“教別人”或者“馬上使用”，可以記住90%的學習內容。所以說我們的學習方式可能平時用得也不一定很科學。我個人實踐來說，這幾種方法都有其適用的場景，不能一概而論，如果可以，我比較喜歡主動學習的方式，尤其是技術分享的方式，比如你現在正在看我的分享

。

3、技術的學習方法

有句話說，若起不得法，則雜亂浮泛，所以我們還是要講究一些章法和技巧的。

（1）技術是有熱度的

我是DBA、做資料庫技術多一些，先來說說資料庫核心技術。Oracle核心技術2000年左右如火如荼，ITPUB上經常為一些核心的不明確問題，論壇裡面能炸開鍋的討論，隨著時間的推移還有技術熱度，這種情況不多見了。一來是堅持技術研究的人少了，二來是熱度沒以前那麼高了，或者說錢途沒以前那麼好了。

現在的MySQL技術依舊如火如荼，技術終究會越來越成熟，我可以想到幾年後，某些攻略不再是攻略，而是整合在資料庫裡很自然的最佳化方法，被詬病的問題也逐步被修復，那麼我們工作的意義和崗位存在的價值在哪裡？都說有了雲端計算，有了虛擬化，但事在人為，別指望能一勞永逸地解決所有的技術痛點，需求總是隨著時代的發展在不斷改進，對於我們自身而言，就是積累的行業經驗和過硬的技術能力了。

（2）抓住重點

資料庫技術那麼多，該怎麼學？我們看問題的時候瞻前顧後，想踏踏實實研究些技術總是被打斷，而有了時間鑽研技術發現有時候又不得要領。

記得Oracle大神Jonathan Lewis說過：Oracle資料庫中x$kcbsw結構包含了Oracle處理一個“會話邏輯I/O”所需的所有命名函式。在11.2.0.3版本，我曾指出有1164個命名函式，但看看執行在64位OEL（Oracle企業版Linux作業系統）上的12.1.0.1版本，這個數字是1300。這一變化對本書內容來說有多大區別？對普通Oracle專業人士呢？答案是“沒有區別”！

把這個回答繼續下鑽，就是一個核心的點：

大部分時候，只要大體知道引擎是如何工作的就足夠了，偶爾才需要知道一些世界上只有一小部分人才會知道的精確資料。注意，不要浪費時間去研究不必要的細節，而是要找到折中的辦法，使你所掌握的知識足以預判Oracle在你沒見過的場景中會怎樣做。

這個態度和思想普適所有技術方向的學習。所以對於我們來說一定是往前走，往上走，那個時候就不是改變了，而是突破。

（3）使用通俗的方式來理解技術

技術和生活是不分家的，有很多技術問題可以用生活的場景來描述，而很多技術牛人的魅力就在於能夠化繁為簡，能夠通俗或者用簡單的幾句話把一個複雜的事情描述出來。

比如TCP/IP的三次握手。很多人都有這樣的想法，這到底是什麼含義，為什麼要三次，兩次不行嗎，一次行不行。我們設定個場景，在地鐵站裡，手機訊號不好，快沒電了，兩個人走散了，這樣打電話：

“喂，能聽得到嗎？”

“我聽得到呀，你聽得到我嗎？”

“我能聽到。”

4、如何快速掌握一門技術

如果想快速學習一門技術，一種方式是透過程式碼來理解它的實現，來反推它的邏輯，這種方式的難度極大，而且能夠沉浸其中的人非常少，過程相對來說是苦悶的，但如果能夠沉下心來，看程式碼看到一種程度之後，有了感覺相信就會融會貫通了。身邊這種大神也有，但確實不多。

第二種方式算是捷徑，就是去聽聽作者怎麼說，透過他的分享來從整體對一個專案有一個基本的認識和了解，好比你去拜訪一個朋友，他熱情地把你領進門，帶著你走走客廳，走走臥室，給你介紹房子的裝修風格、裡面的傢俱和電器，為什麼要這麼設計，很快你就能夠對這一切熟悉起來。這種方式很好，而且最省事，但可遇不可求。

第三種是我比較喜歡的方式，就是透過對比的方式來學習，比如學習MySQL和Oracle的學習，有了Oracle的基礎學起來會容易很多。但越是深入學習，發現兩者的差別越來越大，不斷透過對比來完善自己的認知，從差異化中找到學習的重點和方向，也能夠對技術的發展有一個相對理性的認識。如果什麼都學，但都是淺嘗輒止，會浪費你很多的精力和時間，而且對公司來說也是浪費。

5、提問的正確姿勢

有句話說得好，“提問”在認知上的過程，就像射向未知空間的一支手電筒，至於是不是好問題，可以理解為有沒有指向問題本質的角度。對於提問，我大體總結有下面的一些不恰當的姿勢：

盲目提問，沒有日誌和說明，無法判斷；

自己不思考，不看錯誤資訊；

自己不分析問題，完全想依賴別人；

問題描述不清楚，或捨棄了重要的細節。

所以大家提問時，也最好能夠注意到這些，不是不解答，而是有些問題壓根沒法回答，自己先消化一下，或者換個角度來反問自己。喜歡答案的人很痛苦，因為他的世界觀不斷崩塌；喜歡問題的人很歡樂，因為手中的慧劍越來越鋒利。總之，被問題拍肩膀，總比被現實抽嘴巴子好。

況且，人往往是這樣的：在解決別人的問題時，會有各種說辭，但在解決自己的問題時，就只有寫詩和遠方了。

三．“內心空洞”的解法

1、版權意識和開源建設

對於技術焦慮中的矛盾和困擾，有時很難理得清，我用自己畫的一張圖來解釋。

在這裡想聊聊對於版權的理解，我以前也喜歡破解版，但在2016年寫了一本書《Oracle DBA工作筆記》後，我開始焦慮起來，也收到過很多有意思的反饋，有的同學上來就問我要電子版；還有的說出書能賺很多錢，讓我隨便送他幾本；還有的同學在網上的大店下單，沒收到貨質問我……當然也算吐槽吧，可以看到大家對於版權的認識還是不足的，所以我對版權的認識真是刻骨銘心，我現在也願意去花錢去買一些產品的服務。

《大話資料結構》中的編者欒大成說過這樣一句話：

國內原創技術書整體層次偏低，不是因為國內沒有高手，最關鍵的原因有兩條：第一，國內版稅太低，與高手作者的收入差別太大，導致很多人沒有時間和心氣來寫書；第二，國內智慧財產權保護不利，出版社無法用提高定價的方式來為讀者和作者提供更好的服務。

所以我想說，IT同行，請不要相輕。而我們再看看開源領域也是類似的，開源的理念不光是免費，還有開放。一收費很多人就受不了，別人也忙，別人也有事情，所以沒有什麼是應該的，別人不幫你也不會有道德綁架的嫌疑。可以看到有些開源專案現在很尷尬，技術方向都不錯，但沒有一個良好的模式來支撐發展。有精力和時間就參與一些專案吧，這個是突破自己，我敢肯定的說，會有不一樣的收穫。

2、對於技術分享的態度

在我的認知裡，我們很多人都是沉默的大多數，許多人不覺得自己在學習這件事情上值得分享，或者是討論，都在默默的看，默默的聽，認為這是自己的私事。而我的經驗告訴我，我給新手和老手做分享，總是會有收穫。

分享不光是技術大會分享、技術部落格，技術討論都是分享。所以無論何種形式，聽別人講道理，還不如看看別人走過的路和正在走的路，多看看同行們都在做什麼，對自己未來的選擇，有時候會有意想不到的幫助。對此，我有以下幾個建議：

認準了就不要放棄

如果你認準了一件事，就不要輕言放棄，拿我自己的例子來說，自己堅持寫部落格到現在已經有1300多天了，風風火火進行到了現在的第14輪，這個過程本身沒有什麼可以值得炫耀的，但對我來說，好記性不如爛筆頭，我抽空把每天的工作中碰到的一些問題做了總結，以後碰到同樣的問題可以縮短問題處理的週期。

先利己，再利人

這個話聽起來很功利，但從務實的角度來說還是中肯的，畢竟這個學習的過程首先是對自己有利，你可以從中學到很多東西，把自己的基本要求滿足了，自己的要求都達不到，又何談和別人分享、幫助別人呢。

當然自己動機也是簡單的，興趣所佔的成分居多，要不還是很難堅持的。如果一味朝錢看，也不一定能夠那麼有錢途。積累的過程中會有很多的誘惑，你需要去平衡，不要迷失自我。

短期實踐，長期規劃

如果你對某種技術感興趣，剛好也有錢途，可以做個短期實踐，自己可以多做一些練習來鞏固鞏固，很多時候紙上談兵的東西在實際操作時會有很大的差距。可以用自己熟悉的技術和相關的技術做一個關聯，看看能給自己的工作帶來哪些方便和好處。

我自己以前對Shell也是很生疏的，基本不會，但學習Oracle之後，在資料庫管理中發現指令碼管理很方便，慢慢地借鑑別人的、自己寫的，現在也積累了幾百個指令碼了，在工作中使用這些指令碼感覺還是非常方便和快捷的。

敢於分享

很多人對於技術分享還是有所顧慮，怕出醜，怕邁出這一步；有些人有分享的意願，但不夠主動；有些人是覺得沒啥可分享的，但如果適當引導還是能出一些大作的；還有些人很配合，會主動反饋，主動分享，我欣賞這樣的人。

3、焦慮也有優點

回到最開始說到的焦慮現象，為什麼羅洛梅要研究焦慮？因為50年代的美國人集體焦慮，大家都覺得自己有病。對此羅洛梅舉出兩個很閃亮的觀點：

焦慮是人類面對威脅，希望創造自我的正常狀態；

這種時代，每個正常人都會有焦慮，你不焦慮，就是麻木、冷漠。

從下面的圖可以看出來，焦慮和表現呈現倒U字型。一定的焦慮讓你表現更好，但一旦超過某個階段，過高的焦慮會讓你徹底崩潰，而太低的焦慮會讓人覺得空洞無聊。

最後用王泓人的一句話獻給大家：

對於我來說，最勇敢的事情不是辭職。

而是趁著年輕用所有的精力來充實自己的人生！