學習編程的過程中可能會走哪些彎路，有哪些經驗可以參考？
最好能講一下自己學習這門語言的方法。
回頭看學生時代，最大的彎路就是怕走彎路、想不走彎路。
糾結該學什麼語言、該研究哪個方向、該做項目還是啃演算法，生怕一失足成千古恨，踏上一條不歸路。
很久之後才發現，與其糾結選擇，不如找個點堅持下去。好比爬山，你在山腳下糾結該從哪條路上去，而實際上，每一條都能通往山頂，每一條都不會是筆直平坦的。你怕錯過另一條路的風景踟躕不前，卻不知道只要登上山頂就可以一覽眾山小。
如果一定要說個經驗教誨，那就是儘可能多地寫代碼、讀源碼、讀文檔。
有兩個詞，一個叫做功不唐捐，一個叫做殊途同歸。不要浪費時間把vim配置成IDE，最終我還是用Eclipse寫代碼……
轉發近2000的編程心得：一個編程新手的自我修養
原文標題：我多麼希望我學編程時，有人教會我這些事。
原文地址：Things I Wish Someone Had Told Me When I Was Learning How to Code
原文作者：Cecily Carver
搬磚及翻譯：米洛
這篇文章在Medium上人氣很旺。轉發量和評論數都爆表。原作者回顧了自己漫長的編程學習之路，從中總結了許多個人經歷，走的彎路，和教訓。我翻譯了這篇長文中的大部分內容，希望能幫到題主及所有關注這個問題的朋友們：
1. 在學習編程之前，想清楚自己到底想寫什麼程序。
學習編程基本就是在學習建造東西。如果你知道你到底想造什麼，你的編程學習之路將會豁然開朗。如果你的目標只是「學習如何編程」，卻不知道自己到底想寫出什麼樣的程序，也不知道這些程序將如何讓你的生活變得更美好，你很有可能會感到編程學習令你沮喪，受挫。
說起來還有點丟臉，我最早想學習編程，是因為我想證明我聰明。並且，我也想做一份屬於聰明人的工作。我還喜歡思考數學及理論。因此，編程怎麼看都和我很搭。但是這些想法都不足以延續我的編程學習熱情。直到有一天，當我終於發現如何將科技（編程）與我的真愛---音樂和文學---聯繫在一起時，我才真正愛上編程。
那麼，你到底想用編程來幹嘛呢？網站？遊戲？iPhone應用？一個讓你暴富的初創公司？互動式藝術作品？你是想讓你的老闆對你刮目相看，還是想寫個程序讓電腦幫你完成一個枯燥的任務，以讓你能花更多的時間看水獺的萌照？也可能你只是想在職場中更具競爭力，為你的簡歷加一個潮詞（編程），或者滿足你學校的畢業要求。這些都是有價值的目標。你需要搞清楚自己的目標，然後有針對性地學習。
2. 編程一點也不神秘，一點也不難。
編程和其他技能沒有本質差別。就像語言學習里有語法和單詞；就像數學裡有不同的步驟和不同的題目；就像所有的技藝和手藝，編程里也有前人總結的針對不同任務的技巧，工具，和好的習慣。這些東西，你都可以自由使用，修改，或者棄用。
有個人曾這樣斷定，程序大牛和編程界的芸芸眾生之間有一個明顯的區別---後者往往缺乏足夠的智慧在編程界獲得真正的成功。在這個人看來，這種智慧包含對指針 (pointers) 和遞歸 (recursion) 的理解。
我在學校曾學過指針和遞歸。在學生時代，能理解指針和遞歸的感覺真心超級爽。這種快感激發我踏上了計算機學習之路。但在課堂練習之外，我極少有需要去碰這兩個概念。並且，當我在教別人如何學習編程時，我也一次又一次地發現，人們不用這兩個概念也能寫出很有趣，很贊的程序。
所以，不要害怕，也不要去想自己是否足夠聰明。想這些都沒意義。是的，編程任務越複雜，越難懂，你就需要越高超的技巧才能完成。但哪個領域不是如此呢？除非你這輩子就靠編程討生活了，否則你不太可能需要去理解編程中的遞歸。
3. 沒人能一次搞定
當你第一次學習編程時，你會很快撞上這麼個問題。你覺得你已配置好一切了，你查了又查，但你的代碼就是有！問！題！你對如何排錯毫無頭緒。錯誤信息（如果運氣好你有的話）很有可能對你說的是---「我了個大艹」。這個時候，你很有可能想要放棄。你覺得你永遠不可能搞定，覺得自己就不是編程的料。嘿！當我第一次嘗試編寫C++程序，運行，卻只得到 「segmentation fault」 這樣的錯誤代碼時，我也有過一樣的沮喪感。
但是這種經歷對任何一個水準的程序員而言，都再正常不過了。有過這種經歷，並不代表你的智商，技術悟性，或你和編程的適合度有任何問題。不管你是編程新兵，還是程序大牛，你都會遇到這樣的經歷。而新兵和大牛的區別就在於如何對待這樣的經歷。
新兵和大牛的一大區別就是信念。什麼信念呢？就是深信出錯的原因是符合邏輯的，並可以找到的，深信問題可以被解決，深信總有辦法實現自己的目標。從0到1之路也許並不明顯，但只要你有耐心，你通常都可以找到。
4. 總有人說你做的不對。
大括弧{}應該怎麼放放？該不該不用tab來縮進？該不該對代碼添加註釋？
對於這些問題，大家的做法各有不同。沒有誰有標準答案。很多程序員熱衷推銷自己的偏好的那種處理方式，但這不意味著答案只有一個。事實上，與那些說我做的不對的人面對面，然後再努力去搞懂他們說的到底是不是對的，這種來來回回，是我職業生涯的壓力源之一。
如果你與一個團隊的其他成員一起寫碼，總會有人不認同你的某些行為。有時他們是對的，但事實上你到底是！對！是！錯！永遠值得你親自去推敲。有時他們純粹就是無理取鬧，你別理他們就好了。
5. 總有人會說你不是一個真正的程序員
看看這些說法吧！「HTML不是真正的編程語言。」 「如果你不用vi，你就不是真正的程序員。」 「真正的程序員得懂C語言。」 「有些人就是不適合編程。」 「有些人就是學不會。」 「你根本就不是真正的程序員，我才是。」
要我說，編程對於不同的人有不同的含義。同時，編程的含義隨著時間的流逝也在變化。有趣的是，那些能讓初學者，甚至是編程老鳥，更快上手，更省事的工具，包，框架等往往會被貼上 「真正的程序員不該使用」 這樣的標籤。
這種貼標籤行為背後是一種恐懼：如果任何人都能稱自己為程序員，那這個頭銜就將毫無意義。不過，我認為這種閉關自守的行為是有害的。
去用那些讓寫程序變得容易的工具吧。如果那意味著你用 Stencyl 或者 GameMaker 來寫遊戲，而不是從零開始寫一個新的，沒事，只管去做。如果你第一次嘗試編程是從HTML或者Excel宏開始，沒事，只管去做。哪個（編程方式）你能堅持下去，你就用哪個。
隨著你技術不斷提升，你就會發現那些便利工具對你的限制大於對你的幫助。那時，你就會去尋找更強大的編程工具。但大多數時候，很少有人會看你的代碼，或者問你用什麼編程工具。你的程序到底好不好用才是真正重要的。
6. 堅持比方法更重要。
關於 「正確編程學習法」 和 「最佳編程學習法」 的文章有很多。的確，學習編程的方法有很多。你可以看書來學，你可以做練習來學，你可以給別人的程序捉蟲來學。當然了，也有很多種編程語言你可以挑選來作為你的第一門語言。
自學型的編程課程或者講座系列常常有個問題：一開始你總會學得很爽，但難度會陡然上升。print命令總是很簡單，但要真正搞定一個實用程序的編寫，往往讓人抓狂。你很有可能覺得跟著教程走卻並沒搞懂，然後你就開始抱怨教程有問題。
當你撞上這個 「編程玻璃頂」 時，那些教程和線上資源對你的意義已經不大了，因為他們默認你已經是一個編程好手了。更讓整個編程學習進階之路變難的因素是，你根本不知道自己缺什麼 (you don』t know what you don』t know) 。甚至，搞清楚自己接下來需要什麼都成了難題。
不管上什麼編程課，你都會有這麼一段 「撞牆期」 。唯一的解決辦法就是堅持到底。這意味著你要不斷嘗試新事物，學習新知識，不斷地，一步步地，去解決問題，去編出你要的程序。如果你這時認真回看自己的編程初心，你就更有可能獲得成功。
堅持到底，就會勝利。這就是我之前提到的信念的價值所在。如果你真的堅持到底，你就真的會勝利。
原作者推薦了這本書：Godel, Escher, Bach: An Eternal Golden Braid: Douglas R. Hofstadter: 9780465026562: Books
原作者推薦了這個博客：Joel on Software
本次搬磚及翻譯到此結束。由於時間倉促，難免會有一些差錯。大家如找出翻譯有誤之處，煩請私信告訴我。十分感謝！另外，祝大家周末愉快。
儘管我覺得我從知識的掌握上是走了很多彎路，但是這些彎路都培養了我的debug能力和獨立思考的能力，我覺得都是值得的。
花很多時間比較語言的優劣。
有這些時間兩門語言都入門啦。
怕吃虧是學習的一個大忌。
工業語言和新型現代語言都值得學習。
故事以後再寫，先上乾貨。
學習編程可能沒有捷徑，但一定是有彎路的，按危害程度，依次為：
- 不上機。
- 死磕「經典」。
- 玩鄙視鏈。
「不上機」這個毛病我都不想多說了，野生程序員 - 收藏夾 - 知乎 里多個回答都已經說過很多遍了。不管你是看書還是看視頻，正確的姿勢都是左邊翻開教科書，右邊就同時打開電腦——把代碼敲進去，把程序跑起來啊！在書上畫叉叉圈圈有個毛用！？
@姚冬 的說法我覺得特別到位：編程本質上是門手藝。三天不練手生，手藝是練出來的。你當然要看書，但絕對不是只看書就夠了。
自己上機過個手，首先能發現問題，別以為書上代碼寫得明明白白，視頻里人家演示得清清楚楚，你照著做就沒問題了——試過之後你才知道裡面有多少坑，而填了這些坑，就是你長了功力的地方。
其次，還能加深理解。「書讀百遍，其義自見」，但這話不適合編程，你得把代碼整出來擼，調試、設斷點、調堆棧，不斷的改不斷的試，在這個過程中不斷的折騰，才能領悟出代碼的真義。
挺有意思的是：很多不喜歡上機的同學，就喜歡死磕「經典」（那種既不上機又不看書的同學我們就不用說他們了）。這裡的「經典」是加了引號的，因為我認為真正的經典應該是深入淺出，雅俗共賞的。
當然，這種書很少。大部頭的書厚重權威，但看不懂，怎麼辦？我的建議是那就先看「小部頭」的，碎片化的都行。碎片化閱讀的危害是什麼？ - 知乎，我一直想去回答：沒什麼危害。但想想算了，一些閑書而已，想怎麼讀就怎麼讀，我也不去討人嫌了。但專業書籍，看著有的同學「鑽牛角尖」，還是有點可惜的。
想起我那時候讀書：
我來到圖書館，因為這裡的書夠多。比如數據結構，這本書我看不懂， 我就再找一本，還看不懂，我就再找一本……總有一本書，能用我懂的語言，告訴我這究竟是怎麼一回事！一本不行就兩本，兩本不行就三本……空蕩蕩的圖書館裡，我有一種進入了金庸武俠世界，博採眾長，修鍊高深武學的感覺。這種感覺不斷的刺激著我的腎上腺素分泌，那種日夜不止的亢奮，直到今日，我都再也沒有能體驗到過。
關於書，我印象最深刻的就是程傑的《大話設計模式》，裡面用「雕版/活字」印刷術做例子，唉呀！困惑了好久好久的問題一下子迎刃而解，真的是神清氣爽。但我看直到今天，大家對這本書的評價都不高，一說設計模式就是要「四人幫」的那本經典、原著、英文版……看不懂，那就是你蠢你笨不會讀書回頭再看一篇！其實啊，後來才發現，說這話的人，他自己除了能拽幾個名詞以外，對設計模式的理解也是雲里霧裡的——所以他們才什麼「經典」啊「膜拜」啊，其實不就是不明覺厲么？
關於「碎片化閱讀」，我最想舉的例子是 @金旭亮 老師的《金旭亮 一個IT人的十年》，我甚至可以說，就這麼一篇回憶隨記，再一次重塑了我的價值觀和世界觀。時至今日，重溫此文，仍然止不住的熱淚盈眶。我寫《折騰》 - 知乎專欄，我做 一起幫，難說根子就在這裡。同樣的，我也有技術上的收穫：
一個人如果沒寫過一萬行以上的程序，他看軟體工程書就同看政治書差不多，每句都對，呵呵，就不知道為什麼對 。
就這麼一句就夠了，這講的就是技術的真諦。
你看，又回到「多練」「多實踐」這條路子上去了。
說第三點吧，玩鄙視鏈。
哎喲，我真是轉到IT行業里來了，才知道還有「鄙視鏈」這麼個東西！人家說「文人相輕」，看來理工男也不甘人後啊，哈哈。
但我真得說一說，這東西真的只能「玩」：玩一玩可以，樂呵一下當個笑話聽聽說說都可以，認真你就輸了。
不管是語言也好，演算法也罷，前端後台……沒有高低貴賤之分，「術業有專攻」而已。而一味的「摳」底層，想學什麼「別人學不會」的語言，說明你根本就還沒入門。沒入門不要緊，要命的是你還自以為是沾沾自喜。
我為什麼敢這麼說？
「摳」底層，說明你還沒懂「封裝」，你沒有理解「封裝」的精髓，你辜負了這幾十年來前輩們的一片苦心，你這是在逆歷史潮流而動啊！（呵呵，稍有誇張，但矯枉必須過正嘛）做汽車是要了解發動機，但做汽車的人用不著自己去造發動機啊……那做發動機還需要鋼材，鍊鋼還需要採礦，採礦還需要勘探，勘探還需要……你要「底層」到什麼時候？
想學，或者想寫「別人看不懂」的代碼——這，這，本來想說這得多幼稚的，但很多初學者，尤其是「有追求」的初學者，很容易掉這個坑裡。代碼是寫給人看的，要「通俗易懂」才是好才是美。把代碼寫得讓人看不懂，是在犯「孔乙己」一樣的錯誤，這和知乎上的文青吹捧推薦所謂「小眾」的書籍一樣可愛。寫上一年的代碼，你就會知道，把代碼寫得讓別人看得懂，才是最難的！
我總覺得，這些誤區，都源自於心智的不成熟。學習編程，想的不是解決問題，而是「炫技」「耍酷」；不肯日復一日的在平凡的學習工作中錘鍊自己的技藝，而總是想找一個秘籍大法終南捷徑。
不想走彎路，往往才會總是走彎路。
+++++++++++++++++++++
本文收錄於：野生程序員 - 收藏夾 - 知乎，歡迎關注。 O(∩_∩)O~
++++++++++++++++++++++++++++
做個小廣告：註冊·一起幫（包含 邀請人：葉飛，邀請碼：1786）
我自己個人開發的一個網站，開發過程全程直播並有錄像（自由飛：在鬥魚直播寫代碼是一種怎樣的體驗？）
設立的初衷就是為了降低自學編程（也包括各種電腦軟體使用等）的難度，尤其是一些對新人來說「莫名其妙的」問題（比如配置不對、連不上資料庫之類的），問題本身沒多少技術含量，但確實新人自學過程中的攔路虎，自己瞎折騰不知道要花多少時間，但如果有人遠程桌面幫忙看看，很快就可以解決。
有興趣的同學註冊看看吧？
註冊·一起幫（包含 邀請人：葉飛，邀請碼：1786）
學習過程中的彎路是不得不走的，但是學習方法上的彎路還是可以繞的。
得到經驗和浪費時間終歸是兩回事嗎。
我是個完完全全自學入門的人，現在雖已經進入科班，但是我認為經驗還是可以分享給想自學編程的大家
的。當然如果題主是想要為了信息學的競賽學習，那我覺得這個答案就不適合你了，你應該選擇更為系統，更為針對，強度也更大的訓練方法。
1.
大多數人學習編程最早的懊惱就是不明所以的「燙燙燙燙燙燙燙燙」，雖然基本教育的節奏都是從偉
大的C語言開始，但是作為一個早早自學編程的人來看，C語言作為入門語言是很容易打擊人的（教材本身的質量也是一個因素），所以如果是自學入門的話，不妨學一學的入門容易規則簡單的語言培養語感和基本素養，例如PHP、VB這樣的東西，可以很快做出一個可以看可以用的東西，是很有成就感的，有了自信就自然而然得會想深入的提升自己了。
2.
自己當年中學的時候做論壇，那時候流行的是Discuz!，為了做好玩的互動插件學的PHP。當時的感覺是，自學一門編程語言並不輕鬆，在會的人看來容易的概念其實不容易灌輸給完全不會的人。最開始自己就是啃書本，上課都不記筆記的我把學習到的東西規規整整地記在本子上，直到把基礎的語法和語言特性都了解了才停止。不一定像我這樣，但是作為一個一清二白的菜鳥，一定要讓自己有一個把基礎的基礎看下去的驅動力才可以。
3.
實踐是檢驗真理的唯一標準。實踐對於初學者而言非常重要，但是C語言課本上的實踐大多是一些就事論事，針對知識的題目，面對一個控制台程序，其實做完了……過幾天也不會覺得這個有什麼意思，所以我認為一定要儘可能的嘗試去做一個可以用的東西。學PHP做個登陸頁面呀~學VB仿個Win計算器呀~學Java做個掃雷~總之做出能夠對除你之外的人都能有一點點興趣的東西，對自己是很鼓舞的。在這方面，C語言這種，對於初學者做圖形界面比較不友好的語言……主要的問題就是不會讓你產生那種真正解決問題的成就感。
4.
最開始的實踐是一種拼湊，因為知識的不牢靠，但是需要解決的問題對自己又是如此的龐雜，所以那個時候的代碼都是以能解決問題為主，而不是以好的方法解決問題為主。現在回過頭來看當年寫過的論壇家族，論壇寵物中心，從外觀上講確實是當時一流的，但是背後的代碼著實慘不忍睹。不過對於初學的人而言，能夠利用現有知識達成目標已經是竭盡全力了。那個時候的編程沒有精雕細琢，就是為了實現而實現，也不管有多少if套著if，甚至變數名我都能起成$if。不過我必須承認的是，沒有那段經歷，我可能不會如此的喜歡編程。當有人使用了你的成果，不管是對他提出建議還是提出讚美，對於一個尚未破殼的菜鳥而言，都是很棒的感覺。說實話，作為初學者，敢寫代碼，就是個裡程碑了。
5.
歷史和人的感覺是很像的，當你的代碼寫得多了的時候，你自然就會覺得寫得不好看。照現在的話講，那些代碼一點都不優雅。作為一個逼格滿滿的人，完成任務已經不再是一個追求，當Ctrl+C/V成了編程的必備步驟的時候，你自然而然的就會思考了：是不是可以不這樣做？這是一個重要的過程，你會想要提升你代碼的執行效率，你會想減少查詢資料庫的次數，你會想用輕便的代碼實現想要的功能……當你步入這個階段的時候，恭喜，菜鳥終於入門了。
這是三個大坑，演算法優化、資料庫查詢優化、代碼復用。
你得心甘情願跳進去，再慢慢往外爬。
5.
看上去我好像在抬高PHP一樣，其實不是這個意思。我只是覺得作為一個可以立竿見影的入門語言，它是很合適的。進入大學計算機專業後，我和同學一樣，一起學習C語言，我沒有接觸過這門語言，但是我卻比周圍的初學者們更快更好地接受了它，即便是像內存、數據類型、指針等從沒有接觸過的概念，我也比別人更快的認識清楚。我覺得這一方面是因為編程所帶來的學習能力的提升，另一方面也是因為我自認為我不是菜鳥所帶給我的自信和動力。我當時做了很多出格的事情，當講課、教科書都在用VC的時候，我執拗的使用VS2010，因為我覺得這個用戶體驗好。在課設說明書還在按照Turbo C說明圖形界面的時候，我卻找了個能在VS下使用的仿造的圖形庫EasyX。其實人都是追求美的，老師也不喜歡你開個DOSBOX滾動翔一樣的Turbo C給他演示。擅用和檢索現有的工具和資源，是這個時期我最大的收穫。
當然，這裡也挖了一個大坑，用戶體驗。
前幾天知道，我的學弟學妹們都放棄Turbo C了。
6.
在學校的學習過程是這樣的：C -&> C++ -&> Java。
C++和C截然不同，作為一個擁有面向對象特性的語言，它帶給我們很多新鮮的概念。儘管初次見面的時候我們彼此都如此羞澀，誰都看不懂誰。在學習C++的時候，其實我並沒有提起多大的勁頭，只是覺得STL很好很方便，在OJ上刷題的時候能比C省事不少。不過之後看到一本國外的關於物理引擎的書，便又是提起了12分的興趣看了看。那本書終歸我是沒有看完，不過只看一部分我便能感受到自己的膚淺——原來類是這麼用的啊。
很久之後我才知道這是一個高級坑：設計模式。
7.
之後數據結構的課程設計，按照套路是要用Java做UI的，但是Java的IDE在我的電腦上一直表現不佳，加上調試時候的種種不順暢，使得我我對Java做窗體程序好感不佳。於是我想起了初中的VB，隨後又聯想到了它的同門C#（求別問怎麼聯想的=。=），那種拖拽做界面的爽快感……經過我的推廣，班裡最後只有一人用Java做UI，還有另外一個人用的MFC。這個其實是想說，我這個人比較懶，所以喜歡找更好的解決方案，存在就有存在的價值，短短5天，所有人都可以用C#做出一個好看的界面，而Java搞得很麻煩又不好看。這不是在談優劣或是投機取巧，而是在談生產力、效率。我訓練的人可以5天上崗，做得比你訓練一個學期的人還要好，那這就是價值。
8.
其實一路走來，站的越高，自己就越容易被顛覆。
當PHP寫代碼覺得原始的時候，框架這樣的東西就會跳在你眼前打臉。
當WinForm程序做起來感覺到代碼混搭的怪異的時候，就發現其實還有個WPF。
當覺得Java臃腫性能堪憂的時候，高級的Web技術又會顛覆你對Java的偏見。
……
學習編程的人需要這樣一個自我認知和自我提高的過程，老實說，我覺得這其實不算彎路，這可都是經驗呀。這些所謂的彎路是你只要踏上這條路就必走不可的，就像是宜家的步道設計，人家設計好就是要你走遍全程。因為這是一個過程，學習過程上的彎路是寶貴的。
至於我之前所說的學習方法上的彎路，大多是指教材選擇、訓練方法上的彎路，這些彎路可以通過前輩的指導來避免，我覺得這種彎路走上了，就是浪費時間。現在時間這麼寶貴，我們都要講效率的。當大家都說譚老的書不好的時候，就不要選這本書了。當大家都說某些習題沒有用的時候，就不要去做了。學會選擇，學會甄別，學會找到適合自己的方法，這才是最重要的嗎。
寫一個小程序都要考慮半天可擴展性；起個變數名都要想半天如何才能優雅；沒有設計清楚不敢動手寫；喜歡用各種「新興技術」；滿嘴技術名詞裝作高大上；凡事從輪子造起；鑽研太多的技術細節卻越來越脫離實際……幸好後來我聽我女朋友的按時吃藥，現在終於快要痊癒了。（補：現在是老婆啦）
大忌就是不肯學新東西。時刻記住「選擇最適合任務的語言，而非最熟悉的語言」這句話，往往能事半功倍。
各種大神們說的都不錯了，不才補充幾句，權當來狗尾續貂罷。
走過最大的彎路，是對於「基礎」的看輕，導致我工作三年後仍然在回頭補課。
程序算是我自學的吧。當時自學的時候，把重點放在了「如何實現功能」，而非去摸透更深層的實現機制。那些被計算機系的學生睡過去的課，我沒有意識到重要性。當然，再怎麼不在乎基礎，也還是把數據結構當回事看的，但我也僅僅做了這些而已。
我現在在補什麼呢？
離散數學、編譯原理、JVM、計算機結構……等等很多本該大學本科就該牢記的基礎，現在成為了我自身提高的瓶頸
不要急躁於看到編譯結果，做好基礎知識的吸收和理解，否則，你將為此付出更多的代價去補課。
以為這問題可以跳過，其實你根本跳不過。以為百度很厲害，其實google才最給力。以為英語根本沒用，其實英語才是編程基礎。以為自己很牛屄，其實渣渣都不如。以為編程需要強大的數學能力，其實根本沒那麼邪乎。
編程就像寫作，畫畫，一開始都是閱讀和臨摹。
先設計再實現，有輪子就用，不怕bug，不怕別人的bug。
讀懂別人的代碼比自己會寫要nb。
不用妄自菲薄，越厲害的大牛越找不到對象。
讀書千遍，不如代碼一行，共勉
介紹一些自己在編程學習中一些經驗，希望可以幫助到你。
1. 網上搜 Best Practice- 快速入門：上 Google 搜 xxx best practice。
2. 讀官方文檔
- 盡量讀官方文檔，了解某個庫中可能還不了解的其他功能和函數中參數的真正含義。
- Wikipedia 是一座寶藏。
3. 學會使用調試工具
- gdb/pdb，斷點調試。
- strace，跟蹤系統調用情況。
4. 讀源代碼
- 了解具體的代碼實現。
總而言之，「折騰」。
雖說在這條路上總得折騰幾下，但是上癮了就不好了，就我而言：
1. 折騰編輯器 vim, emacs 之類
2. 折騰各種工具的選擇
3. 折騰 Linux 配置，美化之類
現在覺得把大把的時間花在這些上面真是太愚蠢了。自己和別人一樣都把大把的時間投入進去，但是最終水平卻遠不如人，所以我覺得儘管折騰有積極意義，但是真的不值得去做。
建議：把時間花在有計劃的學習和有針對性的實踐練習上，不要想做什麼就做什麼。
參考這篇文章：The Most Valuable Lesson I Learned from Playing the Violin最大的彎路就是「因為怕走彎路而連試都不試一下」。
對某種技術（語言，平台）懷有宗教般的熱情是有害的。
在學校非開源的東西瞧都不瞧，那時候覺得在 Windows 上用 IDE 學習編程太 LOW 了，非得在 Linux 下用 Vim , Emacs 才能稱得上真正的程序員；Windows 這種操作系統根本就是給小白用戶準備的，怎麼能配得上我們高貴的程序員呢，程序員電腦上都應該跑自己 DIY 的 Linux。
工作一兩年之後為自己當初的狹隘感到羞愧。Windows + IDE 確實有著很高的生產力；語言和平台也沒有我以為的那麼水火不容，掌握 C# 會對掌握Java 有極大幫助，熟練運用 SQL Server 別的 SQL 資料庫也不是難事 ... ...
這段經歷告誡自己做實事，多思考，不要停留在表面。彎路？沒有什麼彎路 最重要的是發現有價值的路！
編程和任何其他事情都一樣， 當你學會了Java/C/C++的順序選擇循環時，會覺得自己已經很牛X了，編程不過如此。後來你發現居然有那麼多種沒聽過的語言，甚至既不是面向過程的，也不是面向對象的，看著各種詭異的語法，感覺自己其實還有些不知道的知識。再後來你發現數據結構和演算法的水很深，各種不同的Map, List之間的差別迥異，不同的排序和搜索演算法詭異漂亮，你覺得還真得好好學學。再後來你發現編程不只是累代碼，還得學IDE的高級功能，寫測試，學版本控制，編譯系統，持續集成，UML， 資料庫，雲平台，Linux，web伺服器等等一套環境，覺得自己以前有點傻X。再後來你發現面向對象編程要有好的設計，要用設計模式，實現可復用，可擴展，低耦合，高內聚的漂亮架構，這已經上升到藝術而不是科學的階段了，這時候你誠惶誠恐，覺得自己過去十幾年的書都白念了，出去都不好意思叫自己程序員。恭喜你，你已經踏入了程序員的門檻，可以稱自己為入門級程序員了。
我承認以上說的其實都是我自己的經歷和體會，但作為IT民工中的普通一員，我相信很多人和我又類似的學習軌跡。知識像個圓圈，圈內是你已經知道的知識，圈外是未知。當你知道的越多，就越會發現自己其實知道的很少。所以作為初學者， 多看看書，拓展一下知識面，把圓圈撐大是很有好處的，起碼你要知道這個圈子裡經常用到的技術有哪些，哪怕不清楚細節，也要知道它大概是做什麼的。之後在工作中需要用到這個技術時，再去仔細鑽研。但預先學習一下基礎的知識，總是有好處的。貴在堅持！
以前遇到問題企圖耍小聰明抄捷徑，殊不知捷徑往往是最遠的彎路。
推薦閱讀：