一晃六年，《技术领导之路》要再版重印了。回想刚刚开始翻译这本书时，我还忙碌在程序开发的一线，对领导技术团队并没有太多经验；如今，也能差强人意地带领技术团队支撑年销售额数亿的业务。一路走来跌跌撞撞，所幸没有中途倒下。思考其中的原因，除去运气，除去身边同事朋友的支持，翻译《技术领导之路》也是不容忽视的因素。
很多人都知道，“职场童年”非常重要，一个人最初工作的几年，在什么样的环境里，得到过什么样的锻炼，很可能决定了他整个职业生涯的走向。同样的道理，“领导力童年”也很重要，一个人对领导力的最初接触和认知，也会深深影响他对于“领导”和“领导力”的观点，甚至领导作风。所以，在我还忙于一线开发的时候，通过翻译《技术领导之路》，“生吞活剥”了一整套关于领导力的学说，基本“塑造”了我关于领导力的认知，深深影响了我作为技术领导的管理风格和价值取向，因此也对很多问题有了自己的判断——前段时间和另一位掌管公司技术的朋友聊天，说起那种“执行力超至上”的领导风格，我们都认为，尽管或许能出结果，但不是好的领导风格。
怎样成为好的技术领导？《技术领导之路》的作者温伯格给出了一系列的答案。以技术人员的身份，我觉得最受用的几点是：通过写日记来加深自我认识，评估自己的能力应该用乘法而不是加法，从哪里寻找改进所需要的时间。
在生活中，我们大多会有一些自己的习惯和坚持，却习焉不察，没有去想过它们是否有道理。然而，如果需要不断改进自己，就必然需要不断观察和审视关于自己的一切，包括习焉不察的坚持。对此，温伯格给出的建议是，每天抽一点时间来写日记，不需要抒情，不需要感慨，忠实记录自己就好。开始我对此也有些怀疑，觉得写日记不过是小朋友过家家。但真正坚持之后才发现收获很大。因为静下心来写日记让我发现，在生活里，自己真正在乎什么，而不在乎什么。有一些东西我很在乎，但成长经历不同的人并不在乎，所以其他人并不是有意冒犯。还有一些东西我不在乎，却是某个人群特别在意的，考虑到其他人的感受，以后还是多加小心为好。
评估自己的能力“用乘法而不是加法”，可能初看起来不太容易理解，但也很好懂。人的能力通常是参差不齐的，有长处就必然有短处。要想成为好的技术人员，技术是不能“一俊遮百丑”的。以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 我所理解的技术领导力
在上一篇文章里，我列举了一些种族歧视现象的亲身经历，引发了许多读者的讨论。但是让我略感遗憾的是，许多人大概没有注意文章的标题，没有觉察到关键是“比想象的要复杂”，所以直接给出了一个简单的论断。 我的本意绝不是强化已有的简单粗疏的刻板印象，而是希望让大家知道，种族歧视这回事，有许多的侧面和细节。了解这些侧面和细节，有助于我们形成更立体的认知。 于是就有了下面这些内容，希望能引发大家的思考。 一 种族歧视是一种最简单粗暴的歧视。 许多人都知道，“歧视”的英文是discriminate，准确的意思是“区别对待”。既然要区别对待，就自然首先必须有办法区分。目力所及，似乎没有人愿意“区别对待”与自己完全同样的人，而总是要先找出一点区别来，再实行区别对待。 所以，种族、口音、家庭出身、经济能力等等各种因素，都可以成为“区别”的指标，由此催生出区别对待。在这些因素当中，种族大概是最容易识别的特征——判断口音需要等对方开口，家庭出身、经济能力等等因素就更是要全面接触才可能了解。唯有种族，具体来说，绝大多数时候是相貌和肤色，是可以远远一眼就望见的。 也恰恰是因为这个原因，种族歧视特别容易引起反感。 这些年来，我得到的一条重要的生活经验是，如果你希望指出对方的问题，但又不纯粹是为了激怒对方，那么最好不要归因为一些木已成舟，对方无法改变的因素，否则对方多半会恼羞成怒。 举个例子，你觉得某人的口语表达还可以更好一点，完全可以直接给出具体的建议。但是如果从“经济不发达地区来的人就是口语差”，或者“个子矮的人就是没自信心来表达”，那几乎一定会制造矛盾。因为“口语表达”是可以改进的，加以锻炼将来肯定更好，而“不发达地区来的人”和“个子矮的人”就像烙印一样，是无法摆脱的。这种话说出来，对方哪怕有意愿改进，也会觉得无奈甚至恼怒。 种族歧视也是这样，“种族”同样是一种烙印，是无法摆脱的。所以当对某些人的判断与种族挂钩的时候，他或她必然感到无奈甚至愤怒。况且老话说“人上一百，形形色色；人上一万，千奇百怪”。哪怕是同一个种族的人，也可能在肤色、相貌之外完全找不到相同点。先入为主地用种族去对其他人下判断，无论是从情感反应上，还是从逻辑上，都是站不住脚的。 (more…)
去年初的时候，小朋友冰球俱乐部来了个新教练Robo。Robo来自加拿大，总是一副很健谈很乐观的样子，而且很喜欢放音乐，把整个训练场搞得热情四射。最关键的是，小朋友们好像都很喜欢他，不但许多动作耐心示范，对每个人的指导也相当到位。而且，他的英语很好，人又很喜欢开玩笑，所以我们交谈很多，他总是跟我说：“你家的小朋友超级酷的，不要给他太大压力，只要他自己运动起来足够自在，能够持续练下去，就是最好的。” 没想到的是，到去年9月份，Robo忽然神秘失踪了，没有任何征兆，也没有任何说明，就此人间蒸发了一般。问其他的教练，也是语焉不详。小朋友训练完，偶尔会失落地跟我说“好久没看到Robo了，不知道他哪里去了。” 3月份的时候，一个偶然的机会，我又见到了Robo，虽然当时时间很紧张，只是打了个照面，但我要他留下了联系方式。 当天晚上我问他：哥们，你怎么忽然就不见了，大家都很想你啊。 过会儿我收到他的回复：我也很想念小孩子们，你儿子很酷……我现在没在那个俱乐部了，因为其他几个教练总是或明或暗地针对我，仅仅因为我的肤色，这是我受不了的。 (more…)
注：原文发布于2023年1月16日 到1月份为止，我已经体验了几个月的全远程+共享空间办公了。有不少朋友听说之后很有兴趣，问我到底是什么感觉，所以我简单介绍下个人的体验。 背景 2019年末、2020年初开始在全球流行的Covid-19对远程办公来说，绝对是黑天鹅一般的存在。因为疫情导致的社交隔离措施，极大影响了各大公司的正常运转。 所幸，IT类公司受到的影响比较小，只要求员工“面对屏幕编程”，不必亲临现场。所以，许多IT公司也谨小慎微地开展了远程办公的试验。 从我所知道的结果来看，不少美国公司并不特别喜欢远程办公，比如Google，一旦社交隔离措施有所放松，就忙不迭要求员工回到办公室，盖因为公司认为远程办公严重影响合作效率。 与此相反，不少德国公司反倒是逐渐适应了远程办公的节奏，纷纷降低对员工“到办公室上班”的要求，许多公司甚至可以支持百分百的远程办公。 这里要提到的是，德国公司说的“远程办公”往往是货真价实的“远程”，而不是一些人理解的“家和办公室在同一个城市，只是不用去办公室”而已。 因为德国IT行业缺人严重，而且许多德国公司并没有那么“互联网”，而是依托实业开展业务，所以据我所知，目前不少公司非但没有裁员，反而都在大力招人。 (more…)
注：本文发布于2023年2月6日 最近硅谷几大公司都在裁员，看了些报道，被裁的员工真是不好过。损失经济来源不说，有些人还面临身份问题，这可真是屋漏偏逢连夜雨。 我也留意到，不少被裁的人会不停追问自己：为什么我会遇到这样的事情？为什么这样的不幸会降临到我头上？…… 实话说，我挺能理解这种态度。这挫折如此巨大，似乎又来得全无预兆，不由得让人对命运、对人生、对世界产生深重的怀疑。尤其是对已经走入社会，取得一定成就（如果非要抠字眼，那就用“进展”吧）的人来说，更是如此。 但是我更想说，如果被裁员了，当务之急是赶紧找到下一份工作，哪怕只是机械地行动。要知道，成年人找工作，容不下那么多愁善感。 我之所以这么说，是有切身经历为基础的。之前我讲过找德国工作的经历。最开始是信心十足的，因为虽然毕业多年，手艺没丢，基础还在，随时打开leetcode，中等难度题目基本都不在话下，不但能解对，解法也基本接近最优。既然网上都说“刷题就能找到工作”，估计自己应该没大问题。 没想到真的找起工作来，仍然充满了意想不到的挫折。如果不相信，我且举几个例子吧。 (more…)
虽然早就听说《园丁与木匠》是关于育儿的好书，但一直没开始读。最近终于翻开这本书，才发现属于“拿起就很难放下”的类型，加班加点读完，收获不少。 关于这本书的价值，已经有许多书评讨论过了，所以我想略过微言大义、长篇大论的叙述，谈谈我印象最深，也是最打动我的三点细节。 第一，儿童的学习方式 小孩子觉得拧螺丝很好玩，想自己动手拧一颗螺丝。于是，他打开了工具箱，对着琳琅满目的工具，他不知所措。一会儿摸摸钳子，一会儿试试扳手……这时候，旁边的父母应当怎么办？ 在大多数情况下，父母大概会直接告诉孩子，“亲爱的，你应该用螺丝刀，来，我告诉你”。耐心一点的父母，大概会潜心观察一段孩子的举动，再设法“引导”他到正确的工具上来。在父母眼里，孩子当然不可能一开始就找对正确答案，所以做各种尝试也是情有可原。但是另一方面，也不应该“在错误的路径上摸索太久，浪费时间”，应当“迅速识别出正确的答案”。 无论父母有多少耐心，在他们眼里，孩子找到拧螺丝的工具的过程，都是个“不断接近正确答案”的过程。这个过程越短，孩子就越“聪明”，或者说“学习效率”就越高。 (more…)
陈皓（Haoel，网名“左耳朵耗子”）上周六因为突发心梗去世了，享年47岁。 我跟他虽然聊过好些次，但只是微信好友，从未见过面。回看微信记录，当年稀松平常的一声“再见”，已经成了“再也不见”。 许多人在缅怀他，许多文章提到他的时候，会用到“骨灰级程序员”、“技术大牛”这样的称呼。但如果仅仅用这两个词描述他，断然难以解释，为什么他的突然去世，会引发互联网上怀念的狂潮。 所以，我更愿意按照自己的经验，把他描绘为“有坦诚追求，兼具趣味、操守、胸怀的技术人”。恰恰是因为这样的人在这个年代太稀少，而这些品质又让众多人赏识和受益，大家才会如此地怀念他。 这个年代，做技术（仅指狭义的IT）的人很多，愿意分享的人也不在少数，其中不少还可以算世俗意义上的“成功者”。 但是，若仔细去看他们分享的内容，总感觉不够真诚。总感觉作者希望往高深了靠，目的也没有那么纯粹。你若提一些小白问题，迎来的往往是“你怎么连这都不知道？”的反问，或者“要谈这个问题，你先去看几本书再说吧”。话是这么说没错，但无数的初学者也往往因此打了退堂鼓。 但是陈皓的分享不同。我已经不止一次地看到有人提起，他分享——更准确说，是“创作”——的内容质量很高，而且总能做到“深入浅出”。哪怕是小白读者，看完也确实能有收获，如果还有兴趣，更可以跟着文末的链接，顺藤摸瓜探究更广阔的世界。 这让我想起我佩服的一位记者说的：记者写文章的最高境界，就是不表达自己的观点，因为记者的观点应当来自于他的素材。只要把这些素材摆出来，读者读完报道，观点就自然形成了。要做到这一点，需要对素材有足够的信心和把握，外加真诚和坦荡。 能做到这一点的记者，着实不多。陈皓虽然不是记者，他写的技术文章却能让读者得到类似的结论——要知道，技术讨论往往是非常容易擦枪走火的——可见他运用素材和逻辑的功力，以及更重要的，他的真诚和坦荡。 (more…)
View Comments
"在日常工作中，要持续表扬和鼓励沉默寡言但能提供高质量程序的行为，而不是提交质量一般但有良好态度去除错的行为。" 你这样的做法也是不理想的。作为领导，重在建立公平的标准。热心的程序员和沉默寡言的程序员都不应该得到领导的鼓励。我们鼓励的是统一的测试标准和发布流程。让质量不高的代码暴露出来，定期的回顾让“热心的程序员”知道自己的问题，并提供帮助让他们提高质量。另一个方面，“沉默寡言的程序员”要知道，程序员首先是一个社会的人，不善表达自己的程序员永远不太可能成为大师。最为领导，如果遇到就是“沉默寡言的程序员”，可以引导他把自己的想法写出来，让别人间接的接触他。如果这个，“沉默寡言的程序员”表达能力有问题，也不太可能写出高质量的代码。往往那些，“沉默寡言的程序员”也不见得代码不出问题。所以，你文中这样的观点，还是没有写的太透彻。
我在这里强调的不是态度的沉默和热心，而是提交质量的高下。
“如果期望打造有战斗力的团队，必须保证大家形成一致的工作习惯和价值观”
国内主要靠洗脑~~
也感觉国内技术实力和氛围不断变强，真高兴。
早就想买一本，请问重印版何时可以上市？
预计是两个月内吧，到时我发通知:)
Hi,现在还没有在市面上找到，是还没有上市吗？
是的，还没有上市呢
一直期望这书能有电子版上市。
我从事程序开发一年多，现在看到这篇文章关于技术人员的观点，感觉好有道理。
“在日常工作中，要持续表扬和鼓励沉默寡言但能提供高质量程序的行为，而不是提交质量一般但有良好态度去除错的行为。”
我很赞同这句话，技术的沉淀需要冷静的思考。频繁而热心的解决各种问题，实际带来的收益（无论是给自己还是给整个公司）并不多（至少不如看上去那么多）
沉默和热心不是重点，工作质量也不是重点，真正的重点是工作效率。假设让系统保持稳定的时间成本是 O(1)，不停修复的成本是 O(n)，当然选前者啊。但如果为达到前者而保证代码质量的成本是 O(n^2)，那就没必要坚持选前者。