程序员

技术领导要不要写代码?这是一个问题。

我刚工作的时候就听说,程序员(那时候还没有“码农”的说法)是吃青春饭的,到30岁就熬不了夜写不动代码了,所以要尽早转管理岗。相应的,如果你走上管理路线成了技术领导,自然就不必干写代码这种低级重复的体力劳动了。所以当时自己代码写得很多,技术能力增长很快,但总感觉有点别扭。那感觉就像,你能把车开得又快又熟练,最终只是为了能按时到达机场赶上飞机。然后,你就再也不用开车了。

不过无论如何,赶上飞机看来是更高级的选择,为了它,放弃苦心修炼的车技也可以接受罢。

但是等我真正走上管理岗位,才发现事实和我想的完全不一样。当时公司的业务增长飞快,支持业务的系统却是几年前“一锤子买卖”的外包项目,更要命的是技术团队的人员组成和工作习惯还处在作坊状态。从我的角度来看,四下里全是大坑,填坑的速度慢得让人着急,在此过程中还经常挖下新坑…… 在我的职业生涯中,我从没有在那么短的时间里写过那么多代码。几年后大家查提交排名,我的名字仍然第一。好在我的努力没有白费,系统终于没有垮掉,顺利回到正轨。

当时我身为技术领导,除去招人、定流程、做运维,还花了大量时间写代码,这样的做法是对的吗?如果是对的,后来我再没有写过那么多代码,好像也与“不称职的领导”无缘,甚至还被夸奖过“忍住放手让下属去做事,锻炼了组织”,这又是怎么回事呢?

很长时间里我都在思考这个问题,发现大家的说法也大不相同。有人言之凿凿“不写代码的好领导不是好领导,因为只有自己写的代码才心里有底”,也有人斩钉截铁“当了领导还写代码是对不起公司,公司发给你领导的工资不是让你敲代码的”。

大家的观点水火不容,所以或许这个事情并没有统一的答案,只有回到具体问题才有答案。我能确定的是,在我当时所处的情况下,自己不写代码系统肯定会瘫痪。但是跳出来看,又不能说“领导要写代码”就是放之四海而皆准的。所以只能具体问题具体分析,下面说说我的“具体”看法。

首先要确信的是,写代码不是丢脸的事情。为了心平气和地理性讨论,我们应当摒弃那些天然带有强力感情色彩的词语,比如“码农”,同样也要注意摘掉其它的有色眼镜。在我们所处的时代,再复杂的算法,再精妙的系统,也必须输入一行行代码来实现的。这就好比写文章,文笔再好的人,也得自己一个一个字地把文章敲出来。

其实这个比喻还不是那么合适,敲键盘是个“标准化”的过程,不存在“打字质量”的问题。写代码更像“创意”,比如多个程序,有同样的输入和同样的输出,但是这些程序到底能应付多少异常情况,有多么稳定,效率差多少倍,离开代码是很难发现的。正因为程序的质量很大程度上取决于代码的实现,所以写代码是必须的工作环节,写好的代码更是非常值得追求的目标。

其次,技术领导不是什么“高人一等”的角色。软件的“软”就在于它是看不见摸不着的,很多时候不能从现实生活中照搬模型,只能靠思维和经验去把握。技术领导肩负着更大的职责,就应当有更深厚的经验与更严密的思维,才能保证软件开发的效果。单薄的专业经验加上发号施令的权力,这样的组合在其它行业或许能当领导,但在软件开发行业充其量只能诞生不称职的技术领导。埃里克·施密特在《How Google Works》里面写道,Google需要的是既有领导才能又有自己实现能力的“创意精英”,我也觉得这种人是技术领导的最佳人选。

既然“写代码”不丢脸,“技术领导”也非高人一等,也就没有必要把两者对立起来。所以我们不妨放宽视界看看更要紧的问题:技术领导这个角色,究竟应当干什么?

可以肯定的是,技术领导领导的是技术团队,所以要对整个技术团队的工作负责。下面我们用简单的模型来分析技术团队的工作。

A是很不错的程序员,写代码速度是2,是普通程序员的2倍,代码质量是1.5,是普通程序员的1.5倍。他对自己的状态比较满意,认为“搞开发就得是这样”。确实,他的生产率是普通程序员的3倍(2×1.5),他也确实很棒。

A的表现获得上级的肯定,于是升任技术领导,领导3个普通程序员开发程序。如果大家的工作都保持不变,那么团队生产率是 2×1.5 + 1×1×3 = 6。

但是A升任领导之后,必然要花很多时间去做写代码之外的事情,不再保持“个人贡献者”的角色。我们假设他花了一半的时间去做其它事情,而代码质量保持不变,那么他的生产率降低为 (2×0.5)×1.5 = 1.5,A的生产率下降了很多。

A应当记住,现在自己不是“个人贡献者”了,所以应当关心团队的生产率。如果团队的生产率不变,那么整个团队的是(2×0.5)×1.5 + 1×1×3 = 4.5。这几乎是最坏的情况,技术领导被琐事缠身无法做出贡献,团队的生产效率因此降低。

但是,如果A再减少自己写代码的时间到0.8,把省下来的时间用于制定开发规范、砍掉不合理需求、搞活团队气氛等等,情况就会不一样了。假设A的一系列安排,让其他3个程序员的写代码速度提高到1.3,代码质量提高到1.3。

对很多技术出身的技术领导来说,这种状态往往不让人满意,因为看不上其它程序员写的代码,总归要自己写才放心。但是,这时候团队的生产效率却变成了 0.8×1.5 + 1.3×1.3×3 = 6.27,反而高于最初的6.0。团队生产率的提高正是公司对领导者的期望与考核标准。所以这个技术领导或许自己不满意,却是称职的。

领导的对象既不是单纯的人也不是单纯的任务,而是以人为媒介,驱动团队成员去完成更复杂的任务。

via: 余晟以为(公众号)