一晃六年，《技术领导之路》要再版重印了。回想刚刚开始翻译这本书时，我还忙碌在程序开发的一线，对领导技术团队并没有太多经验；如今，也能差强人意地带领技术团队支撑年销售额数亿的业务。一路走来跌跌撞撞，所幸没有中途倒下。思考其中的原因，除去运气，除去身边同事朋友的支持，翻译《技术领导之路》也是不容忽视的因素。
很多人都知道，“职场童年”非常重要，一个人最初工作的几年，在什么样的环境里，得到过什么样的锻炼，很可能决定了他整个职业生涯的走向。同样的道理，“领导力童年”也很重要，一个人对领导力的最初接触和认知，也会深深影响他对于“领导”和“领导力”的观点，甚至领导作风。所以，在我还忙于一线开发的时候，通过翻译《技术领导之路》，“生吞活剥”了一整套关于领导力的学说，基本“塑造”了我关于领导力的认知，深深影响了我作为技术领导的管理风格和价值取向，因此也对很多问题有了自己的判断——前段时间和另一位掌管公司技术的朋友聊天，说起那种“执行力超至上”的领导风格，我们都认为，尽管或许能出结果，但不是好的领导风格。
怎样成为好的技术领导？《技术领导之路》的作者温伯格给出了一系列的答案。以技术人员的身份，我觉得最受用的几点是：通过写日记来加深自我认识，评估自己的能力应该用乘法而不是加法，从哪里寻找改进所需要的时间。
在生活中，我们大多会有一些自己的习惯和坚持，却习焉不察，没有去想过它们是否有道理。然而，如果需要不断改进自己，就必然需要不断观察和审视关于自己的一切，包括习焉不察的坚持。对此，温伯格给出的建议是，每天抽一点时间来写日记，不需要抒情，不需要感慨，忠实记录自己就好。开始我对此也有些怀疑，觉得写日记不过是小朋友过家家。但真正坚持之后才发现收获很大。因为静下心来写日记让我发现，在生活里，自己真正在乎什么，而不在乎什么。有一些东西我很在乎，但成长经历不同的人并不在乎，所以其他人并不是有意冒犯。还有一些东西我不在乎，却是某个人群特别在意的，考虑到其他人的感受，以后还是多加小心为好。
评估自己的能力“用乘法而不是加法”，可能初看起来不太容易理解，但也很好懂。人的能力通常是参差不齐的，有长处就必然有短处。要想成为好的技术人员，技术是不能“一俊遮百丑”的。以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 我所理解的技术领导力
之前我写了一篇《坚持了两年之后，小朋友突然不想去打冰球了…》，本来是无心之作，没想到收到了很多留言，我自己也获益不少。 本来，我以为解决了小朋友的问题，此事就这样过去了。没想到的是，暑假过后，冰球训练重开，他又老调重弹：“我不去了，我不想打冰球了……”。 这可叫我如何是好？听到他嘟嘟囔囔说这一切的时候，我心里百感交集。 成年人的生活里总是有忙不完的事情，对应的，也希望一切井井有条、按部就班。因此，这样“意外”的变数，总是第一时间让人心生无奈和烦恼：天哪，怎么会这样呢？为什么会这样呢？ 不过，基于之前的经验，借鉴大家的留言，这次我显然更有心理准备一些，起码不会慌乱。 之前我写过，如果父母多阅读一些高质量的育儿专著，有助于把自己的期望水平“降”到合适的程度，就不会那么焦虑甚至抓狂。 (more…)
认识Michael很偶然，但我也很幸运，因为我见证了一个“打冰球的好孩子”的成长。 最早认识Michael是在冰球队的夏季体能训练上。那时候这群孩子还只有六岁左右，每次训练都是家长送来，在旁边观看陪伴，再接回家。但是，我很快发现有个孩子不一样，家长送他来就回家，他靠自己换好全身装备，训练完自己洗澡更衣，再由家长接回去。看起来，他好像完全没有其他孩子那种“害怕独处”的感觉。 于是我问他：“小朋友，你这么勇敢，你叫什么名字呀？” 他说：Michael。 我尝试复述他的名字，好几遍都不成功，因为我总听成“米歇”，最后他耐着性子慢慢说，我仔细听才发现最后还有个音节，嘴要更扁一点，舌头往上垫，才可以念出来，类似“米歇-厄尔”。其实这个名字写出来大家都认识，英文里读作“迈克尔”，无奈德语的发音规则很严格，字母i不会像英文那样有两种读音，结尾的el又一定要发音，所以就成了“米歇-埃尔”。 (more…)
偶然刷到一篇文章，说的是“贵族家长”群体给小朋友安排的活动：冰球、马术…… 我有点诧异，原来“冰球”也被贴上了“身份”的标签。想想自家小朋友的情况：赶上打折花了400多欧元买的全套护具，80元买的二手冰球包，每个月60欧元的俱乐部费用……想了想，似乎很难和“贵族”联系起来。 只不过，他已经坚持打冰球到了第四年，我们的生活确实有不小的变化。写下来，既是对自己有个交代，也可以作为“贵族运动”的现身说法。因为在我看来，如果非要说它是“贵族”运动，也只能“贵”在高（时间）投入、高产出而已。细细想来，我们的生活，已经被冰球深深的影响了。 (more…)
一 很多人关心，我们父子给M写了道歉信之后，对方是否有回应。 答案是：到目前为止，还没有任何回应。不过比较特殊的是，写完信之后德国小学就开始放秋假，学生不用去学校，既然见不到，也就不可能收到任何回应。 老实说，我觉得对方父母是有点反应过度的。这些年我的一条深刻经验是，如果出现分歧、矛盾，越早、在越低的层面直接面对，就越容易解决。许多小的矛盾之所以越闹越大甚至无法收场，往往都是经过了很多演绎、传话，而没有在一开始就开诚布公地面对。 试想，如果自己的孩子收到写着“我要杀了你”的信件，哪怕一开始很惊慌甚至愤怒，但仔细想一想，毕竟还有很多信息是未知的——比如对方是谁，平时言行如何，为何要写这样的信…… 更好的办法或许是先去直接寻求这些问题的答案，而不是直接把信交给家长委员会，走“公事公办”的路子。 我当然承认，“公事公办”无可厚非，对方家长也有这样的权利——所谓权利，就是“有资格做对方不喜欢的事情，人家还拿你没办法”。既然有这样的权利，就需要尊重。 所以，“严于律己，宽于待人”的确是与人相处的重要法则：我不会选择这么做，但我能理解和尊重你这么做的权利。 也有人问，那将来你遇到M的父母，会不会紧张？ 答案是：不会。 (more…)
一 收到S老师邮件的时候，我刚刚胆战心惊地做完第一次德语技术分享，还在享受着同事们的鼓励。猛然间就收到一封邮件：“您的孩子在学校参与了一起性质严重的事件，您必须来学校面谈，请从以下时间段中选择……” 什么？“性质严重的事件”？我揉了揉眼睛，确认自己没有看错。再把这段文字贴到谷歌翻译里，确认自己没有理解错。 我没有看错，也没有理解错，就是“性质严重的事件”。好吧，既然“性质严重”，那谈话肯定是越早越好，最早的日期是第三天。我紧赶慢赶，回信确认了最早可能的谈话时间，虽然德国人通常都不期待能这么快收到回复。 去接他回来的路上，我发现他一切正常，完全看不出任何异样。于是，我也没有表现出任何异样，只是依照惯例，问他当天发生了什么，在学校开心不开心。 得到肯定的答复之后，我心生疑惑，看起来和“性质严重”完全不搭边。那会是什么事情呢？ 我又问他，有没有和同学吵架、打架，是不是被人欺负了不敢说。但是，答案全都是“没有”。 我满心怀疑，又按捺不住，直接问：“既然一切都挺好，为什么S老师给我发信，说让我来学校跟她谈话呢？”我担心“性质严重”会吓到他，故意隐去了这个词。 他的满面春风在那瞬间凝固了，喃喃低语道：“好吧，原来是那件事，我还以为她不会跟你说。” (more…)
在2024年之前，我从来没想过自己有一天还可以加入乐团，甚至参加音乐会演奏。我只是个普通中年人，在之前文章里说过，上世纪八十年代随大流弹了十年手风琴，考过六级（当时最高八级）之后就彻底放弃了。直到二十多年后，在上海工作时才重新开始弹琴，当时有幸跟夏老师学了两年，打开了感官，懂得了音乐的世界远远比考级要广阔和美妙。再往后，就是自己看Youtube学习了一些乐理知识。因为德国几乎每个城市都有很多音乐学校，2023年末，我给本市的音乐学校写信，询问是否可以参加手风琴课程。通过回信我才知道，原来不只是“每个城市都有很多音乐学校”，而且“每个城市都有很多乐团”，哪怕是手风琴乐团。就这样，阴差阳错的，2024年初，经过简单的试奏，我加入了本市的手风琴乐团。虽然我是乐团新人，仍然有很多要学习的，但是一年下来，确实有不少感受。如果读者朋友也对音乐感兴趣，或者想让孩子学习音乐，也许我的感受可以提供一些参考。 (more…)
View Comments
"在日常工作中，要持续表扬和鼓励沉默寡言但能提供高质量程序的行为，而不是提交质量一般但有良好态度去除错的行为。" 你这样的做法也是不理想的。作为领导，重在建立公平的标准。热心的程序员和沉默寡言的程序员都不应该得到领导的鼓励。我们鼓励的是统一的测试标准和发布流程。让质量不高的代码暴露出来，定期的回顾让“热心的程序员”知道自己的问题，并提供帮助让他们提高质量。另一个方面，“沉默寡言的程序员”要知道，程序员首先是一个社会的人，不善表达自己的程序员永远不太可能成为大师。最为领导，如果遇到就是“沉默寡言的程序员”，可以引导他把自己的想法写出来，让别人间接的接触他。如果这个，“沉默寡言的程序员”表达能力有问题，也不太可能写出高质量的代码。往往那些，“沉默寡言的程序员”也不见得代码不出问题。所以，你文中这样的观点，还是没有写的太透彻。
我在这里强调的不是态度的沉默和热心，而是提交质量的高下。
“如果期望打造有战斗力的团队，必须保证大家形成一致的工作习惯和价值观”
国内主要靠洗脑~~
也感觉国内技术实力和氛围不断变强，真高兴。
早就想买一本，请问重印版何时可以上市？
预计是两个月内吧，到时我发通知:)
Hi,现在还没有在市面上找到，是还没有上市吗？
是的，还没有上市呢
一直期望这书能有电子版上市。
我从事程序开发一年多，现在看到这篇文章关于技术人员的观点，感觉好有道理。
“在日常工作中，要持续表扬和鼓励沉默寡言但能提供高质量程序的行为，而不是提交质量一般但有良好态度去除错的行为。”
我很赞同这句话，技术的沉淀需要冷静的思考。频繁而热心的解决各种问题，实际带来的收益（无论是给自己还是给整个公司）并不多（至少不如看上去那么多）
沉默和热心不是重点，工作质量也不是重点，真正的重点是工作效率。假设让系统保持稳定的时间成本是 O(1)，不停修复的成本是 O(n)，当然选前者啊。但如果为达到前者而保证代码质量的成本是 O(n^2)，那就没必要坚持选前者。