计算机编程中极少人是真正的艺术家，大多数人充其量不过是房屋粉刷匠而已。Tim Bryce
管理顾问 Tim Bryce 不喜欢程序员，而许多程序员也不喜欢他。（注：Tim Bryce 发布过一篇名为《P理论：管理程序员的哲学》的文章。）
Bryce对程序员的看法：
- 程序员都是故弄玄虚，妄自尊大的家伙。
- 与其它大学程度的工作者相比，普通程序员的智商要低。
- 程序员总显得邋里邋遢，精神涣散。
- 程序员做事杂乱无章，因此很难评估他们工作的进度，其技术也尽显不足之处。
- 程序员的典型表现是常常埋怨自己工作过量，薪酬过低，所受的重视过少。
- 程序员自诩对科技发展怀有无比的好奇心。 然而，好奇心是需要通过管理慎重培养的，因为信息过多很可能会导致程序员在工作时分心。
在对Bryce先生文章（如上）的回复中，有很多优秀观点，指出了他看法有失偏颇的原因。但是我想谈谈他兴许正确的几点看法。 我还想去了解为什么一些入行30多年的管理顾问会持有这样的看法？当然， 我否认费络伊德观点论所说的 Bryce先生在童年时被某个无名的程序员伤害过。（主要的原因是当时世上只有为数不多的程序员，并且全都极负盛名。）
Bryce先生的目标听众不是程序员，而是 IT管理者和企业决策者（不管怎么说，程序员的低智商很可能会妨碍他们理解P理论）。 P理论的根本前提是：对程序员的管理越有效，我们就越能充分利用系统来支持企业的信息需要。这一理论并不是针对活生生的人， 而是针对讲究实效的企业。人们应当从企业的角度来看待这一理论。因此，Bryce先生的以下三点看法看来并非全错。
1. 程序员不是软件工程师，而是翻译。
（关于这点，请参见作者 Andriy Solovey 的另一篇文章：《程序员的本质》。）
我同意这种说法。程序员确确实实是翻译。不过我并不认可他们翻译的内容。 Bryce先生写道说：程序员将人类可理解的指令翻译成计算机指令。 实际上，程序员翻译的是人类模糊隐晦的需求和想法，而不仅仅是不清不楚的指令。 有时候这两者间的差别与毕加索化人类情感为艺术和房屋粉刷匠化顾客需求为斑斓墙面的差别无异。
如果客户和程序员间的思想交流不足，蹩脚的翻译及低劣的软件将随之产生， 而程序员本身也会看起来很糟糕。那么，Bryce先生的看法就言之有理了。 （系统思维 除外）
2. 许多程序员并非系统分析师。
不幸的是，在许多情况下确实如此。 Bryce先生写道：真正的系统工程师或系统分析师会去了解业务需求，确定和开展能够满足这一需求的业务流程，并明确需要程序员实现的软件要求。遗憾的是，担当这一重任的人极少。因此，这样的重任只能托付于那些不能胜任这项任务的程序员。
我确实认识很多不擅长去了解业务需求的程序员，或者说他们压根儿就不愿意去了解。然而，与Bryce先生不同， 我认为程序员必须学会使用商业语言，学会与客户进行直接交流并了解他们的需要。 程序员真正的工作不仅仅是编写计算机程序，专业的程序员还应当熟练地将复杂的精神理念翻译成软件。
如若不然，业务理念的错翻将会导致软件低劣，也会因此抹黑程序员。 而Bryce先生的看法又将成为事实。
3. 程序员追求新兴技术方案，而不是实用的解决方案
Bryce 先生写道：要解决错误问题，简单的方案是没用的。 学会从业务的角度去验证程序员自己的技术推荐十分重要。
的确，许多程序员对脱离业务理念的技术方案，甚至是新兴的技术方案更感兴趣。究其原因，是因为技术通常是程序员可以发挥才智与创造的唯一领域？还是因为程序员没能参与企业决策并了解客户需求？亦或是因为程序员素来脱离企业真正的需求和项目目标？
过度设计的解决方案是很糟糕的，它打着新兴技术的幌子却没有实际的需要。 但是，如果能够实现前面的两点，即：1、程序员直接和客户一同工作。2、程序员了解客户需要并将其需求转换为软件，那么程序员就不会有时间和心思去理会天马行空的技术解决方案了， 而是会努力寻求实用的方案，倾向并关注于那些重视客户价值的解决方案。
P理论
Bryce 先生认为程序员是一群我行我素的极客，他们需要强而有力的监督管理。管理员应当想方设法控制程序员怠惰无常，伪知识的天性。 同时，软件项目需要大批可以缜密分析业务需求的分析人员（低智商显然不利于程序员直接获取这一需要）， 当然，也迫切需要像Bryce先生这样的管理顾问，他可以告诉你如何正确看待程序员及他们行为。
另一种方法，就是相信程序员是负责任的群体，允许他们直接与客户一同工作并参与大部分的项目决策。 由于管理者和程序员现有的思维定式，要转换观念并非易事。但对完美软件公司而言，一切皆有可能。
英文链接：Andriy Solovey转自：
http://kb.cnblogs.com/page/115684/