倔强的程序员

对于程序员来说，大多数人公司都有技术和管理两条发展路线，通常在同一家公司，管理路线的发展可能性，要相对广阔一些；但是技术路线也有技术路线的好处，比如相对而言更依赖于硬实力，因而工作机会丰富。我相信有不少程序员都和我一样，坚守着技术路线，无论是进还是退，都对管理者的岗位没有什么兴趣。

　　兴许大家都听到软实力和硬实力的概念。对于一个技术人来说，硬实力大致上可以认为是计算机和软件工程相关的技术能力，1 还是 0，是还是非，会不会算法，懂不懂设计，清清楚楚，明明白白； 而软实力则反过来，听起来挺抽象，挺模糊，比如沟通能力，自我管理能力，但是却扮演者重要的角色，甚至随着职业生涯的发展，它的影响力越来越大。而性格，是软实力中一个很特别的影响因素。

　　下面我讲的是在程序员技术发展路线中，“倔强”性格的影响这一个窄窄的范围，而且是就我的认知而言的。显而易见它不可能是很客观的。我相信会有很多人持有不同的看法。

　　我想大家都认可的是，基本上每个团队里面都有各种脾气性格的人。记得我刚工作的时候，团队里面平和和好说话的人更多。多数人性格都比较平和，这可能和资历、眼界等等因素也有关。以前读过一篇文章，说一个团队里面，有各种各样的角色，有牛、有猪，有狗、有猴子等等等等，分别代表着不同的性格。随着时间的试炼，大家发展的情况各不相同。在讨论方案和问题的时候，肯定有人不同意，但是只要多数人决定了做法，或者是几个强硬派决定了做法，大多数人也就不再计较，因此 commitment 比较容易做出，且朝着一致的方向。

　　但是随着工作年头的增加，我发现团队里面个人的性格，普遍是越来越倔了。无论什么时候我们讨论问题，观点不同是司空见惯的。可现在不同的是，要达成一致，并不是那么容易的事情。好吧，大多数人支持方案 A，少数人支持 B，兴许几年前这票支持 B 的就表示愿意按照多数派的 A 来实施了；可是现在呢，少数派一定要争论下去，技术方案的选择不是少数服从多数的选举，为什么要 A，我们来给 A 和 B 做做分析，我们来激烈地争论吧……

　　以前我认为，职业生涯的发展，到一定阶段，高级别一些的工程师，想必也是性格各异的吧，应该有的人比较强硬，有的人比较容易 pushover 的吧，性格这东西嘛，分布都是有随机性的。可是如今我接触到的情况呢，却恰恰相反。 这些发展比较好的程序员，相对于其年龄和资历，级别比较高的程序员，居然性格几乎无一例外的“倔强”。 而那些性格比较“好”的呢，相对来说发展普遍都没有那么好。看到的案例多了，似乎可以粗略地得到这样的结论：走技术路线的程序员中，性格倔强的人不一定发展得快，但是性格平和的人肯定不行。

　　虽然我能看得到的案例数量并不大，但我依然觉得这个现象有一定代表性。我觉得这里有这么几个因素：

• 倔强的程序员，往往也是较真的程序员，他们会追求最佳的解决方案，他们会追求最合理的代码实现，他们可能抠一点某些人看来无足轻重的东西，但是就是这些东西把软件的质量提高。
• 倔强的程序员，懂得维护自己认为正确的观点，而为了维护这个观点，会反复思考和分析。我没有见过一个能把 trade-off 做得好的人对维护自己的观点抱无所谓的态度。
• 倔强的程序员，遇到困难也不那么容易退缩。这也是显而易见的，性格软弱的人，通常也不愿意坚持己见。
• 倔强的程序员，他们享受争论的过程，也就更能够在争论中得到多样的视角。

　　但是，物极必反，倔强的程序员，也可能死得特别惨。我见过一些 被踢出团队的程序员，大致分为两类。一类是能力实在不足，绩效特别差，比如代码写得又慢 bug 又多；还有一类就是这类硬骨头，倔强到难以维持基本客观的程度，到处树敌，太过拖累整个团队的工作。

　　再结合程序员工作中的许多具体事情，再进一步谈一谈这些倔强的程序员们。就说个有趣的事情吧。我们把他们中的其中一个，叫做大 Z（这个字母看着就很霸气），而相对不那么“难搞”的程序员，叫做小 s。

　　在一次的设计讨论会议上大 Z 说对小 s 说，我认为你的方案不如我的好，理由是 xxxxx，于是大 Z 和小 s 来来回回一番争论，刚开始还算可控，但是大 Z 说，“我觉得你缺少扩展性的常识”。有经验的人可能马上意识到，大 Z 的这句话已经从“对事”变成了“对人”，这明显是不对的。于是这句话一冒出来，小 s 马上就不高兴了，再不痛不痒辩论几句以后，没有继续争论下去，显得很失落。

　　这个场景看起来是不是很熟悉？哪怕小 s 是更在理的一方，也放弃了继续争论下去的欲望，反而落得自己不爽好几天，每次和大 Z 沟通都会想着当时的场景，甚至觉得大 Z 还会有意无意针对他。有人可能会觉得，那大 Z 会不会事后觉得自己过分呢？我想说，大多数情形下，不会的， 以大 Z 的性格来说，他冒犯了小 s，他也许意识到了，也许没意识到，可是这样的事情他根本就不会放在心上 。回到事情本身，谁的方案更合理很难讲，但这件事情本身伤害到了团队中的成员，影响了团队的氛围。我们可能见到类似的事情到处都是，甚至在某些沟通强烈的地方尤为严重，比如 code review。

　　多数情况下，我们撇开技术本身的因素，谁的发展更好呢？却是大 Z。虽然有少数情况并非如此，但是多数情况下，大 Z 却有着更更为广泛的影响力，而 某些情况下争论所显露出来的 backbone 会盖过他在争论和为人上面的“恶霸”属性 。这也从某种角度说明，为什么到了一定级别的程序员，且不论技术如何，心理承受能力和沟通的技巧，都是有一定造诣的，那些敏感而脆弱的呢，已经挂在晋升的半路上了。

　　交流和沟通本身就是一个说不清道不明的复杂体，很多人可能会想要安安心心做技术，我相信也有很多公司希望提供这样环境。可事实是，绝大多数情况下，越是这样想的人，就越会发现，这只是一种美好的愿望，不可避免地，有很多为人处世上的“屁事”，未必要上升到“职场政治”那么高的程度，却依然会考验你的心理，磨炼你的性格。

　　最后，从团队管理的角度来说，哪一种人更合适呢？

　　其实，“合适”这个词的定位很难讲，但是倔强的程序员通常更难管理，这倒是真的。可是，换一个角度想这个问题，为什么要“管”，管理又要做到怎样的侵入性？理想的状况是，虽然有一些性格似乎比较“强硬”的程序员，但是他们是讲原则，讲道理的，如果团队的成员在总的目标上大致是一致的，团队就能够具备一定的兼容性。可理想毕竟是理想，团队中的磕磕碰碰遇到谁都能喝一壶的。特别是，如果管理者想成为那个决策绝大多数事情的人，碰到这些倔强的“大爷”们，很可能就会碰一鼻子灰。

　　在我的职业生涯中，待过好些团队，我见过这种管理者和倔强的程序员们之间的碰撞，有在挣扎和妥协中寻求平衡的，有程序员滚蛋的，也有管理者扫地出门的，甚至有两败俱伤，鱼死网破的。这里面也有很多有趣的故事，下次再说吧。