程序員平常加班嚴重,是怎樣兼顧自己個人能力提升的?

每天加班到10點多,程序員如何安排時間提升自己,比如學習英語,或參加MBA課程,廣泛社交等?


當我們在討論加班與提升的時候,需要首先明白,加班背後的原因。

加班並不簡單粗暴的等於,工作太多,正常上班時間無法完成,所以需要加班。

從主觀和客觀上,我們大致梳理了導致程序員加班的「幾宗罪」:

  • 主觀上看:

1)接觸新的業務,初步的熟悉階段。一般這種情況在剛入職或者接觸一個新的領域/業務中比較常見,這種加班通常是階段性的。

2)接觸新的技術領域,技術轉型,這裡就包括使用的技術語言的調整,接觸的技術環境的變化等。這種加班和上一點一樣,在熟悉熟練後,會有所緩解。

3)個人技術追求提升,修整以前覺得不夠優雅的解決方案。這就是一個程序員對自己技術上的追求了,比如方案優化或者重整,這些都是對技術精進的需求。再加上有的時候一些解決方案上的提升會涉及到比較繁瑣的重構,一般這種重構都不會有專門的時間處理,通常都需要程序員自發進行加班。

  • 客觀上看:

4)業務的增長過快或開發人手短缺;

5)為解決線上突發情況,疲於奔命

總而言之,這就是業務需求的不斷增長和程序員人手短缺的基本矛盾。

100offer 認為,自我修鍊不一定只能在加班後的私人時間進行,加班本身就是一次進行自我修鍊的時機,機智的程序員知道如何更高效地利用它。具體的修鍊建議見下:


1)業務導向:在業務實現基礎上,多想一步

直白的講,這就是做一想二:即當我們要實現一個業務功能時,我們不能僅僅停留在功能實現的層面。怎樣可以多想一步?

a. 不了解多想一步的思路時,不如多確認一步。

作為技術人員,其實對業務的理解或者問題的理解與負責業務人員思考的角度是不同的。需求的提出方可能比你更加了解他未來的呈現,當你在實現功能A的時候,不如多和他們交流,這樣你在實現功能的時候,自然就會對他可能會有的擴展性有一定的把握,方便你留出未來的預案了。

b. 換位思考,把自己當產品的主人

如果你十分害羞,實在不想和業務打交道,其實你也可以考慮經常「換位思考」,把自己當成這個產品的設計者,想想這個功能/需求 是為什麼出現的,它要解決什麼問題,未來會有什麼需求。

2)技術導向:把你的代碼當成自己的孩子

什麼叫做把代碼當成自己的孩子,其實就是要建立好:把技術的精進當成終生奮鬥目標的觀念。

舉個例子,當你完成了一個簡單的需求,你的業務的響應時間從10毫秒增加到了100毫秒,你就要有一種心痛的感覺(危機意識),不斷地反覆捫心自問,為什麼慢了這麼多。當你對自己有一個技術上的目標時,你就會打開自己的雷達,努力提高自己代碼的性能。

那麼,我們怎麼做到進一步的技術提升呢?

首先,我們需要明白現階段待解決的問題的關鍵核心點,找到影響你解決這個問題的缺口。剛剛那個例子,為什麼我們會從10毫秒增加到100毫秒,你需要找到響應時間延長的原因。

怎麼找到這個影響解決的缺口呢?

首先,你要對每個邏輯都了熟於胸;其次,你需要一個強大的監控數據的支持,找到關鍵的路徑,集中進行性能調優。如果確實是因為業務複雜導致,可以考慮採用並行處理、橫向擴展的方案。

3)勤於總結:不要在同一個坑裡摔倒N次

程序員的工作,在接觸A領域時,你可能踩了一部分坑,花了很多時間去尋找解決方案。但可能只是短短一個月沒有接觸A領域,你就漸漸忘記了曾經踩的坑。等到你又要去接觸它的時候,又栽在了相同的N個坑裡,再重新找解決方案。聽上去就效率低下,所以如果實在覺得摔在坑裡太疼,不如記下來吧。這樣就做成了一本專屬於自己的踩坑指南。

