技术领导要不要写代码？这是一个问题。
我刚工作的时候就听说，程序员（那时候还没有“码农”的说法）是吃青春饭的，到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。团队生产率的提高正是公司对领导者的期望与考核标准。所以这个技术领导或许自己不满意，却是称职的。
这个道理我之前在《领导的对象，是人还是任务》中讲过。领导的对象既不是单纯的人也不是单纯的任务，而是以人为媒介，驱动团队成员去完成更复杂的任务。
所以如果你是程序员出身的技术领导，一定要区分“自己”和“团队”，你要考虑的不是怎么让自己写得更快更好，而是怎么让大家都写得更快更好。只要你能持续提升整个团队的生产效率，你就是称职的，哪怕“看不上”其他人的代码，也得忍住。
在上面的例子里，如果你能把剩下3个程序员写代码的速度都提升到1.5，代码质量都提高到1.4，总生产率就有 1.5×1.4×3 = 6.3。这时候技术领导一行代码也不写，而且下属写代码的水平仍然赶不上自己，团队的生产率提高却是板上钉钉的事实——当然你还有其他办法，比如优化人员组合引入用生产率与自己相同甚至比自己更高的程序员，这样的效率更高了。
当然，“一行代码也不写”多半是理想情况，许多时候技术领导还是必须要写代码的，因为软件开发终究是手艺活，大家认同的也是手艺。所以很可能会出现下面的情况：团队很缺某方面的开发经验或能力，除了技术领导之外暂时没人能对付；或者某个程序员不服气或者不理解某个决定，不能用头衔而只能用代码来说服和阐释……
除了这些“必须”的情况，我也主张技术领导“应当”写写代码。软件开发这个行业还太年轻，层级隔离做不到那么好，只说不写是找不到感觉的，而很多技术决策的依据正是这种感觉。所以我每次接手新的项目和团队，通常都要把代码全都看一遍心里才有底，自己提交几个功能才算找到了感觉。
这样看来，“技术领导要不要写代码”这个问题没有统一的答案。所以有时候你不得不忍住“让我来写”的冲动，有时候你又不得不忍住恶心亲自动手。
就我个人而言，我觉得写代码而且不愿意放弃写代码能力的技术领导更可爱。程序员大多是单纯的，一起写代码，哪怕只写几个功能，也会告诉大家“我不是来发号施令的，而跟你们一伙的”。
From Life Sailor, post 技术领导要不要写代码？
家长应当和儿童，尤其是低龄儿童谈论“空气动力学”吗？ 我的答案曾经是非常肯定的：不应当。不要说儿童，就是成年人也不见得理解这些抽象的概念，与儿童谈论这些名词，只会让人望而生畏。身为父母，我们应当做的是，以孩子能理解的、感兴趣的方式谈论相关的具体问题，但绝对不要提这些大词。 不过世界的奇妙就在于，父母对教育并没有绝对的权威，总是需要根据实际情况来修正自己的观点。在“空气动力学”的问题上，我就吃到了教训。 那是一个下午，家里小朋友在iPad上看完他最喜欢的Blippi（这个节目我之前介绍过，对80后父母来说，Blippi可以理解为“带你见识各种新鲜玩意的董浩叔叔”），忽然抬起头来问我：“爸爸，你知道什么是aerodynamics吗？” “什么？你问我知不知道什么是aerodynamics？”我的下巴都要掉下来了。“空气动力学”这种词还是上中学时，身为军迷的我们在《航空知识》上知道的。再往后英语好一些，能看原版科普视频了，才知道“空气动力学”的原文就是aerodynamics。可是，我家这个还没上小学的家伙，竟然就能真诚地瞪大眼睛，一本正经地问我“知不知道什么是aerodynamics”。 (more…)
我本来是不应该认识孟老师的。 2001年，我在寝室夜谈里第一次听到孟老师的名字。当时有同学说“公共选修课的《法学概论》讲得真好，那个老师叫孟繁超”，开始我不怎么在意，慢慢才发现这么说的人还不少。那个年月网上的资料正丰富，出版管制也不那么严格，刚进大学不久的我正自由自在地看得过瘾，心想“大学里的法学概论讲再好，能讲些什么，还不是教科书上老一套”，所以这种课，不听也罢。 但生活就在这么奇妙。那年冬天，有天中午我吃过饭正准备午睡，忽然有人敲门问“计算机系有位叫余晟的同学在这里吗？” 大中午的谁会来找我？我正好奇这个问题，门一推开就有同学喊“孟老师，孟老师来了”。 那是我第一次见到孟老师，中年人，国字脸，身材高大，打扮很精神，披在身后的深色大衣让我一下子想起电影里的斗篷。他笑眯眯地说“你是余晟？听同学说你搞电脑很厉害，我家的电脑坏了，想请你去看看。” (more…)
中国人大概都对历史有一些特别的偏好。对我们普通人来说，历史首先是文化的象征，一个人“懂历史”，基本等于这个人“有文化”；历史也是民族自豪感的来源，哪怕考古上仍然存在争议，但是“五千年文明”的说法是普通人都耳熟能详的。 不过等我长大之后才发现，这种偏好大概还有更深层次的原因，那就是历史看起来有种道德的意味，因为我们从小就熟悉“以史为鉴”的智慧，也熟悉各种“历史的选择”：每当我们对现实感到失望、困惑的时候，我们经常去历史——而不是先贤的智慧中——中寻找解答。找到曾经发生的类似的故事，就可以预言未来的结局。 于是乎，失望也好、困惑也罢，总归会有光明的未来，历史总会给我们支撑的信念。 我曾经很相信，熟谙历史是种智慧，而且是深层次的智慧。但是看得越多、经历得越多，我就越觉得，这很难称之为“智慧”。 为什么？ (more…)
“无人出租车要来了”。以百度“萝卜快跑”为代表的无人出租车，眼看就要在国内多个城市成规模运营。 熟悉IT的人都知道，IT的独特优势就在于“大规模扩展时边际成本极低”。在软件时代，微软开发的Windows，多卖一份的成本只是多刻录一张光盘而已。在无人驾驶时代，从10辆车到10万辆车的成本，也遵循同样的规律。换句话说，一旦模式“跑通”了，就可以迅速大规模铺开。无人出租车的大规模应用，也是“指日可待”了。 只不过，新技术这一次似乎没有那么激动人心，反而引起了很多争议——无人驾驶出租车大规模推广，会不会影响广大出租车、网约车车主的收入甚至生计？如果是，这样的技术进步，真的是我们所需要、所期待的吗？对于这个问题，不同的人有相差迥异的答案。 按照我的观察，许多人对此是相当乐观的。理由在于，“技术的每一次飞跃发展，虽然有阵痛，最终都创造了更多的新岗位”。既如此，无人出租车短期“看似”抢了许多人的饭碗，但也只是短期的“阵痛”而已。看看历史，纺织机的发明，蒸汽机的改良，汽车的诞生，无不证明了“阵痛说”的正确性。 坦白说，这种观点我是怀疑的。 (more…)
因为小朋友放暑假，近期带小朋友回国待了几个礼拜。最深的感受就是标题所说的：松弛一点，愉快一点。 我第一次突出意识到这点，是在上海下飞机乘地铁。当时我们乘的直梯就要关门，远远看见有个年轻小伙子跑过来，我连忙按住开门按钮，并招呼他”别着急，慢慢来“，等他进了轿厢才关门。本来我以为大家起码会打个招呼，露个笑脸，因为我已经习惯如此，但完全出乎我意料的是，他进来之后对我们完全视若不见，自顾自掏出手机，盯着看得入迷。 我继而发现，不管是在电梯里，站台上，还是车厢里，虽然四下里都是广播”请扶好站稳，抓好扶手，不要看手机“，但是似乎人人都盯着自己的手机。年轻人在打手机游戏，年纪大一点的在滑各种小视频，还有不少人在聊天软件里打字如飞……对着屏幕的表情都很生动，可是一旦抬起头来，似乎马上又换了个人。 后来又有一次，我乘地铁的时候，因为比较拥挤，一个小伙子倒退时踩了我一脚，他大概意识到了，很快把脚挪开，脸上闪过一丝不安，马上又恢复正常，我也没有计较。不幸的是，过了十来分钟，他又踩了我一脚，同样是先有一点不安，很快又恢复正常。 这次我忍不了了，于是我开口告诉他：“小伙子，你已经踩了我两脚了。” (more…)
前几天，国内朋友发来一条消息，原来是乌克兰F-16坠落，飞行员丧生的新闻。我本来以为他要讨论此事的真假和原委，他真正的问题却完全出乎我的意料： 新闻里说，飞行员叫阿列克谢·“月鱼”·梅斯，对应原文是Alexei “Moonfish” Mes，为什么会有人把“月鱼”写在自己的名字里，而且还打引号。 之前看新闻，乌克兰还有一个著名的飞行员叫安德烈·“果汁”·皮尔希科夫（Andrii “Juice” Pishchykov），怎么“果汁”也是正式的名字？ 未必Moonfish和Juice之类，还有什么特别的含义吗？…… 这堆问题看的我有点想笑，因为自己以前也很苦恼外国人的名字，只有在国外长期生活，才逐渐搞清楚这其中的名堂。所以，除了解答朋友的问题，我也把自己的解释写下来，搞清楚两个最不容易理解的点，就不会对外国人名有那么多问题了。 (more…)
View Comments
谢谢你的分享
感谢分享，有启发