要知道程式設計大多時候就是在創造，當你有最終目標感時道路會更加的清晰。如果你的目標是「學習程式設計」而不是更具體的學習哪種程式及如何讓你的生活更好，那麼你可能會發現這不過是一次令人沮喪的實踐。
那麼，你想要寫什麼？**？遊戲？iphone應用？致富的商業軟體？互動藝術？你是想讓老闆印象深刻？或你是想自動執行一些乏味的任務以讓你有更多的時間看水獺**嗎（譯者注：這裡應該指有更多的時間看外面的風景）？也許你只是想更具有就業競爭力，因為可以將技術流行詞新增到簡歷，或者只為了實現你的教育需求。所有的這些都是有價值的目標，你得確定知道哪個才是你想要的目標然後相應的去學習吧。
程式設計跟其他東西一樣，是一門技術。跟語言學習一樣，有需要掌握的語法和詞彙；跟數學一樣，有解決特定型別問題的流程方法；像各種工藝和藝術創作一樣，有技術、工具以及人們經年累月發展起來的最佳實踐方案，專門解決各種不同型別的任務，你可以自由的使用、修改或棄之不用。
joel spolsky（乙個非常聰明的傢伙，他的一些其他的觀點我也很喜歡且頻繁認同）曾論斷：在有著「程式設計師真正思想」的人和缺乏該領域成功所必備的知識能力的任何人之間有一條很清晰的界限。據他所言，這條界限包括指標和遞迴（這裡和這裡有為感興趣的人提供的入門資料）。
我在學校學習過指標和遞迴，當我掌握了過後，大腦發生了一次愉悅的波動—這種智力快感使我想要將學習電腦科學排在第一位。但是，除了課堂練習外，其他時候用指標和遞迴來完成任務的次數就相對較少了。後來在一次次的幫助他人學習時，我發現大家根本不用掌握這兩項技術中的任何一項就可以完成一些非常有趣有益的專案。
想知道或怕知道自己是否「足夠聰明」其實沒什麼意義。當然，你的任務越複雜越深奧，你需要掌握的知識水平就越高。不過這也同樣適用於其它的任何領域。除非你計畫完全靠程式設計生活，否則你可能並不需要成為乙個掌握遞迴的天才來完成你的任務。
當你第一次學習程式設計時，你會很快遇到這樣的特殊經歷：你認為已經按照所想的完成了每一件事，檢查了一遍又一遍，卻發現仍然執行不了（出現bug了）。你完全不知道該從哪開始修復它，錯誤資訊（如果你夠幸運只有乙個的話）好像在說「**** you」。你可能就此放棄，心裡想著自己恐怕永遠也解決不了了，那麼你就不適合幹程式設計這行。我一開始就有這種感覺，嘗試著用c++寫乙個程式然後執行它，卻只得到「segmentation fault」這個麻煩。
但是這種經歷對所有不同技術水平的程式設計師來說都太普遍了，這絕對與你的智商、技術悟性或者是否適合幹程式設計這行沒有任何關係。初學者會碰到這樣的情況，經驗豐富的程式設計師也會碰到這種事情。主要的區別就在於你如何應對這種情況。
我發現新手程式設計師和有經驗的程式設計師之間乙個很大的不同點，就在於一種信念（指有經驗的程式設計師所具有的信念）：相信事情出錯是因為邏輯原因並且一定能找出來；相信bug可以修復；相信有辦法實現目標。從「執行錯誤」到「執行正確」的過程可能不是很明顯，但是有耐心你通常都可以找出問題。
括號應該另起一行；括號應該放在同一行；用tab鍵來縮排，但是tab很**喲；你應該使用儲存過程，但實際上你又不應該用它們；你應該總是對**進行注釋，但是好**不需要注釋。
基本上對於乙個特定的問題總是有許多不同的方法，沒有所謂單一的「正確方法」。許多程式設計師都非常擅長倡導他們首選或偏愛的方法，但是那並不意味著這是「唯一正確的方法」。如果與人們面對面爭論後告訴我：我是錯的，那麼我也會盡力搞明白是否他們就一定是正確的，這是我早期職業生涯比較重要的乙個方面。
如果你在乙個小組裡與其他人一起程式設計的時候，肯定會有人總是對你做的東西指指點點，有時候他們說的的確是正確的，但是總是值得去**下看你是否真的「做錯了」。但有時候他們完全就是胡扯或只是再次引起了一場古老而沒有意義的爭論，那麼你最好適應這樣的情況然後忘掉它吧。另一方面，如果你個人喜歡這種古老且沒有意義的爭論的話（比如語法狂，一直看著大家），那麼不用多說，你來對了地方。
html不屬於真正的程式設計；如果不用vi的話，你就不夠嚴肅認真；真正的程式設計師要懂c；真正的程式設計師不用windows；有些人從來都學不會；你不應該學習程式設計； 你不是乙個計算機程式設計師（但是我是）。
「程式設計」對不同的人有著非常不同的含義，而且現在看起來與過去也不太一樣。有趣的是，大家都知道，工具、包和框架能夠讓初學者甚至受過訓練的開發者更快更容易的做開發，但正因如此這些東西往往被貼上「不是真正的程式設計師」的標籤。（看：「return of the real programmer」）
其實這背後隱藏的是一種害怕心理：「如果「任何人」敢自稱他們自己是乙個真正的程式設計師，那麼這篇文章的題目就沒有意義了
（譯者注：也就是都不敢自稱自己是真正的程式設計師）。但是我認為這種保守行為是非常具有破壞性的。
使用那些讓你最容易開發的工具吧。如果這意味著你的遊戲是用stencyl 或者gamemaker做的，而不是自己從頭開始寫的，沒關係啊。如果你首次程式設計用的是html或者excel巨集，也ok啊。只要你能堅持下去就行。
當你越來越舒服的時候（沒任何挑戰力），你會自然的開始找出那些工具受限的不足的（而不是有幫助的）地方接而尋找功能更加強大的工具，但是大部分情況，很少有人會去看你的**或問你用什麼工具—你用這些工具實現了什麼功能才是關鍵。
如前所述，我過去（尤其在學校）一度非常擔心從我的穿著，我的講話，我選擇的閱讀資料，甚至我的軟體定製選項是不是證明了自己「不是乙個真正的極客」（不是真正的極客貌似就沒啥資格進入技術社群），這嚴重消耗了我的精力，後來我決定完全不考慮這些東西後我的技術更強了（譯者注：與其花時間搞那些沒意義的東西不如多學點技術，這樣你的技術就會越來越強）。
你需要謹記一點：你擅長程式設計的能力與你到底有多適應各種極客亞文化沒有一丁點關係。如果你內心深處知道自己永遠都不會適應這些亞文化（而因此焦慮的話），那就需要加倍的記住了。你為了證明自己所浪費的精力應該用來做真正有有意義的事情，並且就算你是一名無可爭辯的極客，眼窩中流露中可信賴的光芒，那麼也請記住：當你評價其他人的信譽水平時，也並不意味著你認為的就一定對，一定是事實。
我們永遠不缺像學習程式設計的「正確」或「最佳」方法這樣的文章，其實還有很多潛在的方法。你可以從一本書或通過完成互動練習或通過除錯其他人所寫的東西來學習概念。當然，在你第一次學習的時候有許多的語言供你選擇，每種語言都有相應的宣傳和倡導。
關於「自學程式設計」流程和講習班的乙個常見的抱怨就是：一開始你會很愉快的輕鬆度過初級材料的學習，然後會越來越困難，這時你就會很快走上陡峭的學習曲線。你知道如何在頁面上列印輸出一些文字行，但是你不知道從哪開始進行乙個「真正的」有用的專案。你可能感覺你只不過遵循了一些指南而沒有真正的掌握，然後你可能就會指責學習資料。
不管你遵循的是什麼「程式設計」方案，衝破這堵牆的唯一方法就是持之以恆。這意味著你要持續的嘗試新東西，學習更多的知識，並且一步步的搞明白怎麼去開發你的專案。如果你非常清楚自己為什麼要將程式設計放在首位的話，最後你也非常有可能成功。
如果你堅持一點一點的鋪磚，可能會花費很長時間才能得到一道牆，但是最終你還是會得到。這時候我先前提到的信念就派上用場了。如果你相信隨著時間和耐心，你可以完成整個程式設計任務，那麼到時候你肯定會達成所願的。
如果當初學習程式設計時能有人給我這些忠告該多好
要知道程式設計大多時候就是在創造，當你有最終目標感時道路會更加的清晰。如果你的目標是 學習程式設計 而不是更具體的學習哪種程式及如何讓你的生活更好，那麼你可能會發現這不過是一次令人沮喪的實踐。那麼，你想要寫什麼？遊戲？iphone應用？致富的商業軟體？互動藝術？你是想讓老闆印象深刻？或你是想自動執行...
初學者怎樣學習程式設計
培訓是坑，請勿進入 學習程式設計的心態 自信入門，苦學成精。學習程式設計的思路 按部就班，精益求精，思考周全 解釋 自信入門 很多人都認為程式設計很難。程式設計跟英語一樣，都是有語法和教程。對於語法的學習，最有效的途徑就是學官網以及官網的例子。遇到外國的 可以使用翻譯工具。多敲敲 多觀察 的作用，就...
如果你是班傑明 富蘭克林，會怎樣學習程式設計？
優秀的程式設計方法是極難教的。程式設計書籍大抵都是這樣開頭的 這是x方法的例子，還有下面這個例子 教教基礎是容易的，因為基礎知識也就那麼多。難就難在，要教明白每種選擇帶來的結果。一般我們會建議多寫 慢慢提高水平。這是必要但非充分條件。要想學的更好，我們還要判斷應該寫哪些 以及如何改善這些 我們接下來...