另外,就像Henrik Warne在《程序員,你會從Bug 中學習么?》所說:

Nassim Nicholas Taleb 在 《Antifragile》中寫到:「錯誤包含豐富的信息」。Bug 幫助我們更好地理解系統,告訴我們怎樣提高編、測試和調試技巧。所以我認為儘可能從 bug 中學習經驗,是再正常不過的事了。

我發現為每個有趣的bug 記錄下來,讓我輕易學習到很多。在記錄的行為中我會對發生的事情思考得更深刻。同樣,一旦記錄下來,我可以在之後檢查發生的事情。偶爾,我也會瀏覽文件,只閱讀教訓部分,對我認為是從 bug 中學到的最有價值的經驗加強記憶。

這裡分享一個BUG修補記錄的例子:

【日期】:2004-08-17【問題】:當解碼 Q.931 信令時無限循環

【原因】:當在Q.931信令中發現一個未知的元素id時,我們試圖通過讀取它的長度來跳過它,並且將位置指針遷移幾個位元組。但是,在這個例子中的長度是零,導致我們反覆跳過相同的元素id。

【怎麼發現的】:在解碼一個 Ethereal 從 Nortel 追蹤到的安裝信息時發現了這個問題。他們的信息是 1016 位元組長度(包含大量快速啟動元素),但我們的 MSG_MAX_LEN 是 1000。通常我們會收到一條來自 common/Communication.cxx 的信息,但現在,當直接輸入需要解析的數據時,數組末端內存訪問越界,其恰好是 0,暴露了這個問題。

為了找到它,我僅僅在 9931 解碼中添加一些列印輸出。但很幸運數據恰好是零。

【修復】:如果長度是零,設置為 1。這方式總是行得通。

【在哪些文件修改了】:

callh/q931_msg.cxx

callh/q931_msg.cxx

【我導致的】:是的

【解決Bug的時間】:1小時

【教訓】:信任收到信息中獲得的數據。不僅僅是產生大量可能導致問題的數據。顯示長度為 0 也同樣不好。

來源:CPP開發者(微信公眾號ID: cppFans )

PS,善用搜索、多多交流 比獨自思考,會更提升效率。

4)保持好奇心:持續學習、拓展技術圈

技術總是不斷變化的、快速迭代的,想要跟上新的技術變化潮流,可以給自己整理出專門的時間去泡一泡技術論壇,多勾搭一些技術達人,進行以技術為目的的社交。當然,最重要的還是要保持對新技術的好奇心。

技術的追求是無止盡的,多看源碼、多看成熟的解決方案、多了解方案背後的原理、多看看視頻,多寫代碼,在實踐中強化能力。

這些其實就是Stay hungry, stay foolish的基本知識點。


說了這麼多方法,這裡還有容易帶來不必要加班的雷點分享給你:

1)簡單的c-cc-v可能給自己帶來無窮的工作量。當一段邏輯在很多地方都需要用的時候,可能有時,我們就去簡單的c-cc-v了。但一個功能是不斷拓展的,可能一開始你還記得這些地方引用了這些代碼,但隨著業務逐漸複雜,可能改了A處、B處,發現C、D、E處沒有改,然後就只能加班了。

這就是一時的偷懶帶來的多餘工作,當你發現很多地方都用到同一套邏輯,不如把它封裝成一個函數,可能這個寫起來比你c-cc-v需要更長的時間,但是其實節約的是未來的時間,以及培養的是考慮代碼復用性及程序的魯棒性的思維。

2)如果沒有風險意識 可能就真的只能加班見了

當每次上線新的版本的時候,僅僅考慮function well的狀態,忽略萬一掛了的狀態,帶來的後果,可能就是真的掛掉,加班解決了。所以,做好風險把控,做足測試,克服萬難做好回滾措施,不要掉以輕心,真的可以幫你少緊急加班哦。

以上就是關於這個問題,100offer想要分享的方法論。

還是希望大家健康作息,少加班,多成長。


只用Google不用百度,只看英文文檔就是學習英語了,先做到這點吧,大多數程序員都做不到這一點。

