程序员是劳动密集型工种

技术很重要，但在实际工作中，可能劳动强度更重要。

我分析我一天的工作内容，可以发现。其实80%的工作内容都是日常的开发或者修改bug。只有20%或更少的时候是有创造性的工作。

为什么会这样?因为一个软件组成的代码太多了，而一个符号用错或者少用一个判断都将带来bug。一是开发逻辑本就需要很多的代码，二是代码一多出bug的机会就多。这许多的问题(逻辑或bug)，就会产生大量的工作。时间再多也不够用。所以说是劳动密集型。

另外，一个常用的词语"工匠精神",乔帮主的极简主义、执着、严谨之类的特点，被用以判断一个程序员的优劣。这些精神对细节的要求极高，如果我们推崇它，那么就会极大增加脑力与体力的工作量。而如果不推崇，我们的软件产品质量就会下降。被客户抱怨，这点用得不爽，那点用得不好。所以，我们需要一个平衡。

往往程序员并不能独立处理好这个平衡，因为产品经理或客户对软件的要求是要尽善尽美，但他们不会关心内部细节。好比他们需要的是一位美女，但他们不管化妆，营养，精神状态。而程序员做到这些就需要大量时间，不光把自己搞得很累，还会影响到老板的工期预算。所以最后形成一个共识，优秀的软件是优秀的程序员做出来的，优秀的程序员是短时间内能做出逻辑完善，外观优美，交互流畅的软件的人。换句话说就是多快好省。这里有创造性么？没有。

但有的需求就是要难度较大的技术才能完成，这些是不是有创造性呢？是，也不是。首先，“难“是共认的。大小公司都知道的，有一些大企业有富余程序员、极客程序员，一般都是他们先搞定了这些“难“的技术。程序员都知道BAT公布的开源框架、SAAS服务有多厉害，一般小公司搞不了。

既然是这么累，那是不是干的再多也只是量上的增加，没有质的变化呢？其实并不是，关键在于是否有客观的分析总结。

今天可能我们用的是jsp,明天用struts,后天用的spring mvc。但对于项目来讲解决的问题都是一样的，就是前端与后端的数据交互问题。那么为什么要换工具，除了单位要求的，还有没有客观带来的好处。当然有。新框架配置更少，api更简单，源码也更清晰。如果只从工具使用的角度，那么3年工作经验与10年工作经验差不多。因为工具常用功能就那么多，熟悉程度上差不多。

上面谈了这么多技术问题，再谈谈项目问题，项目的盈利能力。这个问题比技术问题更复杂，一般的技术问题都可通过大量的时间和人来解决。项目的成功却不行。但项目的成功也有一个特点，经过大量的试错才会成功。老板不是傻子，他们希望自己投资的每个项目都能快速成功。但事实是很困难，从技术细节来看，本文开始就说了。另外还有非技术的问题，用户的习惯、心理，国家政策的影响等等。这个话题就聊不完了。所以我们把话题收缩到怎么一个需求基本固定的项目快速完成。

首先是人员的配合，项目经理的跟进协调。其实这里的协调工作是非常多的，基本套路固定后，协调的细节相当的多。协调也与具体的人有关系，经验丰富的对套路规律熟悉，需协调的少点。经验不足的就需技术指导，项目接口的协商。所以对于我们程序员个人来讲，快速完美解决自己的问题，就能把自己的这块东西搞定。光这就够一个人忙活很多天的了。比如，如何快速做好本需求的增删改查。

增加，不是简单的一个添加页面哦，首先怎么到这个增加页面的，一定是与现有数据有关系的。怎么关联，一般是查询现有数据，现有数据是个什么结构？单表，树，网？总能找到一个路径吧，那就来个导航吧。增加的方式也不是一个增加页面，用户更习惯用excel上传。那么excel的模板是怎样？excel对应的数据库的表又是怎样。如果一个excel里有树状结构，怎么验证父结构的那些重复的字段。字段之间有没有约束关系？字段有没有字典范围？null的情况也有多种，没有Cell的，cell里为空的，java里String.valueOf(null)就成了"null"字符串的。

删除，也是有很多的“坑”，逻辑删除字段如何设计，是否要逻辑删？删除后相关联的表的数据是更新还是删除。关联的表咱就只考虑直接关联的吧，间接关联的就太多了。一个表的N个字段，都考虑一遍工作量也不小了。

更新，比删除考虑的更多了。一个商品把图变了，是不是就不是原来的商品了，那原来商品上的规则怎么办？一个题的序号能不能改？

查询，用户/产品说我要的就是这个，怎么来的我不知道。知道它有多麻烦了吧。