开发团队需要遵守纪律才能从现代软件工程规范中获益。如果你的团队没有正确的工程纪律，那么你们所使用的工具和流程几乎都起不到什么作用。这一点，我已经在“Discipline Makes Strong Developers”（纪律造就强大的开发者）一文中着重论述过了。
有人提议，应该在团队里配备一位像枪炮士官哈特曼那样的资深训导员，以强化工程纪律。一些评论者对此表示了担忧。这也在情理之中。
译者注：哈特曼（Hartman）是电影《全金属外壳》（《Full Metal Jacket》）中的一个角色。这是一部描述美国海军陆战队与越南战争的影片，被认为是电影史上最出色的战争电影之一。在影片中，哈特曼粗鲁的语言、刻薄的训练方式，夸张但也真实地刻画了海军陆战队新兵教官的形象。
你这个臭小子！我知道你的名字了！看我怎么收拾你！我看你还笑得出来吗？你会想哭都哭不出来的。你必须一条一条学下去。我会教你的。
对于软件开发者来说，以哄骗或痛斥的方式让他们服从不是一个有效的激励方法。至少在我的经验里，那行不通。如果你想提高团队的工程水平，你需要一个领导，而不是靠一个训导员去强制执行。其目标并不是给所有的同事洗脑，而是要和他们一起协商出大家都能接受的标准。
Dennis Forbes曾经发表过一篇文章，题目为“Effectively Integrating into Software Development Teams”（有效地融入软件开发团队）。我觉得他很出色地概括了关于有效领导方面的策略。他用一封假想的电子邮件开头（根据我对Dennis的了解，这也可能是他的亲身经历），描述了被人当作强制执行者的弊端：
我最近被拉去帮助一个软件开发团队完成一个产品的开发，具体的要求是协助一些Web应用程序的编码。我尽了自己最大的努力去融入这个团队，热心地帮助他们，以赢得一些信誉和尊敬。
我时常转发“Joel on Software”上的各种小文章给大家，还建议在公司里摆上一堆像《代码大全》、《人件》以及《人月神话》之类的书籍。不管任何事情，只要我觉得可以做得更好，我都会尽力给大家指出来。我经常浏览源代码库，以找出可以让其他成员工作得更好的方法。
译者注：Joelon Software（Joel谈软件）是Joel
Spolsky的个人博客，主要介绍他在软件开发与管理方面的经验。这个博客在全世界程序员中非常流行，他也因此被称为“程序员部落的酋长”。博客上的一些精华文章现已汇编成书，中文版为《软件随想录》，于2009年12月由人民邮电出版社出版。Joel还是Stack
Overflow网站的联合创始人。
当其他开发者来向我寻求帮助的时候，我不仅帮他们解决实际的问题，我还举一反三——指出他们在开发方式上的问题，教他们怎样改进打字形式，告诉他们该使用哪种命名规范，提倡一种更好的代码编辑工具，并且对究竟应该使用存储过程（Stored Procedure）还是动态SQL的争论给出我训练有素的最终结论。
然而，所有这些努力似乎都不起作用，我还是会常常受到他们的抵制，而且我觉得整个团队不是很喜欢我。我的很多建议都没有被采纳，而且我觉得有些人给我的回应是毫不掩饰的讽刺。
我到底哪里做错了？
我相信我们都曾和这样的人一起工作过。也许我们自己就是这样的人。即使你有最好的意图，并且已经熟读我给大家推荐的优秀书籍，你最终还是会落得跟枪炮士官哈特曼一样的下场：被你自己的团队“枪杀”了。
在文章的最后，Dennis对如何避免被你自己的团队“枪杀”做了一个很有想法的总结：
保持谦虚。总是先假定你是错的。虽然开发者的确是会犯错误的，并且作为一个新人你理所当然应该帮助其他人发现和修正错误，但是在你骄傲地宣布你的发现之前，你应该努力确保你的观察结果是正确的。如果你老是喊着“狼来了”（慌报险情），你的信誉将遭受巨大的损失。
提出建设性的批评时要小心。开发者更容易接受非正式的建议和具有巧妙引导性的问题，而不是把同样的内容以电子邮件的方式发送给整个开发组。扩大受众面很可能会引起开发者的防御和逆反。团队总是会去猜测你的动机。如果你贬低他们的工作是为了提升你自己，你会因此被投诉而流放的。
要想赢得信誉和尊敬，最好的方法就是努力工作并且取得实实在在的成绩。廉价而肤浅的替代品——例如群发关于最佳实践的邮件，或者转发别人鼓吹某种“银弹”的评论——它们不会产生同样的效果，到头来你可能也只是枉费心机。
百说不如一干。创建一个团队博客（blog），或者一个维基（wiki），或者实施一种新的代码控制机制，或者实现一种新技术——这些事情说起来都很容易。所有人都知道，你只是在声明这些主意是你想出来的，而实现它们所需付出的艰苦努力却最终会落在别人的头上——他们会因此而讨厌你。如果你想建议些什么，你应该为此付出实际的行动、做好充分的准备。例如，展示团队博客的基本要素，包括初级的使用指南，以及所有的支撑技术。这并不能保证团队对你的倡议会一呼百应，而且你还可能徒劳无功，但团队会意识到：你是付出努力的，你在积极地推动它，而不是在试图捡便宜。
没有一个通用的建议可以适用于所有的情况。不是所有的应用都是大型的电子商务网站。仅仅因为那是最普遍认同的最佳实践，并不意味着它对你所加入的团队来说也是最好的设计原则。也许差得很远！
我喜欢Dennis的建议，因为他均衡地关注了行动与结果。他的结论和我个人观察的结果高度一致：最有效的一种技术领导就是以身作则。经常发生的是，开发主管没有时间和权力去强制执行（即便他们想那样做），于是他们都身先士卒、用行动来说话。
但是，单单行动或许还不够。即使你花上一辈子的时间去学习如何领导，结果可能还是不得要领。Gerald Weinberg的著作《Becoming a Technical Leader: An Organic Problem-SolvingApproach》对软件工程领域的领导力做出了更为深入的分析。
译者注：《Becoming a Technical Leader: An Organic Problem-Solving Approach》的中文译本是《成为技术领导者——解决问题的有机方法》，由清华大学出版社于2003年出版。
在最初的几章里，Weinberg就已经点到了发生在枪炮士官哈特曼以及Dennis Forbes身上的问题的根源：
我们希望怎样被帮助？我不想别人因为怜悯而帮助我。我不想别人因为自私而帮助我。这些情况下，帮助我的人完全不把我作为一个“人”来认真对待。我想要别人对我做的是，真正地爱我——当然，不是那种浪漫的爱，而是真正的对人性的关怀。
因此，如果你想要激励一些人，不管是以直接的方式还是通过营造一个协助的环境，你必须首先使他们相信你是真的关心他们，而惟一能确保他们相信你的方法就是你去真正地关心他们。人们可能会受到虚情假意的关心，但它不会长久。这就是为什么“黄金准则”的第二版说：“爱你的邻居”，而不是说：“假装爱你的邻居”。不要自欺欺人。如果你不是真的关心那些你所领导的人，你作为他们的领导是永远不会成功的。
译者注：黄金准则（Golden Rule）指的是一条公正的准则，可以在世界范围内的文化和宗教里找到，它引导人们要“像你希望别人如何对待你那样去对待别人”。换句话说，你希望别人怎样对待你，你就怎样去对待别人。作者这里引用的是《圣经》中的黄金准则。
Weinberg的《成为技术领导者》是一部真正的经典之作。它跟另一位思想极客的《赢在影响力：人际交往的学问》如出一辙。领导力的很大一部分就是要学着在乎别人，而这恰恰是我们程序员所不擅长的（我们在这方面已经声名狼藉）。我们热爱的是机器和代码，而我们的队友毫无疑问要复杂得多的多。
译者注：《赢在影响力：人际交往的学问》一书的作者是戴尔·卡耐基，英文原版的名字为《How to Win Friends & Influence People》。这本书创造了全球出版史上空前的发行记录。它深深地触动着读者的神经，满足了人们在人性方面的需要。其作者是美国著名心理学家，人际关系学家，20世纪最伟大的人生导师。他以超人的智慧和严谨的思维，在道德、精神和行为准则上指导了千千万万的读者。他还著有《人性的弱点》、《人性的光辉》、《语言的突破》、《美好的人生》、《人性的优点》、《林肯传》、《快乐的人生》等书。其中《人性的弱点》是继《圣经》之后世界出版史上的第二畅销书，被译成28种文字，全球销量突破1500万册。
作者在Twitter上发的一条短讯：
“雅虎的教训是，一个领导力差劲的公司注定会失败。‘一堆程序员呆在一个房间里’不是领导力。”
12:17 PM – 2012-5-23