（给
伯乐在线
加星标，看经典文章
）
编译：伯乐在线/tsteho
我正在一点一点的从一个工程师转型为管理者。别弄错了，虽然我在转管理，但我仍然在每天写代码。不过我发现自己在会议和电话中会花越来越多的时间去分析讨论，试着去组织团队，并且为全局部署而不是具体战术而烦恼。
当然这不是一件坏事。高层次的决策往往比单个的类和函数的细节更有影响。让一个团队更有效率，比仅仅让自己更有生产力有更高的杠杆作用。但我想我已经从我多年来的编程中吸取到了一些经验。我希望大部分经验可以应用于管理方面。
1、没有规定（rules），只有公案（koans）
译注：公案（Koan）有五种重要的涵义： 作悟禅的工具； 作考验的方法； 作权威的法范； 作印证的符信； 作究竟的指点。）
举个例子：DRY，意思是「不要重复你自己」。作为软件的基本规则这很好理解，因为很多话可以证明：“我做 X 是因为它没有重复。”这说得通，不是吗？如果你有两个或者两个以上部分的代码在做相同的事情，说明你正在浪费。而且如果当你需要改变它们其中一个的时候，你可能也需要改变其他的，并且你很可能会忘记这么做。当它们不同步时，你会得到一个怪异的 bug。因此很显然你不能重复你自己。
然而，在使用了几年之后，人们开始怀疑它的普遍适用性。假如你的两个方法中包含相同的代码块，所以你将其拿出来形成一个单独的函数。通常那些方法会开始朝不同的方向发展…接着你发现自己要在函数中加入更多的参数，很可能为结果立了更多 flags……然后下一个接手的程序员会因为分离出来的函数以及它所带的特定的参数和结果，而出现认知负载。你会意识到如果当初允许自己重复，并让两块代码自然的发展为不同的个体，你生成的代码将会更简单直观。
这意味着 DRY 不好吗？当然不是！通常在合适的环境下使用 DRY 是正确的…好吧，也许。我个人的经验是：“重复一次是可以的，超过一次就不太好了…当然这取决于所处的环境。”因为所有事都取决于环境。DRY 的目的并不是为了 DRY。如果你迷信于此，小孩儿，那你还有太多要学。DRY 的目的为了让你了解 DRY。那当然不是规定，仅仅是公案。
（让我重申一遍：我在讨论的是软件。在我的经验中，硬件规定的确更倾向于是我们所理解中的规定。这就是我为什么要从电气工程转到软件的原因）
细想我最喜欢的两个计算机科学“定律”。第一：“计算机科学中没有一个问题是不能通过添加另一层抽象来解决的！”这句话完全正确吗？当然不。这在现象学上是正确的吗？实际上，的确是。这是否意味着抽象是解决任何问题的正确途径？不，不是。它是一个公案，可以启发思想。
还有我历来最喜欢的：“第一优化定律：不要这样做。第二优化定律（对专家而言）：不要又这样做。”这显然是一个公案，却称自己为法规。是时候让你的代码运行的更快吗？不。是时候让你的代码运行的更快吗？还不是。什么意思？意思是要考虑到时间，复杂性，认知负载，具体结果，生活意义，人类存在的意义。并且三思而后行，小孩儿。但不要花太长时间，我们还有工作要做。
2、要想得到他人的信任，先信任他人
这不仅仅针对于管理者。虽然它对管理者尤其重要。信任是你真正拥有的唯一价值。如果你的公正、判断、理解、诚实不被信任。接下来你组织的成员将把你视为祸害并绕着你走。然而，如果你是个有能力但不被信赖的开发者，你可能还有一些价值。虽然你在每个决定上做的努力都会被大大消减。
不过更重要的一点是：一个团队的成员需要互相信任。
当 Natascia 说：“我来解决那个问题单（ticket）”，你必须相信她会去做。当你说：“Peter 能在截止时间前完成的。”，你必须相信那会实现。当某人说，“我有一个疯狂的点子”，他们必须信任他们会被尊重和认真对待，尽管那点子的确很疯狂。
你是如何建立和得到信任的？答案很简单：你去信任他人。
你相信那个说他可以学会这个新库并且在周一前会整合完的人。你相信那个说他需要提前离开，因为家里有事而会错过明天工作的人。你相信那些想在截止日期前一个月休假的人，因为他们觉得自己已经开始筋疲力尽了。你相信说想要解决难题的初级程序员。
但你不总是正确的。有些时候人在工作上存了坏心。
你需要揭露这些人的真面目，让他们尽早离开。有时候你要信任那些真心想成功的人，虽然他们会失败。但违反常识的是，长远来看这通常是个胜利。因为那些人会记住你的信任，他们会尽一切努力来报答你。
3、简单比优雅重要的多
我也喜欢紧凑优雅的代码。我喜欢灵活的框架，有如此多抽象层次随时待命，无论抛出什么改变的需求都能解决。我喜欢使用位向量、位位移、略微复杂的数据结构和不太流行且古怪的小语言特性，但在特定环境下十分实用。
然而你并不只是为了你自己写代码。即使它只是个“原型”。（我已经记不清我有多少“原型”在多次对层操作和润色的过程中出现问题。）而且你不仅仅是为了解决当前的问题编写它。你正在为了下一个接手的开发者可以使用它来解决下一个问题而编写。把你写到那五行代码扩充为十行可以增强其可读性，你知道吗，也许扩展为十五行效果会更好。
你可以提前尝试并用灵活且充满抽象的框架解决它们。但是也许预言不是你的强项，也许你关于下一个问题的概念的想法完全是错误的。也许仅仅编写足够简单的代码才是最佳选择。有一个命名约定和一个编码风格，让它读起来像英语一样。也许不是添加一个类，而是下一个开发者在试图跟随你的控制流程时必须保持另一个文件的开放。你应该用愚蠢的方式，不雅的方式，简单的方式。
4、动力比大多数事都重要
我们都曾见过这种情况。一周里每个人都在检查代码，构建显而易见的雏形，每天不断增加特性，测试覆盖率越来越高。疏忽也随着生产的想法和解决方案而出现。不知怎么的下一周所有事都变得缓慢起来。关于 A 的决定，会影响到 B、C和 D。当人们可以运行D、E 和 F 时，它们不是逻辑序列发展上的一部分。于是需要做更多的假设，认知负载加重，你不得不模拟出一堆东西来写出非模仿代码。一些人需要做这个决定。
或许不是决定会瘫痪，是你上周所做的一切都在错误的基础上，是一个“地震多发区”的技术负债。你需要停止所有事返回并重构它。而且你必须马上开始，因为等的时间越长，事情会变得越糟糕。没人想看到这种事发生 。但他们宁愿现在面对也比下个月知道的好。让暴风雨来的更猛烈些吧。
也许上周每个人都拼劲全力，现在实在撑不住了。你知道该怎样吗？得让他们休息一下，每个人，休息一整天。我保证，这会给你接下来的“长跑”节省时间。
I我们很难定义、衡量以及说明动力。但它在软件开发中是真实存在的东西。而且它的缺失会成为造成首要影响，导致我们需要去解决很多根本问题。别忽略它，也别期望或假装它会神奇地回来。察觉警报并迅速采取行动。
5、与和你互补而不是像你一样的人一起工作
