程序员如何看待码农这个称谓？

“编程是快乐的，一切的最后，殊途同归，追求的都是心灵的极限。”

就目前来说，绝大多数人对程序员的认识都非常非常的不足。这一点甚至包括很多程序员自己。他们每天消极悲观，被迫加班，找不到女朋友，工资标准虽然高过平均但是很多情况下依然和工作量不成比例。他们自称为码农，意思是像农民一样勤劳，也许是被迫勤劳。在别人眼中，程序员的工作无非就是天天敲一些英文字母，并且就这点小事还弄得天天都是BUG。

这里有一个非常大的问题，程序员不是工人，做的也不是重复劳动，所以程序员的工作有很大的不可量化性。对于一个优秀的程序员来说，写代码的时间只是工作时间的一部分而已。但是只有这一部分，甚至是一小部分能够被人看见，久而久之就成了程序员的标志。这种误解越深入，越会干扰程序员的工作，最后降低程序员的生产力，恶化和程序员之间的人际关系。

码农的特征

喜欢编码，而且以写很多代码为荣，尤其是当在一个函数里边写的超过100行后，会欣慰的伸个懒腰，喝杯咖啡，得意的周围转一转，然后回来继续往超过200行写。
满脑子都是代码。一般不思考为什么编码，以及如何编码的更好，喜欢在控制代码。

程序员特征

越来越多的程序员首先开始关注了，为什么要写代码，要解决什么样的问题，什么样的代码或者语言，或者IDE的开发环境能够帮助更快速的解决这个问题。
以多写代码为耻。代码只是实现的手段之一，写的越多，越不好维护，后续越麻烦，还要写很多注释文档。搞清楚需求和目的，尽可能的少些和写高质量的代码来实现需求和产品。

程序员的工作应该这样来描述：将客观世界的模糊需求转化为精确的数学描述。做到这一点，需要进行需求分析，数学模型设计，验证，最后才是编程。当你看到一个程序员在写代码的时候，其实他已经进行到了最后一步了。

下面详细说说

一、需求分析

只有非常少数的程序员可以自由自在的实现自己的想法，绝大多数程序员设计程序的能力都被作为一种资源使用。这样就必须将需求描述给程序员。而对于没有接受过相关逻辑训练的人，描述需求一般都不可能非常精确。这样就必须要求程序员充分理解产品相关人员提出的需求，并且给出建议和解释。但是这一步几乎就被忽视了，很多的产品经理都认为一但我给你了需求你就必须立即开始写代码。但是如果没有对需求的充分理解和认识，会给后期的工作和配合带来很多隐患。

比较具体的一个问题是需求本身的重要性以及它对代码本身的影响和时间成本的影响。《DOOM启示录》里面记载过一个细节。在引擎开发结束，进入游戏场景设计的环节中，罗梅罗认为场景中需要一些隐藏属性，比如墙上的暗门，触动机关后可以缩回去，在平时和墙合为一体看不出来。里面有可能有隐藏的怪物，或者是特殊武器。喜欢研究游戏设计的人应该知道这种隐藏属性能够在延长游戏的生命周期中起到很重要的作用。但是由于当时引擎的设计并不包含这种能力，卡马克需要对引擎做非常大的修改才能够完成这个需求。于是卡马克以项目进度和代码复杂度等原因拒绝。罗梅罗觉得这件事很重要，但是怎奈卡马克大神那种心意已决的态度，罗梅罗也没办法。但是过了很久以后，卡马克居然把这个功能给做了。原因就是他思考了一段时间以后，觉得这种功能的重要性已经盖过了对代码结构的损伤和时间的付出。这就是一个典型的需求分析过程。并不是说这事儿我看懂了，听懂了，就算是需求分析过了。毕竟程序员的时间成本非常高，并且代码结构修改也会带来附加的问题，所以程序员需要深入的理解需求，并且估计出这种需求带来的时间成本以及可能出现的后续情况，给产品人员提供足量的反馈信息。

二、数学模型设计和验证

其实程序员并不需要有太高的数学基础，除非你从事的是和科研领域相关度非常高的项目。绝大多数软件需求其背后的数学模型都相当的简单，游戏也是如此。但是不管怎样我们还是需要有一个设计和验证的过程，然后才能将精力放在具体实现上。

设计环节程序员多多少少的会做一些，虽然很多产品经理还是不知道程序员需要干这个工作。大多数程序员，会简单用纸笔处理一下脑袋里面杂乱的信息，所以我觉得没有必要细说这个事儿。

但是验证环节，很多程序员还是意识不到的。其实我觉得验证很重要，甚至比需求分析还重要。因为验证是一种在投入大量的时间和精力之前快速的知道一个大致的结果的方法。游戏领域，应该叫做游戏原型或者叫Prototype，怎么叫随你了。这个过程应该是拿出一大块时间来做的，用一些简单的工具和脚本语言，去对一些比较模糊比较有歧义的地方进行一个简单的实现，从而在投入大量精力之前尽可能的发现一些可能存在的问题。所以我一直建议程序员学一些简单可靠的脚本语言，比如Python。

三、代码编程

终于到了写代码了。写代码还用说？当然得说。代码首先是给人看的，然后才是给编译器看的。否则我们这么多年发展编程语言干什么？作为软件公司，代码是一个公司非常宝贵的财产。为什么？代码能够运行仅仅是一个方面，更重要的是代码是一个公司的智慧的传承。现在的公司人员流动都非常大，如果公司的主营业务领域有一套非常稳定健壮容易阅读扩展的代码，就可以避免人来人往伤了公司元气。当然，对于个人来说也是一样。自己写的代码，如果代码写得不好，半年以后再看到就想放弃重写。所以我觉得对于程序员来说，给自己的代码质量定一个非常高的标准很有必要，这个过程会让自己逐渐变得更强大，对计算机程序的理解也会越来越深入。

而在现阶段大多数公司的劳动模式下，写代码这件事本身受到的重视也不够。大家都重视工期，成本，程序员加不加班。但是极少有公司注重员工的代码质量问题。在我看来，不注重代码质量反而是一种极大的资源浪费，因为这样会花费大量的时间和精力去处理那些本来不该发生的问题。而对于程序员本身，也由于大家都不注重代码质量而放弃了对自我的提高，最后自己认为自己的工作没有意义没有美感完全就是重复劳动。我想这也是码农这个词出现的原因。

说到底，你觉得你自己是码农，那你就是码农。如果你觉得自己是个真正的程序员，那么就没有人能叫你码农。