前几天晚上吃饭的时候，和部门里一个比较厉害的项目经理聊到“为什么在中国，程序员不能干长久的原因”。他说，在国内，一个高级程序员的上面通常都会有一个不懂程序的领导，即使是一个再有有经验再有能力的人，如果上面有个人瞎指挥，你就不能很好的工作。
想想自己做项目的切身经历，和看到的程序员与领导之间的一些冲突。我觉得他说的很有道理。很多时候，领导一拍脑袋，就要你去实现这个，实现那个，在领导眼里，觉得加一个功能或者变一种方式很简单，很快。的确，我们只要找到那个地方，然后加上几行代码就好了。可是，这几行代码，却破坏了我们原来对这个系统的设计，就因为这样的几行代码，系统的耦合性增加了一倍甚至几倍。当领导拍脑袋形成了一种习惯，这种+1-1的操作就会越来越多，最终导致系统变得越来越难维护，扩展变得越来越难，debug定位难的问题也越来越严重。一旦维护这个系统的人离职，接手的人就会怨声载道，要么无法理解，要么重构，重新设计开发。国内很多项目和软件生命周期也就2-3年，最多也不超过5年，这应该是很大的一个原因吧。（更可气的是，有的领导尽然说出“我们的软件就要能运行2年就够了，2年以后的事不用担心”这样不负责任的话。你们不知道吗，对于程序员来说，每个软件都是自己的孩子啊。每一行代码，都像妈妈的毛衣，一针一线织出来的，自己在程序里面写了那么多的注释就是为了能让后来人能理解我的代码，方便他传承和扩展。如果说妈妈的毛衣里倾注了母爱，那么我们的代码也倾注了我们程序员的爱）。
同样，软件开发业界也有许多倚老卖老的人，他们做了很多年的开发，终于到了领导的位置。也许在猪头领导下面压抑太久了，现在又来虐待下面的程序员 。他们自称架构师，，但是却和他们的职称并不相称。这些冒充架构师的人通常在项目开始时介入，绘制各种各样的图，然后在重要的代码开始之前离开。有太多的这种“PowerPoint架构师”了，由于得不到反馈，他们的架构设计工作也不会有很好的收效。作为设计人员，如果不能理解系统的具体细节，就不可能做出有效的设计。就像在我们工具组，开发的都是一些还没有的东西，他们提出的一个简单的想法，就要我们实现，根本就不考虑在多进程和线程切换肯能会遇到的困难，通常一个任务都要延期才能完成。
有一句言语说：“只有一张蔬菜图无法做出好的咖喱菜”。与之类似，纸上的设计也无法产生优秀的应用。应该根据设计开发出原型，经过测试和验证。实现“可用”的设计，这是设计者或者架构师的责任。
当然，作为一个代码实现的程序员，也不是说，只要按照详细设计说明书写代码就行了，这是典型的“代码民工”行为。应鼓励程序员参与设计。主力程序员应该试着担任架构师的角色，而且可以从事多种不同的角色。他会负责解决设计上的问题，同事也不会放弃编码的工作。程序员在拒绝设计的同时，也就放弃了思考。