这是我参与8月更文挑战的第14天，活动详情查看：8月更文挑战

总体评估方向

1. 对技术的分析和判断⼒
2. 对待预估任务时间的态度
3. 为⾃己的工作建⽴明确的边界
4. 对“异端”的相容度
5. 对每⼀项提交记录 (⽇常工作成果) 的态度
6. 对待交付的态度
7. 对待技术⽋债的态度
8. 对待⼈员流失的态度和处理方式

1. 对技术的分析和判断⼒

技术没有先进与落后之分，只有适用与不适用。要相信世间任何事物存在即有它合理之处。

如果你经常听某个程序员对你说 “xxx 很先进，比 yyy 好多了，应该⽤ xxx 就不会有这些问题了”，“xxx ⾮非常强⼒力力，BAT (此处可换为任何⼀一个公 司名) 的 yyy 项目以前用的是 zzz，现在都改用 xxx 了” 那么就要对他的判断力打个问号了。

如果换成是你，你可以尝试以下两种方法来表达：

“xxx 虽然在 aaa ⽅面不太好，但比 yyy 更适合我们的项⽬，因为我们眼下更需要 bbb 和 ccc，将来如果在 aaa ⽅面出了问题，我们可以做这样的调整: 1… 2… 3…”

“我们之所以不用常规方案 xxx，而是用更激进⼀点的 yyy，是因为我们的项⽬在 aaa 和 bbb 等方⾯面没有那么强的约束，虽然损失⼀一些 ccc，但是可以获得更高的 ddd 和 eee” 如果你发现一个程序员，⾏走都把某个特定的平台/工具/技能/编程语言挂在嘴边，“xxx 就是好啊就是好”，你就会知道他不不仅有选择上的局限性，也会在技术判断中 不可避免的因为已有的积累产⽣偏见，正所谓“⼿里握着锤⼦子的时候，满世界长得都像 钉子”，一般这种程序员，我们称之为“信徒式程序员”。

2. 对待预估任务时间的态度

诚实是⼀个重要的品质。相比起对他⼈的诚实，对⾃己的诚实就更难了。

举个例子，你答应了两个礼拜后交付一个版本，可是因为某些原因，一个礼拜过去之后，你发现⾃己还需要两个礼拜，这时你会如何选择呢?

诚实的态度是，承认⾃己的时间预估是不准确的，要么砍掉一部分计划，按期交付，要么保证功能的完整性和质量，延期交付。如果一⽅面拍胸脯保证能按时交货，另⼀⽅面罔顾负荷与节奏，过度地挤压，就是不诚实的表现。这样短期内能获得更好的 KPI，但⼯程质量，团队士气都会受到打击，长远看得不不偿失。诚实余额不足的协调者，惯⽤这种伎俩，通过各种手段，汲取和消耗组织的能量来为⾃己的 KPI 充电。更更糟的是，这会使组织对团队的能⼒做出有偏差的判断，进⼀步放大问题，以致⾛上一条不归路。

正确地预估任务时间，是⼀项需要经年累积才能有一点成长和收获的技能。任何一项任务，有经验的开发者给出的不是一个拍脑袋的日期，而是包含以下诸要素的整体判断:

• 完成核心功能需要的时间预估
• 完成次级功能和周边工具链的时间预估
• 系统集成
• 稳定化
• 性能优化的时间预估
• 预留的缓冲周期

有经验的程序员对计划中的弹性点保持敏感，计划会随着实际进展不断调整，不会刻板地拘泥于原计划。他们的计划会尽量做到诚实且忠实地反映实际的进展情况。如果突发情况造成了计划外的影响，能及时地去做出调整，并向需要的人更新状态。

3. 为⾃己的工作建⽴明确的边界

所谓“明确的边界”，就是能尽早地建立明确的头脑模型，尽早摸清楚 (在你负责的领域内) 什么必须做，什么可以做，什么不能做，什么做不不了了。

有明确的边界会带来很多显性和隐性的好处。最重要的好处是，⼤家的需求关系明确化、协议化，不再依赖私下的潜规则，会节省后续⼤量的沟通成本。其次，愿意为⾃己的工作范围建立明确的边界的程序员，对边界内的代码质量通常会有强烈的责任感和主⼈翁意识，他们会比其他人敏感和熟悉得多，在他们的地盘上，他们能彻底的说了算。相关系统内如果出了问题，让其他⼈来可能要修两三天，换他来可能凭着对相关代码的熟悉度闭着眼睛就说出几个可能的问题点。

充满各种潜规则的系统⾮常脆弱，如果你发现一个程序员总在焦头烂额地处理沟通事务，往往就意味着隐患已经浮现出来了。缺乏边界意识的程序员，往往伴随着对代码较低的责任心。他们不把⾃己工作的代码看做是“⾃己的”，自然也就不会尽⼼尽⼒地去好好维护。

有种流⾏的说法是，应该通过某种形式的“轮换”，把程序员打造成“可轮换的”螺丝钉和多⾯手， 以降低⼈人员流失带来的风险。也许这一方式对其他⾏业会很有效，但至少在游戏行业，我发现，被这样轮换的程序员，这样来过几次之后，确实是对彼此的系统更熟悉了没错，但他们变得不再像之前那样“精⼼心地”照料料⾃己原本负责的那片代码。因为被 n 个人按⾃己的思路修理过之后，他们已经失去了“对那片代码的爱”，他们逐渐慢慢地从“园丁”变成了“游客”。随着时间的推移，没有人对这个模块内部的所有可能状态了如指掌，曾经被精⼼照顾的花园慢慢地变成了废弃的垃圾场。每个人改到这⾥都是⽆奈地捂着鼻子赶紧弄完了事，只要不要弄出新的问题就谢天谢地。这种腐化通常是加速⽽且不可逆的，从⼯程角度来讲，这往往预示着这一堆代码的废弃。更残酷的是，程序员们纷纷发现在这个项目里无法积累真正的领域相关经验，成为专家，还有什么比天天围着一辆⼆⼿车的不同部位反复修理⼜得不到成长更糟糕的事呢?他们唯⼀合情合理理的选择，就是拂袖⽽而去，或是准备以温和一点的⽅式拂袖而去。

