程序员为什么有点难当

    当我说到这个悲伤而又乐观的话题的时候，多数程序员，甚至投身IT世界的人，可以迸发出两种思维：
    一种是：程序员难当，我的生活很痛苦；另一种是：程序员难当，这个门槛使得优秀程序员偏少，我还是有希望让我领先于50%的程序员的。当然，领先不领先于百分之几十的程序员，这和一个人的电脑让360检测出领先于98%或者2%的电脑不成正比例。
    当大家都认清了《21天学会……》是不太可能的事情的时候，可能时间已经来到21世纪了，写40个网页就能拿到20万元企业网站建设费的时光一去不返。程序员的金字塔已经搭建，每个人都在奋力的向高级攀登，但是不是每个人都会如愿。
    简单的做个比较，当一个人做了文案创意，这种有创新性拓展性的工作，面临的是巨大的脑力挑战，当他做一个复杂而时间紧迫的文案的时候面临的是体力挑战。而当一个人做了程序员，可能他面临的是不仅脑力挑战，还有基础工具匮乏的问题；当目标复杂而时间匮乏的时候，可能不是体力的挑战，而是根本就做不出一个像样东西的结论在等着他。
    当一个程序员学习写程序的时候，可能照着书上敲代码就可以了，幸运的是，这世界上还不是所有书的代码都有不能运行的错误或者完全狗屁不通的逻辑（题目是一码事，程序说的是另外一回事）。他们学习完了一本书之后，面临着复杂的如同建筑师一样的外部环境：很多代码级别的东西都完全和书上讲的不同，或者差距很大。不要把这个比喻同样复制到其它领域，很多工作到最基础的单元工作还是和书上很像的，比如，打字，周围的人基本都使用带有26个字母的键盘打字，至于使用105、104，还是108键，跟品牌或个人习惯相关而已。编程同样是打出字母，就不这么幸运了。

    书上可能是这么写的：打开一个文件，向里面追加一部分字符。而实际工作中遇到的东西可能是这样的：打开一个文件，向文件前端追加一部分字符。解决这类书上遇不到的问题可能受到文档的限制，编程语言本身的限制，等等等等。很可能找了半天，另外一种语言解决这个问题简单得不得了，可是你需要写很长代码来实现。这个很基础的工作，由于API的熟悉程度、在线手册的使用熟练程度，区隔了很多程序员，也有人将这个分类称为码农和非码农的分类。我们可以简单的划出一大堆码农，他们暂时无法在时间紧促的情况下，做这类问题的技术攻关，即使一两天都不行，只好上网找代码，copy paste一下了。更高境界的，可能找到一些库，一些框架，一些开源软件，来完成这件事。但是其代码的隐患可能也就此种下。日后的一天，程序的崩溃就是因为粘贴的这个东西导致的。

    我们总会想起一句在项目管理界的名言：资源总是不够的。意思是让项目经理穷其心智的讨论一件事情如何成行，即使在看起来那么不可能的情况下。中国那么快建了好多座楼就是证据。那么也有一句在软件工程界的名言：没有银弹。意思是让项目经理明白，逼急了，出不来老板要的东西。in SH倒了一座楼就是证据。