“編程是快樂的，一切的最後，殊途同歸，追求的都是心靈的極限。”
就目前來說，絕大多數人對程序員的認識都非常非常的不足。這一點甚至包括很多程序員自己。他們每天消極悲觀，被迫加班，找不到女朋友，工資標準雖然高過平均但是很多情況下依然和工作量 不成比例。他們自稱爲碼農，意思是像農民一樣勤勞，也許是被迫勤勞。在別人眼中，程序員的工作無非就是天天敲一些英文字母， 並且就這點小事還弄得天天都是BUG。
這裏有一個非常大的問題，程序員不是工人，做的也不是重複勞動，所以程序員的工作有很大的不可量化性。對於一個優秀的程序員來說，寫代碼的時間只是工作時間的一部分而已。但是隻有這一部分，甚至是一小部分能夠被人看見，久而久之就成了程序員的標誌。這種誤解越深入，越會干擾程序員的工作，最後降低程序員的生產力，惡化和程序員之間的人際關係。
碼農的特徵
- 喜歡編碼，而且以寫很多代碼爲榮，尤其是當在一個函數裏邊寫的超過100行後，會欣慰的伸個懶腰，喝杯咖啡，得意的周圍轉一轉，然後回來繼續往超過200行寫。
- 滿腦子都是代碼。一般不思考爲什麼編碼，以及如何編碼的更好，喜歡在控制代碼。
程序員特徵
- 越來越多的程序員首先開始關注了，爲什麼要寫代碼，要解決什麼樣的問題，什麼樣的代碼或者語言，或者IDE的開發環境能夠幫助更快速的解決這個問題。
- 以多寫代碼爲恥。代碼只是實現的手段之一，寫的越多，越不好維護，後續越麻煩，還要寫很多註釋文檔。搞清楚需求和目的，儘可能的少些和寫高質量的代碼來實現需求和產品。
程序員的工作應該這樣來描述：將客觀世界的模糊需求轉化爲精確的數學描述。做到這一點，需要進行需求分析， 數學模型設計，驗證，最後纔是編程。當你看到一個程序員在寫代碼的時候，其實他已經進行到了最後一步了。
下面詳細說說
一、需求分析
只有非常少數的程序員可以自由自在的實現自己的想法，絕大多數程序員設計程序的能力都被作爲一種資源使用。這樣就必須將需求描述給程序員。而對於沒有接受過相關邏輯訓練的人，描述需求一般都不可能非常精確。這樣就必須要求程序員充分理解產品相關人員提出的需求，並且給出建議和解釋。但是這一步幾乎就被忽視了， 很多的產品經理都認爲一但我給你了需求你就必須立即開始寫代碼。但是如果沒有對需求的充分理解和認識， 會給後期的工作和配合帶來很多隱患。
比較具體的一個問題是需求本身的重要性以及它對代碼本身的影響和時間成本的影響。《DOOM啓示錄》裏面記載過一個細節。在引擎開發結束，進入遊戲場景設計的環節中，羅梅羅認爲場景中需要一些隱藏屬性，比如牆上的暗門，觸動機關後可以縮回去， 在平時和牆合爲一體看不出來。裏面有可能有隱藏的怪物，或者是特殊武器。喜歡研究遊戲設計的人應該知道這種隱藏屬性 能夠在延長遊戲的生命週期中起到很重要的作用。但是由於當時引擎的設計並不包含這種能力，卡馬克需要對引擎做非常大的 修改才能夠完成這個需求。於是卡馬克以項目進度和代碼複雜度等原因拒絕。羅梅羅覺得這件事很重要，但是怎奈卡馬克大神 那種心意已決的態度，羅梅羅也沒辦法。但是過了很久以後，卡馬克居然把這個功能給做了。原因就是他思考了一段時間以後， 覺得這種功能的重要性已經蓋過了對代碼結構的損傷和時間的付出。這就是一個典型的需求分析過程。並不是說這事兒我 看懂了，聽懂了，就算是需求分析過了。畢竟程序員的時間成本非常高，並且代碼結構修改也會帶來附加的問題，所以程序員需要 深入的理解需求，並且估計出這種需求帶來的時間成本以及可能出現的後續情況，給產品人員提供足量的反饋信息。
二、數學模型設計和驗證
其實程序員並不需要有太高的數學基礎，除非你從事的是和科研領域相關度非常高的項目。絕大多數軟件需求其背後的數學模型 都相當的簡單，遊戲也是如此。但是不管怎樣我們還是需要有一個設計和驗證的過程，然後才能將精力放在具體實現上。
設計環節程序員多多少少的會做一些，雖然很多產品經理還是不知道程序員需要幹這個工作。大多數程序員，會簡單用紙筆 處理一下腦袋裏面雜亂的信息，所以我覺得沒有必要細說這個事兒。
但是驗證環節，很多程序員還是意識不到的。其實我覺得驗證很重要，甚至比需求分析還重要。因爲驗證是一種在投入大量 的時間和精力之前快速的知道一個大致的結果的方法。遊戲領域，應該叫做遊戲原型或者叫Prototype，怎麼叫隨你了。這個過程應該是拿出一大塊時間來做的，用一些簡單的工具和腳本語言，去對一些比較模糊比較有歧義的地方進行一個簡單的 實現，從而在投入大量精力之前儘可能的發現一些可能存在的問題。所以我一直建議程序員學一些簡單可靠的腳本語言， 比如Python。
三、代碼編程
終於到了寫代碼了。寫代碼還用說？當然得說。代碼首先是給人看的，然後纔是給編譯器看的。否則我們這麼多年發展編程語言 幹什麼？作爲軟件公司，代碼是一個公司非常寶貴的財產。爲什麼？代碼能夠運行僅僅是一個方面，更重要的是代碼是一個公司 的智慧的傳承。現在的公司人員流動都非常大，如果公司的主營業務領域有一套非常穩定健壯容易閱讀擴展的代碼，就可以避免 人來人往傷了公司元氣。當然，對於個人來說也是一樣。自己寫的代碼，如果代碼寫得不好，半年以後再看到就想放棄重寫。所以我覺得對於程序員來說，給自己的代碼質量定一個非常高的標準很有必要，這個過程會讓自己逐漸變得更強大，對計算機 程序的理解也會越來越深入。
而在現階段大多數公司的勞動模式下，寫代碼這件事本身受到的重視也不夠。大家都重視工期，成本，程序員加不加班。但是 極少有公司注重員工的代碼質量問題。在我看來，不注重代碼質量反而是一種極大的資源浪費，因爲這樣會花費大量的時間和精力 去處理那些本來不該發生的問題。而對於程序員本身，也由於大家都不注重代碼質量而放棄了對自我的提高，最後自己認爲自己 的工作沒有意義沒有美感完全就是重複勞動。我想這也是碼農這個詞出現的原因。
說到底，你覺得你自己是碼農，那你就是碼農。如果你覺得自己是個真正的程序員，那麼就沒有人能叫你碼農。