仔細思考一個問題,你加班是因為工作多還是因為效率低?

我的經驗是,大多數情況下是因為效率低,而不是工作量大。

比如,絕大多數程序的編譯速度都有很大提升空間,我曾經多次把一個項目的編譯速度提升至少一倍。工程師在進行編碼-&>編譯-&>測試-&>調試循環的時候,編譯時間是白白浪費了。

機器內存夠大嗎?用了SSD沒有?編譯器的PCH配置對了嗎?頭文件是不是太多不合理?IDE里那些提升效率的插件都裝了嗎?

MBA課程里一個重要內容就是怎樣提升一個組織的生產效率,你如果連自己的效率問題的都沒解決就不要去試圖解決組織的效率了。


工作每四個小時裡面抽一個小時出來看書。

反正要拚命加班的一般都是工作效率不高的情況,再低一點別人也無所謂了。

然後慢慢的,等你能力提高了,你四個小時裡面就能抽兩個小時出來看書了。

然後再慢慢的,你就有辦法在另外兩小時的工作時間裡面提高自己了。


工作兩年,收發的幾千封郵件全是英文,所有閱讀和書寫的文檔全是是英文,搜索全用google,看體育消息基本靠espn,知乎時間慢慢被Quora代替,地鐵上讀的書也從《資治通鑒》變成了《Life and death in Shanghai》,搞得說夢話都是用英語。入職一年時參加公司舉辦的innovation forum,在台上看到下面坐了一個老外boss,厚著麵皮臨時起意用英文講完了一個小時的lecture+QA環節。不知道這些都算不算是在提升自己。

工作兩年,雖然沒做過太多的paper work,但是基本上Word/PPT/Excel/Visio都用了個遍。一開始漫不經心,但是現在開始很認真地意識到用好這些工具的重要性。特別是PPT,如題主所說,因為有潛在地讀MBA的可能性,決不能讓自己做出的slides在幾個月後還是「with no power and no point」。

工作兩年,從一個單線程動物慢慢進化成了可以同時handle N項任務的工程師。就我目前的眼界看來,所有的職業需要完成的工作都有其共通性。人們實現工作的高效率除了合理分配時間、集中注意力之外,遵循特定的方法論也是一個非常重要的手段。就以程序員為例子,在外人看來我們每天的生活都是在重複地敲鍵盤,寫一些不知所云的代碼。但實際上,這僅僅是工作很小的一部分。在編寫代碼之前,我們會花費大量的時間進行Feature discuss/Architecture design/Risk analyse etc,方案敲定後,寫代碼確實也就和搬磚沒多大區別了。即便是在做這樣一些看起來很專業的工作,我也學習到了除了專業知識以外的更多的東西。時間管理、精力分配、團隊合作、任務穿插以及無時無刻不在潛意識總結各種task的方法學,都讓我收受益良多。

另外說一下加班。因為所在公司是某老牌美企,講究的是所謂「快樂工作」,加班的人在這裡絕對屬於異類。每天一到18:00,周圍的座位基本就空了一半。其餘的人一般會用40~60分鐘來聊天,避開交通高峰期後也紛紛離開。等待七點後,剩下的也就個別年輕員工和某些快當上架構師的大牛了。就我個人經歷來說,剛工作時絕大部分加班確實是因為做不完分配給我的任務。這種情況基本上在入職半年後就消失了,之後的加班往往是想留下來做一些自己喜歡的東西。前段時間在微博上說,「加班不用來做有意思的事情,簡直是浪費」,基本概括了這一年半以來的加班狀態。

可惜,我喜歡這份工作,卻並沒有把它當做life job一樣熱愛。工作這兩年來,對金錢和物質的慾望膨脹到了程序員的這份工作已經不能支持的地步。我明白這不是一個好心態,可是當前只能被驅使著做出改變。正嘗試著做一些不一樣的事情,讀MBA,然後再投入到一段新生活。希望在將來能做到「get more, contribute more」。

PS:是誰說程序員每天都工作到10點的?有一些在外企工作的小姑娘,每天早上10點來上班,下午6點就走了,還拿高薪,生活不要太happy呀!!