程序员对代码的爱是⼀个项⽬里最稀缺的资源之⼀，不要忽略略它，更不要粗暴地碾碎它，要通过创造稳定的环境和氛围去创造它，培育它，这样的代码库才能成为肥沃的⼟壤，带来源源不不断的回报;否则就会变成⼀个摇摇欲坠、四处冒烟的，靠巧合来得以运行的庞然大物。

4. 对“异端”的相容度

「托利利得定理理:测验⼀一个⼈人的智⼒力力是否属于上乘，只看脑⼦子⾥里里能否同时容纳两种相反的思想⽽无碍于其处世行事。」

这句句话有三层递进的意思:

1. 具有包容性。能够理解⽭盾各方的情势，对盲点敏感，不容易被蒙蔽。
2. 具有批判性思维。能⽤用理性和逻辑等工具去分析问题，形成⾃己的判断，不盲从。
3. 具有人格独立性。依本性从事，不存偏见。

这三样对于程序员来说，都是⽐较重要的软素质。寸步不让，主导意识强烈的程序员，往有着惊⼈的⾃信—要注意这种⾃信有时会成为双刃剑。在讨论中展现出不必要的自信，往往在令⼈屈服的同时，促使对方从“奉献者”转变为“打卡者”，降低整个团队的战⽃力。

5. 对每⼀项提交记录 (⽇常工作成果) 的态度

有经验的开发者从⼀个程序员的提交记录里，能读出太多的东西:

对于⾼素质的开发者，你能不费太⼤力⽓就能顺畅地读出他近期做了哪些⽅⾯的工作;在哪些点上曾遇到了了困难，选择的解决⽅方案是什么;当他权衡和折衷时，考虑的最多的是什因素;在⼀段时间内，贡献相对均匀 (DPS 能保持在相对稳定的节奏) 而相对的，如果你在提交记录里看到不不少 “临时方案”，“暂时先注掉”，“先跑起来晚点再改” 这样的句式，或者提交信息简短到像发电报，或者提交⼀⼤大堆代码却不不写提交信息，那么这样的程序员的实际贡献意愿和实际产出结果就要打个问号了。

查看⼀个程序员的 commit history，⼀眼扫过去，如果除了 “完成了xx功能” “修复了 xx bug” 等 信息之外，还有⼀些 “改善了 xxx 的内部结构，⽅便后期维护”，“简化了 yyy 的接⼝，降低了跟 aaa 和 bbb 的沟通负担”，“⾃动化或移除了 zzz 的操作，省去了跟 ccc 的额外沟通和确认的步骤” 你就可以知道，这个程序员不仅业务能力过硬 (勉强能完成任务的程序员，是很难有余⼒去操心这些事的)，⽽而且对项⽬也有⾜够的责任⼼和爱⼼，愿意把⾃己的真正心⾎奉献给项目，⽽不是想方设法总是凑合和应付，“先弄出来再说，哪管之后洪水滔天”。

其实，这也是最快的考察工程师团队的⼀个⽅方法，一个团队的做事⽅式，效率，甚⾄至是⼠⽓和状态，从 commit message 上能读出⼤量的细节，⽽不少信息是从平常的交流里无法提取和判断的。

6. 对待交付的态度

有经验的程序员明⽩，提交功能的那一刻，只是交付的开始。

7. 对待技术⽋债的态度

一个快速前进的团队不可避免地会留下或多或少的技术欠债，这是敏捷所要付出的最大成本之一。并非所有的技术欠债都需要偿还，它们中相当⼀部分实际上会随着开发风向的变化被直接⻛干和丢弃。有经验的程序员会时常为⾃己的⽇常⼯作留出处理技术⽋欠债的时间，他们会及时查遗补缺，趁着⼿头任务的余温，补上因为快速开发而遗漏的东西，同时果断抛弃那些越积越重的包袱，尽量轻装上阵。

如果你观察到一个程序员总是乐于做新东西，他的提交记录里缺乏对已有系统的梳理，那说明他更适合作为突击队员，还不能适应作为⼀个组织者的⻆色。

8. 对待⼈员流失的态度和处理方式

有经验的程序员永远不不会故作惊讶，对同事或下属的离职假装出惊讶的样⼦。他们总是“Work for the best, prepare for the worst”。他们在过去的经历里吃过亏，明白“靠⼭山会倒，靠⼈人会跑”，所以早在一个⽣力军加入⾃己负责的团队之前，他们就会计划好此⼈一旦离开时的善后处置⼯作。他们不会轻易让⾃己的团队没有原则地进人，也就不会让⾃己负责的业务因为某一个人的离职变得失控。

但这绝不是在说他们对⼈员流动无所谓，不会主动捍卫⾃己团队成员的利益。正相反，他们会重视每⼀个做出贡献的成员，竭尽所能地为他们争取应得的尊重;他们会把哪怕只贡献过⼀⾏代码的离职同事都仔细地整理出来，放在 Credits ⾥的合适位置，以确保他们的⼯作得到认可;即使某些成员在⾃己负责的团队内表现不佳，当这些成员离开时，他们尊重个体的选择，并仍愿意给予力所能及的最大的帮助，因为他们清楚地知道，同⼀个人在不同的环境下，也有可能激发出完全不同的能量。