算起来，我从互联网开发投身企业开发已经有四年多时间了。刚刚进入企业开发领域时心里很是忐忑，虽然也读过《企业应用架构模式》之类的书，到底没有做过正经的“企业开发”，好在业务不算太复杂，所以更多是借着之前互联网开发的老底子解决问题。而且，这么做确实能解决问题，只是心里还不太放心，总觉得这不是名正言顺的“企业开发”，以后会有问题。
谈到传统的企业开发，大家通常想到的是“为明确目标（通常由甲方设定）而开发的紧耦合固定系统”，主要元素包括重型框架、长发布周期、严格的限制、海量的文档、对商用软件的倚重等等。谈到互联网开发，大家通常想到的是“为不明确或多变目标而开发的松散多变系统”，主要元素包括轻量类库、迅速迭代、不断试错、简单交流、开源/免费软件的广泛使用。传统上，企业开发和互联网开发俨然两派，你觉得我是杂乱无章的恣意胡闹，我觉得你是傻大笨粗的因循守旧，好在双方“井水不犯河水”，也相安无事。
企业开发和互联网开发的这种区别，让我在以互联网开发的方式应对企业开发任务时，始终有挥之不去的担忧。然而工作得越久，事实却不断证明这种担忧是多余的，或者至少不必高估“企业开发”的正统性。而且，有越来越多的迹象让我相信，企业开发的互联网转向，即在企业开发中越来越多地采用互联网开发的方法，是未来的趋势。按照我的总结，原因大致有以下几点。
Continue reading 企业开发的互联网转型
上周在深圳见朋友，聊天时仍然把“正则表达式”和我联系在一起，这真让人惭愧，因为我已经很久不写正则表达式了，甚至有些生疏。估计是Jeffrey Fridel的《精通正则表达式》写得太好，身为译者的我也沾了不少光，收获不少虚名。为避免误解，撇去虚名，有必要专门写写我和正则表达式的故事。
我和正则表达式的缘份，始于我的第一份工作。那时我刚刚离开学校，除了在学校里认真写过些程序实现书上的理论和练习，根本没做过实际的项目。找工作当然也不顺利，尤其不是北京的高校毕业，在北京找工作更加困难。好不容易找到一家公司愿意收留我，周四上午面试、下午复试、周五就签合同，通知“下周一来上班”了。
我清楚地记得，上班的第一天，为了不让其他人看穿自己其实没有项目经验，我特意带了那本厚厚的影印版《the Java Programming Language》，一来充门面，二来也抱抱佛脚，之前在学校写的都是C++程序，Java确实不熟悉。而且，上午确实没太多事情干，这本书救了我的命。
好日子在下午就到了头，项目经理给我们做培训。当我满心欢喜地参加培训，希望通过培训来“软着陆”时，等来的却是高强度的信息轰炸：一小时内讲完了JBuilder、JUnit、Ant三样东西，我完全没有接触过，但公司要求“明天就开始使用”。读书时虽然不排斥学习新的知识，毕竟习惯“循序渐进”，这种“培训”闻所未闻，结束之后只觉得大脑一片混沌。在QQ向同学吐槽说“公司这么不讲道理，纯粹血汗工厂”，答复却出乎我的意料：“赚翻了，赶紧学，我们想用还不让用呢”。在当时，被“堵”的感觉特别糟糕，但转念一想，这么说也有道理，所以我拼命忍住反感，硬着头皮学习。
Continue reading 纯属偶然——我和正则表达式的缘份
工作是在大公司更好，还是小公司更好？这个问题让大家争论不休，也没有最终的答案。凑个热闹，我结合自己的经历，谈谈我的看法。
我最开始工作就是在小公司。当时刚刚毕业，在对工作完全没有概念的情况下，进入了一家小的创业公司。虽然今天想起来，作为创业公司，它有这样那样的不足，但我依然非常珍惜那段经历。主要原因是，虽然在创业公司，我仍然受到了相对良好的职业训练。当时我的两位领导都是毕业于清华，而且在搜狐工作过的，有丰富经验的IT人员。所以我最初工作的两个月，几乎是每天在批评中度过的。虽然我在学校也认真写过一些程序，但还是每天被批得一无是处，因为学生写的程序，距离生产系统要求的工业级别，实在是差得太远了。所幸自己当时脸皮厚，被批了就赶紧改，根本不去想太多，这样过了两个月，终于没那么少被批评了。当然，另一方面是因为我受到的批评都是“对事不对人”的，所以一直没有“人格被否定”的糟糕感觉。
第一份工作我做了一年多，最大的收获是在领导持续的严厉批评下，深刻认识到了“现实生产环境需要的程序是什么样的”，其次就是模糊地领悟到，持续的“对事不对人”的批评，可以营造出追求专业进步的价值观。现在回头去看，很多人即便进到大公司，受到各种条框的限制，也不见得理解这些约束的意义；加之，如果领导没有严格的要求，没有树立“工作至上”的价值观，身为员工很可能不会有太多收获，反而会受到负面的影响。
Continue reading 大公司？小公司？我的经历和建议
IT人才难以管理，这恐怕是众所周知的世界性难题。我遇到过的一位公司老板就说：IT嘛，去招50个实习生来当码农，一个礼拜不睡觉，系统就做出来了。虽然这话看起来比较极端，也反映出大家面对IT人才管理的困境。因为没有明确的、通用的办法，所以干脆“釜底抽薪”，用最极端的手段来应付——要知道，这位老板对其它部门的管理可不是这种样子的。
IT人才管理的历史可能相对短暂，但也确实出现了不少探索。我先后读过《最后期限》、《人月神话》、《门后的秘密》、《软件人才管理的艺术》，都涉及到IT人才的管理，也提供了许多有价值的信息，但读过之后，总有“只见树木、不见森林”的遗憾。在IT行业的各个技术领域，基本都有“经典教科书”存在，能让人一览全貌，并且会提供若干实用的操作指引。唯独在IT人才管理方面，各本书籍多是侧重某个方面的管理，或某种具体类型的案例，因此难以在管理者内心建立完整统一的图谱，结果就是各个方面参差不齐，注意到的方面做得不错，注意不到的方面则形成明显短板。
出于很偶然的机会，我读到了这本《知人善用》，顿时觉得眼前一亮，希望推荐给大家阅读。这本书的英文原名是Managing the Unmanageable，意思是“管理那些没法管的家伙”。在作者看来，IT人才之所以“没法管”，完全是因为“不得法”。换句话说，IT是工作高度抽象化的纯脑力劳动工作，但实际执行起来又非常像传统的手艺活，这种张驰不但提高了管理的难度，它所形成的特定文化更是让管理难上加难。所以，作者根据自己的经验，提供了一整套的建议、工具、技巧，希望能帮助读者“既见树木，又见森林”，“得法”地管理IT人员。
Continue reading 全面且实用的IT管理教科书——评《知人善用》
上周五到周日，72小时内连续参加了北大、武大两场校园招聘会，笔试加上面试，总共见了一百多位同学。其中有很多很不错的同学，在学校里就积累了相当的经验和见识，相信这些同学将来一定有很好的机会；同时也见到不少同学因为各种各样的问题，没能顺利走完招聘流程，让人感觉非常可惜。下面我结合自己经历的校园招聘安排，给各位找工作的同学一点建议。
校园招聘的第一个环节通常是笔试。因为收到的简历太多，用人单位希望用笔试高效地筛选出符合基本需求的同学。所以，参加校园招聘的同学，应当记得的第一件事情就是带上笔。
笔试的题目一般由客观题和主观题组成。客观题考察的是基本的数学和逻辑能力，具体形式是简单的逻辑推理或者数学计算，有时会安排一些干扰因素以增加难度。这类题目或许有题库可供参考，但正式一些，或准备充分严密的笔试卷往往不会照搬题库，至少也会加上变化。比如计算某个指标的增长率，会让你先排除干扰把这个指标从一大堆数据里剥离出来。不过通常来说，一般公司的笔试提都不会太难，毕竟大部分公司不是“只招最聪明的人”。所以，只要同学们在学校里认真、严谨地学习过一定数量的课程，冷静应对，回答这类题目是不在话下的。实际情况也是如此，不少学文科的同学的本功都是过硬的，一些同学甚至取得了客观题全对的好成绩。这充分说明，基本的数学和逻辑不应该是理科生的专利。
Continue reading 校招经验——写给找工作的同学们
不再从事单纯的程序开发，而是介入和管理公司的IT工作之后，我遇到了许多新的问题，对许多旧问题也有了新的视角和理解。无可否认的是，在大多数公司，IT工作的管理都不是简单的工作，状况层出不穷，而且似乎没有能直接拿来用的解决方案。一面是千头万续，一面是束手无策。为什么会这样呢？原因之一大概是，很多人没有意识到：IT是种资源。
IT是一种资源，首先意味着它不是成本。
在很多场合，IT被视为支持部门，但将其视为成本，思路就自然会想到“降低成本”，而将其视为资源，则会从“发挥价值”来考虑。所以在很多偏实业的公司里，并没有严格意义上的IT预算，他们更习惯一次性花钱去购买系统，并培训人员学会使用，然后就是一了百了。在它们看来，养IT的“成本”是相当高的。
如果换个角度，设定专门的IT预算，要求这笔投入得到更大的回报，就可以看到甚至把握住许多其它的机会，比如内部操作和流程的优化，比如对外业务交互的便利。尤其是在今天，“互联网思维”已经到处弥漫，各产业的生态都在不断演变，一门心思想着降低IT成本，固守封闭系统的企业很可能错失大好机会，甚至被产业发展所淘汰。这不是说笑，而是活生生的例子，现在许多制造型企业也想搭上电商的快车，掌握更多的主动权，但因为长期忽略IT建设，根本无法进行数据对接，只能望洋兴叹。
Continue reading IT是种资源
在我小的时候，家长经常对胖孩子打趣说：哟，身体长得挺快，可惜就是横向发展了。看来在很多人的潜意识里，纵向发展是向上的，值得夸奖，横向发展则不是那么光彩的事情。但是我的工作经历和思考，却让我对“横向发展”有了新的认识。
程序员的发展，长期以来都是大家关心的问题。通常程序员的发展有两大方向，深度和广度。深度发展，就是精深自己的本事，研习新潮尖端的技术乃至学会“屠龙之术”，以绝招打遍天下；广度发展，就是拓宽自己的技能种类，比如学会更多的语言，以完成更多种类的任务。除去这两大方向，其它能选的发展方向似乎就只有“改行”了。
今天我要说的当然不是改行，而是除去深度发展、广度发展之外的第三维度，因为似乎一直也没有正式的命名，所以我干脆借用“横向发展”的说法好了。
Continue reading 程序员的“横向发展”
领导必须更懂技术吗？这是个问题。做了领导以后，因为工作的关系，许多人都不那么熟悉基础的技术了，结果自己心里没底，更怕遇到问题时在下属面前丢脸。所以，有些人选择了双管齐下——既不放弃领导的工作，又不放弃原有的技能，结果疲惫不堪。还有人干脆选择不当领导了，因为有手艺，才有安全感。
这个问题也困扰过我，而且始终找不到“合理”的答案，最终还要靠亲身的工作经验来解答。所以在正式回答这个问题之前，让我先讲讲自己的亲身经历。
Continue reading 领导需要比下属更懂技术吗？
不少朋友都提到，手下的员工离职往往是让人非常头痛的事情。这大概是管理岗位经常需要面对的一种麻烦，这个问题也困扰过我。为了帮助仍然被困扰的各位同仁，下面提供我的经验给大家参考。要说明的是，因为我和朋友们几乎都在IT行业，“员工离职”的大部分情况也就直接体现为“程序员离职”，所以我主要讲的还是应对程序员离职的经验，其它行业的朋友可以自行参考。
要妥善应对员工的离职，首先应该问的问题是：员工为什么离职？但是，这么提问往往容易将大家的思维引入极端，得到“他家里有事”、“他不爽薪水”之类的个例答案，而偏离了关于问题的本质。所以我们不妨换个问法：在什么情况下，员工不会离职？我的朋友 @jackyexin 给出的答案是，员工不离职，必须满足两个条件：第一，员工觉得公司有发展；第二，员工觉得自己有发展。我觉得很直接很可靠，也为我的经验所验证，所以，下面结合我的经验谈谈这两个条件。
Continue reading 领导如何应对员工离职
大概六年前，我在一家名为“抓虾”的在线RSS阅读网站工作（如果你不清楚RSS阅读网站是什么，可以参考Google Reader）。阅读器都需要显示当前用户的未读数，抓虾的做法是给出精确的数字，明确告诉用户“你还有2456篇文章没读过”，Google Reader则显示为10+、100+等形式，告诉用户“我还有十多篇/一千多篇文章没读过”。初看看来，这只是一种普通的差异，但产品人员提出10+、100+的形式更好，原因我如今记不太清楚了，似乎是说这样给用户的心理压力更小，因为如果数字比较大，用户就不需要知道具体的数值，所以阅读体验更好。虽然程序员都并不认同这种理论，但因为分工不同，最终做开发的大伙还是完成了这个功能。“可想而知”的是，这个功能上线之后并没有带来明显的正面反馈。更好玩的是，过了一周，Google Reader的未读数竟然改成了准确数字！
前几周，我在twitter上说起这个故事，本来只是凑兴当个玩笑，收到的反应却出乎我的意料，因为反馈大都是对产品经理一边倒的负面评价。我又想到自己的一个朋友，他在某家以产品经理文化著名的大公司做开发，谈到理想的工作，他的要求是“找个产品经理少的地方就好了”。这样看来，程序员和产品经理的矛盾是普遍而且深刻的。
Continue reading 做个懂产品的程序员