當前職位能學到的都學到之後,如果既沒有經濟回報又沒有上升的途徑,就換工作吧。

完全不同意前面加班是效率低的這個說法,中國軟體行業的加班和效率沒有多大關係。如果公司只能招到低技術的開發人員,那麼就應該根據現狀,遵守勞動法,調節開發計劃。如果招到的都是高素質人才,很顯然效率低的說法說不通。歸根結底都是管理者的問題。

當然另外還有一種就是老闆喜歡加班的員工,所以很多人為了加班在拖時間,這種現象在中國軟體行業也不少,因為走得早可能被老闆看到評價不好,走得晚可能還能報銷打車或者晚飯。這其實也是中國軟體業的一股歪風邪氣。很多沒能力的混混就是靠能加班混進這個行業來的。

至於上班看書學習,如果和工作任務不直接相關,這就是職業道德的問題了。當然以中國軟體行業的環境,大部分公司沒資格和員工討論職業道德。

另外實際上知乎上很多號稱程序員的人,實際上已經在做管理職位,屁股決定腦袋,他們的說法不能代表基層軟體開發人員的想法。作為帶隊伍的人當然認為加班加點把工作儘快完成是正確的,因為這是他們的業績。

一個每天加班的公司不是好公司,有很小的可能是管理者沒有做好計劃的能力,很大的可能是惡意的壓榨員工。這家公司也許會發展的很好,可是作為一個基層員工真的沒有必要為老闆奉獻,程序員都是自由人,又不是勞工營的奴隸。


  1. 造輪子,自從我寫出「Luy一個類React框架」,並且支持redux,react-router,之後我編寫React代碼的速度有了質的提升,究其原因就是我對組件化,React內部,更加熟悉,任何需求信手拈來。
  2. 讀源碼,為什麼很多人永遠用著第一年的知識工作了十年?究其原因就是很少讀源碼(當然少造輪子也是一個原因),在這種你忙我忙大家忙的時代里,好的技術文章非常少,拼了命去找技術文章來補充技術,不如直接去你他媽的源碼。讀別人源碼,真的能學到非常多有用,並且實際工作中會用到並且增添你編碼速度的寫法。愛信不信,不讀源碼,加班加死你。
  3. 提高編碼速度是不加班的關鍵,然而如果你只會一種技術(比如某些見識比較少的所謂的前端工程師),大多數情況下你快不起來。
  4. 從來不寫測試用例的工程師,我認為如果你加班,真的很活該。測試用例雖然很傻逼,很沒技術含量,但是好的代碼一定是一鍵測試,一建打包,一鍵發布。因此,接上一條,只會一種技術的工程師,有你好受的。
  5. 繼續接上一條,不斷不斷的review自己的代碼,使得自己對自己的代碼熟悉,這一點很多人沒注意到,很多人寫了幾個月以後,發現一開始的代碼讀不懂了。堅持review代碼,是不出bug的或者是能迅速定位bug的關鍵,這節省非常多時間。
  6. 堅持重構,這一點要結合以上幾點來說。看了別人牛逼的代碼,重構。有了新想法,重構。出了更好的解決方案,重構。看似代價非常大的重構,使得你的項目永遠控制在一個維護成本最低的狀態,這種重構是值得的。重構的速度取決於你當時寫的測試案例,如果你不寫測試案例,那你重構就等著死吧。

把簡單的問題搞複雜,把複雜的問題搞簡單。這就是我提升編程能力的方法,比如leader安排完成一個任務,本來用熟悉的方法1個小時就能搞定,但我偏要用一個我不熟悉,只是聽說過但是有趣的方式,邊查資料邊完成,花了2個小時。實際上還是完成任務1小時,另外一個小時學習了。

再比如leader又安排了一個任務,我一看之前做過一個類似的,我找到上次做的代碼一看好像寫的有些冗餘,恩~,性能也不好,我就精簡了一些代碼,改善了一下性能,把本來複制粘貼再稍微修改10分鐘就能搞定的任務又花了2個小時才搞定,這樣我就又學習1小時50分。

