写给一位有领导心结的朋友

猎手在群里转贴了这么一篇《写给一位有程序员心结的朋友》。

这位博客园的朋友显然一位身居高位的领导，一个招聘架构师的人，怎么也是CTO一级的人物吧。

不可否认，从他的描述中看来，这位应聘者的确不是一名合适的架构师人选。在我看来，他甚至不是一名合适的一般程序员人选，他的人生错误在于把编程这个爱好变成了一项工作。

但是那位作者朋友的大部分评论我却是不赞同的。

我 不知道是不是所有人当上了领导都会变成这样。虽然他在文章前面一大段里拿出了一大堆的“管理实践手段”来进行所谓的性格测试，但是后面还是不可避免地陷入 到语言和工具的优劣层面——这是初级程序员才会常犯的错误。即使后面他还是堆彻出一堆诸如UML、RUP、框架、建模之类的高深名词（我很欣慰的一点是， 其中没有CMM），但在我看来，不过是些高来高去的扯淡。美国管理学家劳伦斯·彼得指出：当一个人在组织中晋升到一个他不能胜任的位置时，就会出现一些征兆，其中之一便是“使听者莫测高深”的不正常说话习惯。（《彼得原理》第十一章）

那位应聘者的确是被耽误了，但不是被自已耽误，而是中国目前的软件业环境就是这样。这一点我也曾经多次谈到过，国内软件业普遍缺乏一个技术晋升通道，迫使大量并不适合做管理的高级技术人员去做管理，结果就是得到了一批糟糕管理者，同时失去一批优秀的技术人员。

至于工具和语言的问题，虽然是作者的一个低级错误，但我还是要说一下。

作者所谓的“一直认为”恰恰就是他自以为是的偏见。RAD的方便性固然有一定的副作用，但是这并不是不能解决的，比如我曾经尝试过的《在VCL应用中运用MVC模式》。

如 果一个公司或团队因为用RAD而陷入困境，正说明这个公司或团队的架构师在系统规划设计上犯了错误。不是说程序员没问题，而是从责任担当上说，这是设计缺 陷，不应由程序员承担；再则就算团队中个把程序员指出问题也没有足够的权限去改变设计。但无论如何，把责任推给开发工具是一件非常可笑的事情，比这个笑话更加可笑。

如果一个公司或团队能够很好地设计他们的系统，充分利用RAD的优势而同时在设计上避免可能带的混乱，那么用C++ Builder也完全可以写出层次清晰的类和对象——特别是对于那些在前RAD时代成长起来的C++开发人员来说。

当然，一个C++ Builder程序员如果对Delphi一无所知，那的确是一个严重的问题。但这也是人的问题，与C++ Builder有什么关系？难道能够因为一个做底层开发的C程序员完全不懂汇编而批评C吗？

至于：

C++ Builder程序员是一群在编程技术方面没有前途的程序员。他们的前途应该是应用系统的需求分析能力。

就更加是无稽之谈了。

我 相信这不是所有.net程序员的通病，但我必须说，类似的观点在.net程序员中最常见。难道.net程序员就在编程技术方面一定有前途吗？把自己的前途 寄托在工具上的人能有什么前途呢？工具只是工具，至于系统的需求分析能力就更加与工具无关了，就算是一个只用Rose生成代码的程序员，也未必就一定具有 良好的系统需求分析能力。而作为一名架构师，至少要对自己所负责的项目所用的开发工具和语言有相当深入的了解，并且能追踪其相关领域的最新动向。反而是 UML、RUP、框架、建模之类的高来高去的扯淡应该少一点，因为很多项目并不需要用到这些。当然像模式、重构、单元测试等，这些还是要知道的——即使是作为程序员。

如果他选择另外一种编程语言，在某应用领域（而不是信息化系统领域，在这个领域，重点不是编程技术而是设计技术）能流畅地使用该编程语言，我会很高兴。

事实上我认为，作为一名程序员，囿于一种开发语言或工具是完全不行的，即使是在非信息化系统领域。至于在信息化领域，设计技术也不是最重要的，重要是需求的获取以及对其进行正确的理解。

或者，他告诉我：编程语言只是一门工具，我追求的是如何高效地快速地开发系统，我知道如何合理地设计系统，如何对进度进行控制，如何进行开发质量的控制，我也会很高兴。
再或者，他告诉我：编程算什么呀，那只是我曾经在某个阶段的工作，我现在已经完全不编程了，我开始转型为产品经理、销售经理等等，我会非常地高兴，因为，我相信，那些工作可能更适合他。

这两种说法固然不错，但是并不是人人都适合。但这又是中国软件业的现状，一个程序员，想要升职加薪，大概就只有这两条路可以走了，最后不过是使组织达到彼得极限——所有人都晋升到了一个他们力所不能及的职位上。

当作者以一种施舍的态度表示他将招聘那个人为一般程序员或一般销售人员时，带着一种作为领导的居高临下和得意洋洋。文章的言语中还对那个应聘者的年龄和老化的知识结构加以嘲弄。

这种领导心结其实比程序员心结更加危险。