技术领导要不要写代码？这是一个问题。 我刚工作的时候就听说，程序员(那时候还没有“码农”的说法)是吃青春饭的，到30岁就熬不了夜写不动代码了，所以要尽早转管理岗。相应的，如果你走上管理路线成了技术领导，自然就不必干写代码这种低级重复的体力劳动了。所以当时自己代码写得很多，技术能力增长很快，但总感觉有点别扭。那感觉就像，你能把车开得又快又熟练，最终只是为了能按时到达机场赶上飞机。然后，你就再也不用开车了。 不过无论如何，赶上飞机看来是更高级的选择，为了它，放弃苦心修炼的车技也可以接受罢。
对程序员来说，学好“英语”而不是“专业英语”是非常重要的。只学好专业英语，看得了技术文档，但那一大堆专业术语和概念可能会像陨石一样，没来由地坠落下来，只能生吞活剥地硬背。如果学好英语，你才会有融会贯通的感觉，知道那些术语和概念原来是从地里长出来的，底下连着根茎。
我刚刚工作的时候，面试官曾经跟我说：好好干两年，可以迅速从程序员成长为工程师。当时我觉得太诧异了，从很多招聘启示来看，“程序员”不就等于“工程师”吗，只是“工程师”更好听一些而已。等我工作久了，才知道“程序员”和“工程师”真的是不一样的——程序员只写程序，工程师写能在现实世界中创造价值的程序。 可惜，很多软件开发人员未必清楚两者的差别，甚至做了很久也只算程序员而不算严格意义上的工程师。所以我就自己的观察和经验，谈谈程序员和工程师的差别。 第一，工程师不写黑箱程序。 “程序=数据结构+算法”，这个著名的公式大家都知道，不幸的是，它不适合描述工程领域或者现实世界的程序。有很多程序，数据结构和算法都写得很棒，功能足够强大，系统足够复杂，但是——它很难调试，一跑起来就无法停止，而且谁也不知道程序现在到底在干什么，里面发生了什么。
对程序员来说，学好“英语”而不是“专业英语”是非常重要的。只学好专业英语，看得了技术文档，但那一大堆专业术语和概念可能会像陨石一样，没来由地坠落下来，只能生吞活剥地硬背。如果学好英语，你才会有融会贯通的感觉，知道那些术语和概念原来是从地里长出来的，底下连着根茎。
我有时会帮朋友们做些工作引荐，所以经常见到一种可惜的情况：有些人明明素质很好、专业很过硬、经验很丰富，偏偏简历做得太过敷衍潦草，一眼看去泯然众人、毫无亮点，甚至让希望引荐的我感到汗颜。看来，有必要认真谈谈简历这件事情。
就我所见，把原有系统“推倒重来”的喜好不只程序员有，使用者更有。拿我几年前的那份工作来说，刚入职老大们就来跟我讨论系统重做的打算：需要多少人，多少钱，多长时间，能把原有系统推翻重来。毕竟大家每天都忍受切肤之痛：速度慢、经常出错、不安全、客户抱怨、架构糟糕…… 所以都想拿出“敢叫日月换新天”的劲头，来个干脆的彻底解决。
人的一生，当然有很多的时间去自己摸索和探究，做出自己的选择；其他人的教诲，很多时候并不会干涉选择，反而会让人少走弯路，更快捷抵达自己的目标。下面，我列了自己印象深刻的教诲（或者说“建议”），既是对各位的感谢，也希望通过分享让更多人受益。
在超市结帐的时候，收银员都会给我们打一张小票。有时候同样的商品我们会买两三件，打印在小票上面，有时候只有1行记录，数量是3，但也有时候有3行记录，数量都是1。这个现象很有意思，也引起了我的兴趣。据我观察，后一种情况明显更多。分明是前一种做法更节省纸张，为什么更少采用呢？ 我曾经设想，是因为收银的机器性能太差，内存很少，只能维护简单的数组结构，不能维护集合，也不能每添加一样商品就去重新扫描一次数组做修改。但是继续观察就会发现，这个说法站不住脚——现代的收银机性能足够很好了，甚至手机的性能都在突飞猛进。那么这么做的原因到底在哪里呢？就在我百思不得其解之际，一个偶然的机会解开了我的疑惑。
2011年前我写过一篇文章，讲到自己发现的两大趋势：第一是人与人之间的沟通越来越少地采用“同步”（电话）的方式，而更多采用“异步”（邮件、短信等，当时还没有微信）；第二是有越来越多的人“实名上网”，不一定用自己的真名，但是希望在网络上建立通行的“身份”。当时我也好奇：随着时代的发展，我们的生活还会发生哪些变化？ 后来我才逐渐认识到，这些变化都只是表象，实质是两个字：互联。
抱着了解的心态，我第一次来到了张江，参加了一次创新院的计委会例会(计划委员会？)。后来我才知道，这个会议定期召开，对内部和外部的项目进行点评，参会者包括固定成员和报名参加的创新院员工，大家都可以畅所欲言。如果说非要有什么等级的话，大概就是把最后的点评机会留给创新院的院长大年(陈大年)，他的点评没有咄咄逼人的气势，而多是以温和的方式托出自己的思考，大多数时候都让大家信服。相比小公司的会议，设施更好，准备更充分，也更严格；相比大公司的会议，少了仪式感和官僚气，多了活力。结果，2010年3月我加入了创新院。
“丰田生产方式”给我印象最深的要求是，员工必须同时对工作和工艺负责。自从福特发明了“流水线”之后，工人似乎成了机器的附庸，只是完成机器暂时无法完成的工作。生产的终极形态，就是把一切工作变成简单重复劳动，用机器执行。所以，工人的工作也应该简单机械，比如每天按照生产线的运作，以一定节奏拧紧某个螺丝，就是一种典型。而在丰田生产方式下，工人不但要完成简单机械的本职工作，还必须对工艺负责，也就是理解该工作的意义，思考并不断思考改进自己的工作过程——他们既有这个义务，也有这个权力。结果，整条生产线就好像具备了不断改进的活力，而不再由少数专职的“专家”负责优化(实际上专家也负不了那么多责任)。
程序员的发展，长期以来都是大家关心的问题。通常程序员的发展有两大方向，深度和广度。深度发展，就是精深自己的本事，研习新潮尖端的技术乃至学会“屠龙之术”，以绝招打遍天下；广度发展，就是拓宽自己的技能种类，比如学会更多的语言，以完成更多种类的任务。除去这两大方向，其它能选的发展方向似乎就只有“改行”了。
上周五到周日，72小时内连续参加了北大、武大两场校园招聘会，笔试面试了一百多位同学。见到很多很不错的同学，在学校里就积累了相当的见识和经验，也见到很多很可惜的同学，因为这样那样的问题，没有走完招聘流程。下面我结合公司的校园招聘安排，给各位找工作的同学一点建议。
上周在深圳见朋友，聊天时仍然把“正则表达式”和我联系在一起，这真让人惭愧，因为我已经很久不写正则表达式了，甚至有些生疏。估计是Jeffrey Fridel的《精通正则表达式》写得太好，身为译者的我也沾了不少光，收获不少虚名。为避免误解，撇去虚名，有必要专门写写我和正则表达式的故事。
最近因为工作的缘故，接触了TokuMX，尝试下来感觉不错，值得介绍给大家。 事情的起因是要解决MongoDB的问题。系统中需要保存程序输出的运行信息，这类信息比程序语言的log更高级，但又不如业务操作日志高级，是某些时候发现问题的关键证据，所以必须保存。因为格式不太规范，又需要方便检索，所以文档型NoSQL的MongoDB是比较好的选择。
TokuMX的一大创新在于，它打破了一条长久存在的关于数据库的规则：要保证好的写入性能，索引的工作集应当能够放在内存里。标准答案是这样的：如果索引的工作集比内存要大，写入就需要执行I/O，I/O就会成为限制因素，性能就会下降。所以，要么让索引小到能全部放进内存，要么提供一种索引写入模式，避免工作集过大，比如MongoDB所采用的，内存中只为最近插入的数据保存索引。
领导必须更懂技术吗？这是个问题。做了领导以后，因为工作的关系，许多人都不那么熟悉基础的技术了，结果自己心里没底，更怕遇到问题时在下属面前丢脸。所以，有些人选择了双管齐下——既不放弃领导的工作，又不放弃原有的技能，结果疲惫不堪。还有人干脆选择不当领导了，因为有手艺，才有安全感。
不少朋友都提到，手下的员工离职往往是让人非常头痛的事情。这大概是管理岗位经常需要面对的一种麻烦，这个问题也困扰过我。为了帮助仍然被困扰的各位同仁，下面提供我的经验给大家参考。要说明的是，因为我和朋友们几乎都在IT行业，“员工离职”的大部分情况也就直接体现为“程序员离职”，所以我主要讲的还是应对程序员离职的经验，其它行业的朋友可以自行参考。
说起翻译，许多人都有兴趣。但真正能动手去尝试的人，只占其中的一小半；能熬过尝试阶段的煎熬，真正入门的人，更是少之又少。这种现象给不少人造成了错觉，认为翻译是件看起来容易做起来难的事情。但是根据我自己的经历和其它做译友的反馈，这话其实只说对了一半，翻译“做起来”并没有那么难。翻译之所以给人“做起来难”的感觉，很大程度上是难在入门阶段，难在一些基本问题没有解决。所以，这篇文章来谈谈大家关心的两个基本问题：第一，翻译是怎样的工作；第二，直译更好还是意译更好。
读了本文如果有人觉得这还不满足，希望知道程序员有了产品意识还有什么别的好处？且让我讲个故事：我有个做金融的朋友，从小参加过不少信息奥赛培训，业余也自己写过不少小工具。有一天他问我：“你说程序员的工作有那么高级吗？不就是写写代码？你看我也会不少编程语言，也写过不少程序，所以程序员没什么了不起的吧。”我回答：“那么，你有没有写过给别人用的程序呢？”他想了一会儿说：“好吧，你赢了。”
