倔强的程序员

2022-07-19 14:35:29 浏览数 (1)

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

兴许大家都听到软实力和硬实力的概念。对于一个技术人来说,硬实力大致上可以认为是计算机和软件工程相关的技术能力,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,他也许意识到了,也许没意识到,可是这样的事情他根本就不会放在心上。回到事情本身,谁的方案更合理很难讲,但这件事情本身伤害到了团队中的成员,影响了团队的氛围。我们可能见到类似的事情到处都是,甚至在某些沟通强烈的地方尤为严重,比如 design meeting 和 code review。

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

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

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

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

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

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

0 人点赞