本节书摘来自异步社区出版社《告别失控：软件开发团队管理必读》一书中的第1章，第1.1节，作者： 【美】Mickey W. Mantle（米奇 W.蒙托） , Ron Lichty（罗恩•利克蒂），更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.1 程序员都做什么
首先，程序员的工作很有趣！Fred Brooks在软件工程的经典名著之一《人月神话》[6]中很好地总结了程序设计充满乐趣的原因。
“第一，是纯粹的创造的愉悦……”
“第二，是做出对其他人有用的东西而带来的快乐……”
“第三，是设计组装谜题一样环环相扣的复杂部件，并观看着它们巧妙地运转而产生的吸引力……”
“第四，是持续学习的乐趣，这来源于任务的无重复特性……”
“第五，工作的对象是可以自由驾驭的代码，令人开心。程序员，像诗人一样，操作的是与纯粹思维事物只差一点点的代码”。
既然多数程序员都很享受工作，你就可以理解为什么难以管理他们了。如果有人付钱让你开心地玩，你还会愿意受制于人吗？受人管制就会减少工作中的乐趣！
这也能解释为什么程序员常常难以共事。在计算机出现之前，许多程序员可能会成为工程师、会计师或者教育工作者。我们这么多年来招聘的程序员中约有50%属于这种情况，另外的50%则比较难以归类，许多可能会成为艺术家、音乐家、作家等“右脑型”人才，他们本质上更加自由奔放。更令人惊讶的是，这类“右脑型”人群中产生的天才程序员更多[7]。
此外，程序员的工作“与纯脑力劳动只有细微差别”的特点助长了自由散漫的工作作风，使得程序员几乎无法管理。设计与实现程序时，没有广泛使用严格、规范、全面的工具。往往程序员可以从一张白纸开始设计编写程序。
把这两类不同的程序员混合成一个团结、高效的软件开发团队，给管理工作带来了极大的挑战。管理工程师相对来说比管理艺术家、音乐家和作家要容易一些。如果没有外界的干扰，许多程序员在独自面对自己的设备时通常都会很投入地写代码，一边写一边设计。程序设计经理必须培养建立在可靠的开发实践基础上的软件开发文化，否则程序设计项目就可能失败。
尽管可以对程序员进行分类，但成功管理他们的关键却是要认识到他们是独立的个体。程序员之间的差异很大，你必须努力地让每个人的长处都得到发挥，同时尽力提高或者至少抵消每个人的短板。这条原则适用于任何领域的管理，不过在管理程序员时尤为重要。
即便有着良好的软件实践和开发过程，当项目产品本身难以捉摸的时候，你如何能够知道项目的进度？几乎在所有的软件中，程序的实际有形结果（即打印的报告、输出的数据甚或用户界面）与实际程序的完成状态都是不成正比的。Mickey在Evans & Sutherland公司工作期间，曾与一名杰出的系统程序员共事，这名程序员为一个非常复杂的设备驱动程序设计和编写所有的代码，但在几个月的开发期中，甚至都没有进行过一次完整的编译。再来看另一种极端情况：Ron到富士通公司之前的那3个月时间里，富士通公司的程序设计团队每周都会告诉领导，再等一周产品的功能就能完全实现。对于这两种情形，我们无法通过进度估计来预测项目成功完成的时间。如果程序能够给出我们想要的结果，但设计和/或实现都很糟糕，以致改进或维护完全不现实，那就更麻烦了。即便是资深的程序员也难以注意到程序中这些隐藏的或者无法预见的方面。
坦率地讲，许多（也许是大多数）程序员的工作是对已有的程序进行修改，而且这些程序多半是别人写的。即便程序是他们自己写的，恐怕也是半年之前的事情了，根据伊格尔森定律（Eagleson’s Law）：“自己写的代码如果有半年时间没有看过，就跟别人写的代码没啥区别了。”这句话的意思是，代码看起来会很混乱，难以理解，并且同样无法通过进度估计来预测项目成功完成的时间。
类似地，对许多管理者（尤其是CEO或CFO等技术性不那么强的管理者）来说，原型似乎已经是比较“完善的”产品了。软件难以捉摸的特性使得在企业内部判断其完成状态的难度更大，这与程序产生的结果是好是坏无关。程序设计经理必须能够借助于经验、工具以及深入的观察来把握程序的进度。
避免这些问题的最好办法是招聘杰出的程序员——那些能为计算机程序设计艺术带来纪律和方法的特殊程序员。这些杰出的程序员到底是艺术家、工程师还是匠师呢？
尽管现在对计算机程序设计艺术的讨论很多，但纯粹从字面上理解的话，很少有程序员认为自己是艺术家。
类似地，尽管软件工程是我们的目标，但从字面上讲，如今很少有程序员能称得上是软件工程师。尽管IEEE [8]提供了软件工程方面的规范认证项目，但根据我们的经验，这些认证程序不仅得不到大多数专业程序员的重视，而且知名度在学术圈和极少数公司之外也并不高。普通程序员在软件工程培训方面不会花费很多精力，甚至可以说没有这样的需求。[9]
那么“匠师”这个说法怎么样呢？很多核心程序员认为，把程序员比喻为匠师更合适。[10]匠师不是与生俱来的顶尖高手，他们需要当多年的学徒、多年的熟练工作，在证明自己的技能并获得业绩之后才能赢得顶尖高手的称号。用知识、经验和成功的过往业绩来认证程序员比较切合实际，而正规的认证程序则难以给出这样的认证。我们认为“匠师”这个比喻比其他称谓更适合我们所说的那种“杰出的程序员”。
杰出的程序员是如何产生的呢？仅仅具备程序设计方面的天赋是远远不够的。事实上，程序设计方面的天赋对杰出程序员的技能反而有副作用。杰出的程序员是大师级的人物，做事有条不紊、遵守纪律。他们能够凭直觉把代码和程序组织好，能够约束自己总是在编写代码之前进行设计，能够在最少的时间内编写出清晰、简洁、实用、高质量的代码并获得预期的结果。换言之，杰出的程序员是大师级的匠师。
如果程序员的动力主要来源于时间计划表、管理层压力或金钱，那他通常不会是一名杰出的程序员。对大多数杰出的程序员来说，动力事实上来源于更高的要求：在世界上产生影响，并且做出人们实际使用的程序或产品。杰出的程序员希望并且需要为具有世界影响的项目工作，他们希望能够感受到自己的工作是有意义的，哪怕只在某个很小的方面有意义。杰出的程序员偏爱能够满足他们更高要求的公司和项目，他们非常在意自己所做的事情，常常为了想要的结果而超限度地工作。
杰出程序员的工作效率往往比称职的普通程序员高一个数量级（即10倍以上）。
然而世上的杰出程序员实在太少了，不可能让每个项目团队都拥有杰出的程序员。而且多数团队也只能容忍队伍中有一两名杰出的程序员。我们发现大多数的程序或项目主要依靠的是普通程序员，而不是杰出程序员。普通程序员通常是称职的、专业的、能干的，但他们可能会把程序设计视为一种工作。
现在我们面临的挑战是：如何找到并雇用一个能干的程序员团队，如何激励并训练其中一部分人成为杰出的程序员，如何管理剩下的人使他们获得成功的结果，以及如何保证整个团队的持续进步，即使其中大部分或者所有的人都仅能算是称职的程序员。
