这段时间除了忙项目外，还在参加游戏部门的程序技术评审。我是 6 人评审委员会成员之一。
这项工作逐渐收尾了，所以随便写点东西总结一下。只是我的个人想法，不代表任何其他同事和公司。我想我们尽量做到公平公正，这个是努力方向。至于公开…… ，好吧，现在还做不到，未来争取吧。写这篇东西，算是私下为“不公开”开一个小口。
在我看来，网易的管理一直都是稍显混乱的。管理层很薄弱，相比公司更重视研发技术，管理方面要差的多。对于开发人员，尤其是程序员来说，许多人甚至喜爱这种感觉。这就无法评论其好坏了。这五六年，隐约感觉管理层想逐渐在制度和管理方面正规化，做出一些改变。确实有许多改变在逐步实施，也有不少同事对此郁闷甚至失望。我觉得作为一个公司的灵魂，在重视技术方面我们不能抛弃，否则就不再是原来的网易。这次大规模的技术级别审核评定，也是肯定这一方向的。
我们这次确定下来，和员工收入直接挂钩的，正是员工的技术级别。换句话说，对于程序员，只要能把研发工作做好，收入就能相应提高。跟管不管人是脱钩的。不像管理岗位，一个萝卜一个坑，除非公司规模扩大，否则是没有多余的职位的；而以技术等级来衡量晋升确实有个好处是不限名额，能力达到后就能晋级。
对于管理级别，就成了额外的设置。反映到收入水平上看，一个特定等级的管理职位就是额外享受固定的职位津贴。如果专注于管理事务，而疏于提供技术等级，从工资收入上来看，是有折扣的。目前看来，管理级别比技术专业级别高或低的人大体上差不多，各占相当比例（还有等级相同的） 。这也说明管理等级和技术等级是可以做到独立的。
技术评级也是想做到一定的导向作用。用来引导同事向一致的风格靠拢。（不符合公司整体氛围的人比较难得到晋升）我们到底想引导什么？是前几天在广州昏天黑地的开了两天封闭会议的主要议题。
会议结果我个人还是比较满意的。作为多人相互争执妥协的结果，应该算不错了。
虽然不是 100% 能接受，但以项目成败论英雄还不是最坏的选择。技术要为成功的产品服务在目前这个时期是必要的。我们不能像 google 那样，可以随意拿出精力来做纯粹觉得好玩的东西。虽然做没关系，但是对于个人评级的影响就很微小。正所谓，不鼓励、不反对。如果做的东西能服务在好的产品中，那才能加分。
我们不鼓励单方面的发展自己的技术能力。无论多牛，那也是自己的事。所以就必须要求做技术交流，以及培养同事共同成长。甚至是提高整体行业技术水平。为了不让这个成为空话，较高级别的晋升的硬性条件中就加入了必须在公司做技术讲座甚至必须要求在整个技术圈内有一定规模的技术交流。即使在比较低的级别晋升中也要求有带新人的义务。作为硬条件写在晋升条件中，对某些内向的同事来说有点不公平，但目前也只好如此。如果实在做不到这些交流活动，至少，坚持写技术 blog 并有一定数量的读者也成吧。
这次，我的一项主张在通过时，还是有人反对的。那就是在一定级别之上，我们要求程序员必须精通一门静态语言和一门动态语言。只用一门静态语言的人是得不到高级别晋升的。Ding dang 就反对这一点。虽然他是公司最早提议使用动态语言做开发的人。不过最终我们还是以多数意见通过了这一条。嗯，算是比较民主了。
重构代码算不算重要工作业绩和能力体现，这个问题也拿出来讨论过。最终的结论是不算。原因是公司内太多人希望自造轮子。虽然有可能以偏概全，但简单容易实施的规则在现阶段对我们的评审标准更为重要。好吧，公司里现有太多脏西西的代码，太多不优雅的结构，混乱不堪的项目，但是，我们还是不推荐无边无尽的重构。真正的程序员会把那些实在看不下去的部分重新写一遍，但我们不鼓励这样做。同样的问题还有，每个客户端程序员都想做自己的 3d engine ，每个做服务器的同学都想重新设计服务器架构……
而参加开源项目则是充分鼓励的。尤其是向知名开源项目贡献代码和 patch ，可以和参加公司内部项目取得的成果相提并论。并在晋级评审中得到相同的权重。
似乎在网易，从搞开发转到纯做管理，不再写代码的人会被人“鄙视”。做管理工作的前程序员们多少都还做一些开发工作（甚至相当多开发工作）。就算完全不做了，也要表面上看起来还有做。嗯，老 ding 同学就喜欢在不同场合宣称自己的技术背景。其实他不写代码很多年了。这对不太喜欢写程序的程序员来说可能感觉不好。对比其他一些大 IT 公司来说，也显得管理方面不专业。但这种感觉，于那些痴迷于技术的同学来说，也是一种吸引力呢。至少，一个技术氛围浓厚的公司，人也更单纯一些。那些一心只写代码的同学们普遍显得比实际年龄年轻许多 :D