技术领导要不要写代码？这是一个问题。
我刚工作的时候就听说，程序员（那时候还没有“码农”的说法）是吃青春饭的，到30岁就熬不了夜写不动代码了，所以要尽早转管理岗。相应的，如果你走上管理路线成了技术领导，自然就不必干写代码这种低级重复的体力劳动了。所以当时自己代码写得很多，技术能力增长很快，但总感觉有点别扭。那感觉就像，你能把车开得又快又熟练，最终只是为了能按时到达机场赶上飞机。然后，你就再也不用开车了。
不过无论如何，赶上飞机看来是更高级的选择，为了它，放弃苦心修炼的车技也可以接受罢。
但是等我真正走上管理岗位，才发现事实和我想的完全不一样。当时公司的业务增长飞快，支持业务的系统却是几年前“一锤子买卖”的外包项目，更要命的是技术团队的人员组成和工作习惯还处在作坊状态。从我的角度来看，四下里全是大坑，填坑的速度慢得让人着急，在此过程中还经常挖下新坑…… 在我的职业生涯中，我从没有在那么短的时间里写过那么多代码。几年后大家查提交排名，我的名字仍然第一。好在我的努力没有白费，系统终于没有垮掉，顺利回到正轨。
当时我身为技术领导，除去招人、定流程、做运维，还花了大量时间写代码，这样的做法是对的吗？如果是对的，后来我再没有写过那么多代码，好像也与“不称职的领导”无缘，甚至还被夸奖过“忍住放手让下属去做事，锻炼了组织”，这又是怎么回事呢？
Continue reading 技术领导要不要写代码？
时常与一些同行朋友说起“软件难做”的话题，一方面软件确实挺难做，变数着实太多（推荐《梦断代码》），另一方面，让人理解软件难做，更是不容易的事情。如果说第一个问题靠苦练内功还能看到希望，第二个问题就近似无解而让人绝望了。下面两个场景，相信大家都不陌生：
头儿说：你们开发怎么这么慢？拿这么高的薪水，做事还这么慢？我急得不得了，只可惜我不懂开发。我如果懂，我去学校招50个码农，连续熬夜一两个礼拜，绝对可以做出我想要的系统。
头儿说：我真是对系统失望透顶了。想我以前刚创业的时候，七八个人，五六台电脑，什么事都是靠喊，那时候工作效率多高，人均产值多高？现在人才到几百个，就成了这个鬼样，说要上系统，上了系统有变好吗……
我有时候会想，这些说法在普通人看来似乎也没有错，但行业中人都知道错得厉害。那么，问题究竟出现在哪里呢？我想来想去，觉得原因大概在于，持这样说法的人往往只依靠来自生活经验的“逻辑”和“直觉”，还没有真正理解“软件”（或者说“系统”）到底是怎么一回事。
Continue reading 从静不稳定设计说起
上个月，有个以前的同事问我：“你在的时候，为什么不把原来的系统都重做了，我们明明有实力啊”。
我说：“我们也做了很多事情嘛，系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。”
他说：“对，但我还是想知道，你为什么不把系统重做了呢？”
于是我问：“我离职之后，后来似乎多投了不少人重做系统？结果怎么样呢？”
他说：“结果，结果就是做业务要同时操作三四套系统……”
就我所见，把原有系统“推倒重来”的喜好不只程序员有，使用者更有。拿我几年前的那份工作来说，刚入职老大们就来跟我讨论系统重做的打算：需要多少人，多少钱，多长时间，能把原有系统推翻重来。毕竟大家每天都忍受切肤之痛：速度慢、经常出错、不安全、客户抱怨、架构糟糕…… 所以都想拿出“敢叫日月换新天”的劲头，来个干脆的彻底解决。
这种心情可以理解，但在我任内“重做系统”一直没有被提上日程，整个技术团队所做的都是“改良”的工作，内容就像我上面说的：系统稳定性、安全性、增加冗余、理清各模块职责、API通讯机制的建立、内部分层的整理。这个选择我有充分把握，而且在我看来，如果断然“推倒重来”，我未必能比继任者做得更好，甚至可能更糟糕，因为“推倒重来”绝不是那么简单的事情。
Continue reading “推倒重来”的讲究
在我上大学的时候，除去普通的英语课程，专业课程里还有一门《计算机英语》。当时大家的普遍认为，普通的“英语”是过四六级用的，《计算机英语》才是专业真正需要的。
等到工作了，我发现很多人都持这样的观点：程序员应该学好英语。这样才能方便地查找资料，迅速地学习最新的知识。换句话说，“学好英语”在很多人看来，就是是“学好专业英语”——这项要求已经很高了，我曾经在《程序员要怎样学英语》里提到，不但要能看懂文档，还要知道“黑屏”是blank screen，“死机”是system halt，否则查找就会很费力。
但是今天我想强调的是，对程序员来说，学好“英语”而不是“专业英语”是非常重要的。只学好专业英语，看得了技术文档，但那一大堆专业术语和概念可能会像陨石一样，没来由地坠落下来，只能生吞活剥地硬背。如果学好英语，你才会有融会贯通的感觉，知道那些术语和概念原来是从地里长出来的，底下连着根茎。
Continue reading 程序员为什么要学好英语
在超市结帐的时候，收银员都会给我们打一张小票。有时候同样的商品我们会买两三件，打印在小票上面，有时候只有1行记录，数量是3（“听装百事可乐 x3”），但也有时候有3行记录，数量都是1（“听装百事可乐 x1” 重复3行）。这个现象很有意思，為什麼不统一呢？而且据我观察，后一种情况明显更多。分明是前一种做法更节省纸张，为什么更少采用呢？
我曾经设想，是因为收银的机器性能太差，内存很少，只能维护简单的数组结构，不能维护集合，也不能每添加一样商品就去重新扫描一次数组做修改。但是继续观察就会发现，这个说法站不住脚——现代的收银机性能足够很好了，甚至手机的性能都在突飞猛进。那么这么做的原因到底在哪里呢？就在我百思不得其解之际，一个偶然的机会解开了我的疑惑。
Continue reading 软件开发的硬约束
很多初上管理岗位的人都听过这样一条教诲：“公开表扬，私下批评”。而且，很多有管理经验的人也是这么做的。理由很简单：公开表扬能给人鼓励，催人继续，私下批评给人留了面子，减少副作用。但是，它真的是一条应当时刻遵守的行为规则吗？
不妨看两个例子：某人表现不好，主管与他谈话之后有了一点改进的苗头，做事能“及格”了，看来应该鼓励，所以主管公开表扬，可是其它人明明做了更大贡献，却没有得到表扬；某人搞砸了工作，造成整个团队加班为他补救，然而主管只是私下批评，所以有人觉得不公平，这是主管在有意袒护。
很明显，这两个例子里的“公开表扬，私下批评”并不是合适的做法，反而造成了新的矛盾。那么，问题究竟出在哪里呢？表扬和批评，到底应该在什么情况下公开进行，什么情况下私下进行呢？
Continue reading 公开表扬，私下批评？
一晃六年，《技术领导之路》要再版重印了。回想刚刚开始翻译这本书时，我还忙碌在程序开发的一线，对领导技术团队并没有太多经验；如今，也能差强人意地带领技术团队支撑年销售额数亿的业务。一路走来跌跌撞撞，所幸没有中途倒下。思考其中的原因，除去运气，除去身边同事朋友的支持，翻译《技术领导之路》也是不容忽视的因素。
很多人都知道，“职场童年”非常重要，一个人最初工作的几年，在什么样的环境里，得到过什么样的锻炼，很可能决定了他整个职业生涯的走向。同样的道理，“领导力童年”也很重要，一个人对领导力的最初接触和认知，也会深深影响他对于“领导”和“领导力”的观点，甚至领导作风。所以，在我还忙于一线开发的时候，通过翻译《技术领导之路》，“生吞活剥”了一整套关于领导力的学说，基本“塑造”了我关于领导力的认知，深深影响了我作为技术领导的管理风格和价值取向，因此也对很多问题有了自己的判断——前段时间和另一位掌管公司技术的朋友聊天，说起那种“执行力超至上”的领导风格，我们都认为，尽管或许能出结果，但不是好的领导风格。
Continue reading 我所理解的技术领导力
最近因为工作的缘故，接触了TokuMX，尝试下来感觉不错，值得介绍给大家。
事情的起因是要解决MongoDB的问题。系统中需要保存程序输出的运行信息，这类信息比程序语言的log更高级，但又不如业务操作日志高级，是某些时候发现问题的关键证据，所以必须保存。因为格式不太规范，又需要方便检索，所以文档型NoSQL的MongoDB是比较好的选择。
但是，选择MongoDB就必然会面对磁盘空间的问题。我们的数据大概是这样的：每天的数据量不到200万条，单条数据的平均大小不超过4k，但MongoDB存一个月的数据就消耗了接近40G，最近三个月的数据则需要接近100G。限于具体的硬件环境，只能保存最近三个月的数据，但这无法满足业务需求，所以必须另想办法。
Continue reading TokuMX使用小计
不再从事单纯的程序开发，而是介入和管理公司的IT工作之后，我遇到了许多新的问题，对许多旧问题也有了新的视角和理解。无可否认的是，在大多数公司，IT工作的管理都不是简单的工作，状况层出不穷，而且似乎没有能直接拿来用的解决方案。一面是千头万续，一面是束手无策。为什么会这样呢？原因之一大概是，很多人没有意识到：IT是种资源。
IT是一种资源，首先意味着它不是成本。
在很多场合，IT被视为支持部门，但将其视为成本，思路就自然会想到“降低成本”，而将其视为资源，则会从“发挥价值”来考虑。所以在很多偏实业的公司里，并没有严格意义上的IT预算，他们更习惯一次性花钱去购买系统，并培训人员学会使用，然后就是一了百了。在它们看来，养IT的“成本”是相当高的。
如果换个角度，设定专门的IT预算，要求这笔投入得到更大的回报，就可以看到甚至把握住许多其它的机会，比如内部操作和流程的优化，比如对外业务交互的便利。尤其是在今天，“互联网思维”已经到处弥漫，各产业的生态都在不断演变，一门心思想着降低IT成本，固守封闭系统的企业很可能错失大好机会，甚至被产业发展所淘汰。这不是说笑，而是活生生的例子，现在许多制造型企业也想搭上电商的快车，掌握更多的主动权，但因为长期忽略IT建设，根本无法进行数据对接，只能望洋兴叹。
Continue reading IT是种资源
说起API，做开发的人大概都知道也用过，我也是如此。不过除去使用，我还亲眼目睹过API制定，参与搭建过开放API平台，也与合作方商量确定过API方案；算是各个方面都有了解和经历，感受过让人啧啧称奇的赞赏，也经历过举步维艰的尴尬。目睹还有很多同行在API的泥泞里挣扎，我把自己的经验写在这里与大家分享。
大家都知道，API是Application Program Interface，也就是应用程序接口，看起来非常容易理解，实际却并非如此。据我观察，不少API方案之所以陷入了泥潭，就是程序员对API理解错误，把它看成了“对外开放的函数”：某个动作可能之前需要用户鼠标点击触发，现在开个口子给程序用消息触发，这就是API了；推广开来，现在流行的API化、开放平台的潮流，无非是多开一些这样的口子而已。
Continue reading 迷失自我的API