關於學英語,我也給不出什麼建議,因為我是當初為了考GRE、托福,6各月的時間裡每天15個小時以上的高強度集中訓練出來的成果,這事上學的時候做了也就做了,工作了之後我只覺得我是每天8個小時高強度的訓練編程。

我不是很理解為什麼要參加MBA課程,以及廣泛社交。我只能說人的精力是有限的,魚和熊掌不能兼得,一樣技能只有積累的1萬個小時的訓練才能量變達到質變。同時進行的項目多了,哪一項都難以突破質變的那條線。愛好廣泛不是錯,但要有付出幾倍於別人努力的覺悟。


我沒太想好怎麼回答這個問題。

但是我每天的感受就是,如果不看點書(技術方面的),心裡就有點空,不安。所以每天晚上都要看一會兒書,哪怕再晚。帶娃上課檔口,在門口等娃,我也看手機、Kindle里的電子書。日積月累也能有不小的收穫。

所以,可能是如果習慣成為你生活的一部分,就會堅守,如同吃喝拉撒。如果當成闌尾般可有可無,是附加的,則想再多、求助再多都沒什麼意義。


弱弱地問一句,難道認認真真做好本職工作,通過技術手段解決項目中的問題,就不能提升水平嗎……?

比如說吧,加班多,是不是意味著開發效率不夠高?如果通過自己的努力實現少加班,不加班,是不是水平就提升了?


我說一下我個人的真實案例。

大學畢業後去了一家遊戲外包公司做了三年程序員。

每天工作時間不會超過4小時,其餘時間都在偷偷看東西。公司用的是C++。我會看看RoR,還有一些經濟學方面的書(我大學輔修經濟)。 這個是別人不知道的。以為我在工作呢。

後來要加班了。我不肯加。但是leader說早走會影響士氣。於是我就留下了當著大家面看報紙(第一財經日報)。。。

後來有一次員工評定的時候,leader跟我當面說,看我這樣做他很不爽,但是他沒辦法說出來,因為我的效率很高且bug很少。。。

所以呢,就按照@趙劼 說的做就行了。

PS.

我現在是一家小創業公司的CEO,在做自己的產品。其實在說這段話的時候,我不清楚這段話想不想讓自己的員工看到-_-。

不過反正他們暫時也看不到

又PS.

@趙劼 是我的學長呢~~


選份有難度,有挑戰的工作,全職干這個,比你琢磨著如何利用業務時間提升有效


Side project


我老公也是程序猿,工作三年半,每晚10點後才回家。即使這樣,他每天仍然在很努力地學習,具體事情如下~僅供參考:

1.他在ipad/kindle/電腦裡面都下載有自己感興趣或想學習的技術文獻和書籍(全英文),每晚下班回家後有2-3小時非常認真在閱讀和學習新知識;

