一晃六年，《技术领导之路》要再版重印了。回想刚刚开始翻译这本书时，我还忙碌在程序开发的一线，对领导技术团队并没有太多经验；如今，也能差强人意地带领技术团队支撑年销售额数亿的业务。一路走来跌跌撞撞，所幸没有中途倒下。思考其中的原因，除去运气，除去身边同事朋友的支持，翻译《技术领导之路》也是不容忽视的因素。
很多人都知道，“职场童年”非常重要，一个人最初工作的几年，在什么样的环境里，得到过什么样的锻炼，很可能决定了他整个职业生涯的走向。同样的道理，“领导力童年”也很重要，一个人对领导力的最初接触和认知，也会深深影响他对于“领导”和“领导力”的观点，甚至领导作风。所以，在我还忙于一线开发的时候，通过翻译《技术领导之路》，“生吞活剥”了一整套关于领导力的学说，基本“塑造”了我关于领导力的认知，深深影响了我作为技术领导的管理风格和价值取向，因此也对很多问题有了自己的判断——前段时间和另一位掌管公司技术的朋友聊天，说起那种“执行力超至上”的领导风格，我们都认为，尽管或许能出结果，但不是好的领导风格。
怎样成为好的技术领导？《技术领导之路》的作者温伯格给出了一系列的答案。以技术人员的身份，我觉得最受用的几点是：通过写日记来加深自我认识，评估自己的能力应该用乘法而不是加法，从哪里寻找改进所需要的时间。
在生活中，我们大多会有一些自己的习惯和坚持，却习焉不察，没有去想过它们是否有道理。然而，如果需要不断改进自己，就必然需要不断观察和审视关于自己的一切，包括习焉不察的坚持。对此，温伯格给出的建议是，每天抽一点时间来写日记，不需要抒情，不需要感慨，忠实记录自己就好。开始我对此也有些怀疑，觉得写日记不过是小朋友过家家。但真正坚持之后才发现收获很大。因为静下心来写日记让我发现，在生活里，自己真正在乎什么，而不在乎什么。有一些东西我很在乎，但成长经历不同的人并不在乎，所以其他人并不是有意冒犯。还有一些东西我不在乎，却是某个人群特别在意的，考虑到其他人的感受，以后还是多加小心为好。
评估自己的能力“用乘法而不是加法”，可能初看起来不太容易理解，但也很好懂。人的能力通常是参差不齐的，有长处就必然有短处。要想成为好的技术人员，技术是不能“一俊遮百丑”的。以1分为满分，如果你的技术有0.8分，表达能力只有0.1分，总分可能不是(0.8+0.1)/2=0.5分，而是0.8*0.1=0.08分。如果给你时间把自己的技能提升0.1分，用来提高技术水平，总分可以到0.09，而用来提高表达能力，则可以达到0.16。哪种选择对个人更有利，其实是一目了然的。不幸的是，大家通常在潜意识里更愿意遮挡自己的短处，更习惯于训练提高自己的长处。程序员更是如此，面对非技术问题，他们往往更希望从技术方面解决。仅仅是因为他们更“喜欢”从这方面入手，而没有考虑这样做是否真的有效率。想要成为优秀的技术人员，一定需要能克服情感的抵触，注重补齐短板。
我在抓虾网（早年一个很流行的在线RSS阅读网站）工作时曾有过深刻的体验。有一次我们的抓取调度出了问题，抓取新浪博客过于频繁，被新浪封锁了服务器的IP。当时大家想出的办法就是找一大堆代理服务器，通过代理来抓取。从技术人员的角度出发，这种思路是自然而然的。我当时觉得还有更好的解法。于是我尝试给新浪打电话说明情况，一下午的时间打了超过二十个电话，终于找到了决定封锁IP的人。我向他说明情况，并说明我们已经修正了程序避免出现这种情况，他验证之后便解除了封锁。有了这段经历，不管是关于纯技术问题还是业务问题，我的思路都开阔了很多，也深刻明白了单纯靠技术是不能“一俊遮百丑”的。
关于改变自己所需要的时间，温伯格的一句话让我印象很深，“如果你想做某件事情却一直找不到时间，那多半是你其实不想做”。想要改变，尤其是自我改变，通常不会像上级布置的任务那样，有明确的压力和期限，所以改变也停留在“想”而已。网络上经常可以看到类似的问题：道理我都懂，但就是行动不起来。所以很多人在纠结，希望有什么办法提高行动力。但是在我看来，要解决这个问题，第一步是承认自己其实不想实践这些道理。
如果确认自己想去做这件事情，由苦于找不到时间，温伯格给了三个建议：第一，对已经分配的任务，不要反复纠结；第二，对实现过程中的细节，不要反复纠结；第三，不要让自己的生活被层出不穷的危机所支配。比如对于“缺乏行动力”的问题，如果你真的希望提升行动力，应该首先制定计划，制定好计划之后应该按时推行，在这个过程中可以容忍错误和异常，但不要轻易纠结计划本身。在实现过程中，不要过分纠结细节，比如学英语，捧着一本书刚看了个开头，又觉得要先学语法呢，还是先背单词，还想知道是这本书更好一点，还是那本书更好一点。更重要的是，要想有时间做自己的事情，应当把一切保持在“井然有序”的状态，哪怕平时需要花更多的时间来维护，这样才不会被各种意外所支配。我曾经见到很多程序员，每天忙于改正线上的各种问题甚至乐在其中，却从来不想想怎么让程序保持在“自主稳定运行”的状态，还一个劲的抱怨“工作辛苦，生活忙碌”。也正是因为如此，我才大力提倡程序员要“横向发展”，要操心程序运行的整套环境，才能真正把自己解放出来
当然，既然名为《技术领导之路》，温伯格讲得最多的还是“如何成为技术领导”。温伯格反复强调的根本观点是，人不应当被作为机器对待，尤其因为技术工作强调思考和创新，所以技术工作者更不应当被视为机器，而应当被视为种子——蕴含内在力量，会不断发展成熟的种子。所谓领导力，就是创造一个环境，让所有的人都可以发挥出比单干时更大的价值，并不断成长。以此为基础，领导力的培养和发挥，需要注意激励、组织、创新三个方面。
关于领导的激励，已经有很多的论述。不幸，通常的激励似乎是从行为主义心理学的角度出发的，认为简单机械的“奖励/惩罚”就可以对员工起到引导和归束的作用。但这种理论其实是行不通的。赫兹博格的“激励-保健因子”理论指出，员工在不同的阶段所看重的方面是不同的，简单说员工刚开始更看重的是个人生活、工作环境、薪金福利等“基本因子”，满足之后则寻求学习与发展、工作乐趣、成就与肯定等“激励因子”，而简单的“奖励/惩罚”在这些方面并不能奏效。更重要的是，因为技术工作的核心之一便是创新，简单的“奖励/惩罚”并不能催生创新。按照我的经验，激励的作用更多是树立正确的价值观，这种价值观既符合公司的利益，又兼顾个人的成长，而且还要能落实到真实的工作中来。
在很多公司，有一些程序员是众望所归的“明星”：程序出了什么问题，找他们可以第一个响应，而且他们可以非常投入地解决问题，哪怕加班加点也无所谓。可是如果仔细思考，这样的程序员有不少就是麻烦的制造者，因为他们写不出高质量的程序，只能以“高度的责任心”在线上除错。而且，这样的程序员往往因为态度好、加班多，受到大量的关注和鼓励。还有一些程序员，他们或许沉默寡言，或许不爱加班，但他们总能提交高质量的程序，上线之后就不需要自己再操心。不幸的是，这样的程序员往往不会获得关注，颁发奖励的时候也论不上他们。
身为技术人员，很多人都知道两种做法的优劣，但因为外界（领导）没有明确的褒贬，很多人并不敢坚持自己的选择。所以，如果希望成为好的技术领导，一定要注重激励的方面。在日常工作中，技术领导应当持续表扬和鼓励能提供高质量程序的行为（哪怕日常不怎么说话），而不是提交质量一般但努力除错的行为。有这种持续的激励，才有可能塑造正确的价值观，给有潜力但还在摇摆、困惑的成员发出清晰的信号，从而打造高质量、迅速成长的团队。
技术领导需要注意的第二个方面是组织。前段时间我和一位MBA朋友聊天，他说很多领导对于招人的定义就是：因为我忙不过来，所以我需要一个人帮我做这个。他评价说：“其实，这类领导需要的不是员工，而是劳工”。用我的话说，这种组织不叫团队，只能叫团伙。
既然领导力的表现是创造让所有人都能成长，都能发挥更大价值的环境，当然不能把所有人当成可以互相替换的棋子。按照温伯格的意见，好的组织应当是“全面的（Organic，也可以翻译为“有机的”）”，也就是可以互相取长补短，形成一股合力。假设一支团队里没有产品经理，虽然客户对产品的要求并不是太高，程序员也有一定的产品意识，交付的软件堪称能用。但技术领导应当看到，关于产品的工作其实消耗了开发人员大量的时间，而且开发人员本身并不“愿意”从事产品方面的工作。所以应当考虑补充产品人员，并让产品和开发协调工作，形成1+1>2的结果，提升整个团队的效率。同样的道理，如果团队里多数开发人员都比较沉闷，在继续招聘开发人员的时候，就应当优先考虑开朗外向的性格。
组织的全面，还提现在一个方面，即它是自组织的，各级的情况和任务可以在对应的级别自动自发地完成。或者用温伯格的话说：“（在全面的组织）中每个人都能解决问题，做出决策，执行这些决策。而领导不需要对各种问题亲自出面，亲自做决策，亲自执行”。这种观点也可以在其它相关书籍中得到验证，比如Uncle Bob就在《程序员的职业素养》中再三强调，团队要有凝聚力。要想打造全面的组织，有凝聚力的团队，温伯格列出了几种需要警惕的行为，包括“只抓大目标”（特别强调执行力的领导作风就是如此）、把人当成机器来看待（忽略人的情感和潜力）、事必躬亲（下属不应当仅仅是领导完成任务的手段）、奖励低效的组织（回到价值观的树立）等等。虽然我们日常工作中无法做到彻底戒除，但只有尽力避免这样的行为，才能真正营造全面的组织，形成有凝聚力的团队。
技术领导需要关心的第三个方面是创新。许多技术领导本身对技术非常有兴趣，所以他们自己在创新方面是没有问题的。但是身为领导，仅仅自己创新是不够的。既然相信人不是机器，既然相信软件开发是需要创造力的工作，那么就应当鼓励每个人的创新，为团队营造勇于创新的气氛。
在很多公司，技术领导往往掌握着框架和类库的生杀大权。我听到不少程序员说，自己在网络上看到了很多新的、好的框架和类库，但领导就是不同意。很多时候，这是因为领导没有用过，对此不熟悉，不愿意冒风险，毕竟领导要对公司业务负责。有时候我也确实发现，因为经验等方面的限制，一些程序员提出的创新想法并不实际。但是好的技术领导从来也不应该因循守旧。按照温伯格的说法，即便你用某种方式成功过，也不意味着没有更好的办法来解决同样的问题。所以，身为技术领导，应当鼓励所有人的创新，对于不够完善的创新建议，不能简单拒绝，需要代之以鼓励和引导。甚至在某个问题上，即便自己有过成功经验，心里已经确定了方案，也需要虚心听取其他人的不同建议，更要勇于采纳更好的方案。要知道，这样做并不意味着贬低自己的技术威信，反而确立了积极创新，并且能采纳合理创新建议的工作方式。只有一个人能创新的团队，永远不会强过一支人人都能创新的团队。
很多人读过《技术领导之路》之后跟我说：“我觉得这本书写得很好，我也承认作者说的很有道理。但是，这和中国的现实不搭配。我努力去激励了、去组织了、去创新了，却好像对牛弹琴，我领导的人似乎无动于衷。还不如安心当个包工头省心省力”。是的，我承认现实中确实有这样那样的困境，但我也认为这不是安心放弃成为优秀的技术领导的理由，因为有个重点书里没有写到，那就是想要打造好的技术团队，必须对招进来的人有足够高的要求。实际上，在《极客与团队》之类讲述技术团队管理的书籍里都强调了这一点：如果期望打造有战斗力的团队，必须保证大家形成一致的工作习惯和价值观；对这种工作习惯和价值观持续产生负面影响的“害群之马”，是应当坚决予以淘汰和替换的。
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
"在日常工作中，要持续表扬和鼓励沉默寡言但能提供高质量程序的行为，而不是提交质量一般但有良好态度去除错的行为。" 你这样的做法也是不理想的。作为领导，重在建立公平的标准。热心的程序员和沉默寡言的程序员都不应该得到领导的鼓励。我们鼓励的是统一的测试标准和发布流程。让质量不高的代码暴露出来，定期的回顾让“热心的程序员”知道自己的问题，并提供帮助让他们提高质量。另一个方面，“沉默寡言的程序员”要知道，程序员首先是一个社会的人，不善表达自己的程序员永远不太可能成为大师。最为领导，如果遇到就是“沉默寡言的程序员”，可以引导他把自己的想法写出来，让别人间接的接触他。如果这个，“沉默寡言的程序员”表达能力有问题，也不太可能写出高质量的代码。往往那些，“沉默寡言的程序员”也不见得代码不出问题。所以，你文中这样的观点，还是没有写的太透彻。
我在这里强调的不是态度的沉默和热心，而是提交质量的高下。
“如果期望打造有战斗力的团队，必须保证大家形成一致的工作习惯和价值观”
国内主要靠洗脑~~
也感觉国内技术实力和氛围不断变强，真高兴。
早就想买一本，请问重印版何时可以上市？
预计是两个月内吧，到时我发通知:)
Hi,现在还没有在市面上找到，是还没有上市吗？
是的，还没有上市呢
一直期望这书能有电子版上市。
我从事程序开发一年多，现在看到这篇文章关于技术人员的观点，感觉好有道理。
“在日常工作中，要持续表扬和鼓励沉默寡言但能提供高质量程序的行为，而不是提交质量一般但有良好态度去除错的行为。”
我很赞同这句话，技术的沉淀需要冷静的思考。频繁而热心的解决各种问题，实际带来的收益（无论是给自己还是给整个公司）并不多（至少不如看上去那么多）
沉默和热心不是重点，工作质量也不是重点，真正的重点是工作效率。假设让系统保持稳定的时间成本是 O(1)，不停修复的成本是 O(n)，当然选前者啊。但如果为达到前者而保证代码质量的成本是 O(n^2)，那就没必要坚持选前者。