2.他在所有通勤期間(上下班、外出吃飯坐車等)都會拿出ipad來看書~利用好一個人的碎片時間,陪我的時候就少看點(//偷笑)

3.他的所有電子設備都設為英文界面,平時上的也是全英文的網頁,都是一些技術相關的我也不記得了。。昨天看到他在學習神馬「變分法求泛函極值」,一直在啃英文維基百科。平時也會利用google scholar搜論文。

4.上quora瀏覽感興趣的話題。


很多時候,是程序員利用上班時間學了很多對自己有用的東西(暫時跟工作關係不是很密切的),導致手頭的活沒幹完,才得加班。。。同意的來點贊。

----------------------------------------------------------------------------------------------------------

其實工作中所謂有技術含量,有挑戰性的任務,反而不利於績效的提高。90%的公司里,真正能賺錢的是那些乏味的業務代碼,這塊做好了往往績效就低不了。但是這樣一樣,就與「提高自己的基礎技術和個人能力提升」有些矛盾。 底層的程序員很少有機會通過業務經驗來換來自己價值的提升,除非你被同行業競爭對手挖之類的。

另一方面,技術積累上的匱乏,會讓大多數程序員焦慮。這是很簡單的道理,因為你有足夠深的技術積累,可以做到「老子哪天不爽了,拍拍屁股走人,第二天就能找個待遇更高,條件更好的單位」。沒有這層心裡的強化,焦慮是遲早的。

我的意見,有兩點:

1. 在計劃安排時,盡量在時間上跟leader周旋一下,在可以接受的情況下,盡量拉長。這樣可以在幹完活之後,能有更多的時間學習技術。

2. 每天划出特定的時間學習你認為對你有價值的東西,比如每天在工作中抽兩個小時。如果碰到活比較多,那麼下班時間盡量把這個時間補夠,學習需要節奏,最好別斷。


今年暑假那段時間在公司實習,幾乎每天都加班,我又是習慣提早到公司工作的,所以每天工作時間大都超11小時,住的地方離公司也較遠,每天回去之後想看個書學習一下消化一下都沒時間。

那段時間工作很忙倒也接觸了不少知識,只是總沒有自己的時間去理解消化,整理歸納,發現其實這樣子是進步很慢的,感到不小的危機感。後來因為得回校了,我也順勢把工作辭了。

雖然在繁重的工作任務下兼顧個人能力的提升這方面還沒有什麼實際經驗,但我也有幾點想法,這是我對未來工作的思考:

1、天天加班的公司是不正常的,這樣的公司大部分是某些方面出了問題,要不就是老闆觀念有問題,除了在工作之外幾乎沒有自由時間是很痛苦的,至少對我來講是這樣子,可以考慮跳槽了;

2、爭取去那些有技術深度和業務深度的公司工作,這樣子技術提升會比較快,技術也不會「泛雜淺」;

3、踏實做些研究,有一個自己長期研究的技術領域,這應該可以叫做「真正的程序員的情懷」吧,我相信久而久之會讓你有別於其他人的。


提高自己的水平,把任務快速高質量完成,這樣就可以下班回家自己學習了,如果是強制性加班不能回家,同樣可以有時間學習(上班加班時間)。

至於說引入新的技術方法解決業務問題並同時學習新技術,那就要看領導是否開明了,開明的領導可以這麼做,不開明的領導是不會讓你使用新技術的。

對於英語學習,我覺得最重要的是還是辭彙量。我曾經以為多看英文技術資料英語就會好,英語技術資料對英語要求其實很低的,提高英語的第一步是背單詞,所以每天抽時間背幾百個單詞吧。

總之提高做事效率,才能有時間學習提高。


我是白天工作掙奶粉錢,晚上看書到四點多,有太多無奈,所以沒有學歷,但還有一份興趣!活多久不重要,重要是自己無憾!


多造輪子


高效的學習往往需要高效的方法配套,零碎的時間可以學習一些零碎的知識,然後拼接起來就是大量的內容。量變總會引發質變。

大規模的加班通常是在做一些沒有效率的事,這個時候可以提高效率。假設有四小時低效率時間,我們可以把需要做的事在三小時內解決,剩餘一小時可以這樣去提升自己。因為我就是這樣去做的。

首先呢,私以為最快掌握知識和融會貫通的辦法就是自己整理。我會通過一些網站去做到這個事情。就是建立屬於自己的書籍,然後去分門別類地整理。不會的地方去查資料,然後記錄下來,會的地方去慢慢地回想和整理,進一步加深印象。

整理呢,首先要有一個具體的框架,最好細分內容,慢慢去一點一點充實它。整理過程中會加深印象,融會貫通。這個的好處不需要我多說了吧!

不能理解的地方去互動區和一些大牛交流一下,畢竟術業有專攻。最後整理出來的東西就會編成一本書,這本書像自己的親生骨肉一般,完全是自己的心血,一方面獲得滿足感,一方面補充自己的不足。

因為寫這本書的過程會有一些滿足感和充實感,這會提供一些自我驅動的因素在裡面,完成它也是自然而然的事情。

這樣做的好處有如下幾方面

一,會的知識得到整理

自己會的東西能夠得到一些整理,思路更加清晰,也更加融會貫通,使用起來也會更加得心應手。

得到整理的知識和亂糟糟的一團不同,首先減少了一些自動檢索的時間,其次能夠對一些工作有更清晰的規劃,同時也能明白一些自身的強項和不足,利於下一步的系統學習。

二,不太清楚的東西加深印象,理解到位

有一些不太清楚的地方可以通過查資料,詢問行業大牛,與他人交流的方式去加深印象,加強理解和感悟。

總是有一些東西,說不會也會一點,說會也不是全會。這個時候我們需要去整理和理解,通過一些方式從他人那裡獲得知識,轉變為自己的內容。使這些東西也慢慢融會貫通,使用起來才能得心應手。

三,補充自己弱項,

有一些我們不清楚的,沒有去接觸過的東西。我們可以去查資料,慢慢了解,慢慢學習,把自己查到的資料和自己的一些理解和感悟加到裡面。慢慢去學習,使自己學到的東西越來越多,越來越全面。

通過自己感悟和學習的東西,以後稍有遺忘可以重新打開去看,去回想,去加深理解。三次四次之後就能基本掌握。

如果害怕文件丟失可以去一鍵保存到本地,有時間可以打開自己的電腦去看,去理解,去加深感悟。

又因為這本書是自己的心血,所以會格外珍惜,不像別的書。再好的書,只是囫圇吞棗,也不會起到什麼大用處。況且,大多數人不會把一本書讀好幾遍。

自己寫的這本書可以設置為隱私,不讓別人去看,也可以放在那裡,讓所有人都能看見。別人看了你的書,可能會提出一些建設性意見。這時候,可以去與他討論,可以交流,可以切磋,也是變相地增加自己的知識面。

也會有一些新手去讀你的書,無形中增加自己的自豪感。可以去討論區解決一些新手的問題,一方面幫助他人獲得內心的充實,一方面可以錘鍊自己的基本技能,也能讓新手獲得一些知識,豈不是兩全其美?

第一本書很快就能寫完,這個主要取決於你的空餘時間,還有你提高工作效率後所節省的時間。而且因為第一本書往往是自己的拿手領域,寫作速度也會快一些。而且寫完之後,自身的一個自豪感和滿足感是非常強烈的,它會驅動你去寫第二本,第三本。

第一本書寫完之後,我們基本對自己的強項有一個了解,也對自己所掌握的內容有了一個大體的把控。此時,我們開始涉足自己一知半解的領域,或者是自己感興趣但沒時間去了解的領域。

對於這些領域,我們慢慢去寫,邊查資料邊寫,邊理解邊寫,邊感悟邊寫。同時也可以去找一些這方面的人才去互相溝通,互相學習。這樣的話,他的轉化是非常快的,比盲目地學習有效的多,因為直接轉化成了自己的東西。

如果說我們能夠把這些時間利用起來,去做這樣一個高效的事情。長此以往,我們對於一些別的層面的把控也是非常強的,對於自身的也是很有利的。

這樣堅持一個月,我們學習到的是多少?堅持三個月,我們能學到多少?一年呢?只要自身技術過硬,還會去愁沒有高薪工作來找你?還會去愁沒有獵頭來找你?呵呵

至於我,我一直在http://www.markbj.com做這個事情,現在收益也慢慢開始體現出來,這個提升的是自身的價值,是一種無形中的東西,往往會比一些有形的東西更有價值。

看在我這麼有誠意的碼字,各位看官,能不能給個贊啊?


《修改代碼的藝術》《程序員修鍊之道》這兩本書讓我效率提升了很多。最近正在看《儘管去做》。

我的建議是首先應該研究的不是額外的知識,比如英語啊MBA什麼的。

而應該研究如何提高當前的工作效率。而且這種研究對於未來其他工作都是有好處的。

至於英語,如上面其他答主所說,只看英語文檔就會有提升。MBA?這和你工作有關係嗎?


推薦閱讀:

有哪些迅速提升編程技術的方法或途徑?
印度的軟體產業為什麼發達?
遊戲公司的程序員會不會在做項目的時候預留後門,然後自己編寫外掛之類的惡意程序賺錢?
為什麼會有編程行業的轉行做IT培訓?
為什麼主流播放器都無法變速播放WMV格式呢?

TAG:互聯網 | 程序員 | 編程 | 軟體業 | 能力提升 |