• Feeds

  • 技术晋升的误区


    每到年底,业内不少工程师又需面对晋升答辩的流程,如何让自己在最短的时间完成职级提升是大家关注的话题。在一个规范运作的公司里,基础的晋升通常由部门的经理或者技术负责人定夺,更高级别的评估通常由一个跨部门或公司范围的技术专业委员会(Technical Committee简称TC)来负责。本人有幸参与了几年TC的工作,很高兴看到不少人员的快速成长,但同时看到的一些成长认识误区如下。大家可以通过这些误区的了解,来合理的规划自己的职业生涯,获得更好的职业成长。

    • 罗列工作、项目或者KPI。技术委员会评估一个人的能力时,通常希望寻找论据来支持候选人符合更高级别的Level。但是支持点并不是凭工作量或者项目数的多少来决定。项目按时完成情况是一个辅助因素,但不是全部。因此在所罗列的项目中,寻找那些项目包含了能支撑你胜任高Level去介绍。
    • 没有重点及个人贡献。有些候选人介绍了几个形态各异的项目,但需要评委去仔细挖掘到底体现了候选人哪方面能力;另外一方面有些员工虽然参与了重点及有挑战的项目,但如果其中的个人贡献不好辨别则很难加分。评委可能想“嫦娥三号项目很伟大,可是这个家伙究竟是参与开发了玉兔号月球车,还是仅仅坐在监控大厅看显示器……”。仅强调项目成果评委无法判断候选人的能力,突出重点项目及个人的独特贡献,是材料展示的关键。
    • 承担过的项目与申请的Level不匹配。有些候选人参与过不少项目,对公司也有贡献。但是TC对不同的Level期望候选人展示的能力及规划能力是不同的,越是高阶Level申请,越是看在领域内的规划能力、影响力与愿景,如果目标仅停留在项目完成与否上,不管在哪个级别都会有所欠缺。
    • 可度量及可比性不强。技术行业中,分工越来越细,因此候选人从事一个大家不了解也没参与过的领域的情况越来越多。因此如何将这块的工作的好坏达到一个行业内的可比性也是很重要,帮助TC来理解你的工作。
    • 大篇幅罗列非专业领域的能力,比如项目管理、团队管理、跨团队协调成绩、培养新人成果、项目交付状况、创新成绩等。并不是说这些材料不好或不能讲,但是如果60%以上篇幅都是讲这些,TC无法判断你在专业上是否达到了申请的Level。通常TC对专业角度的考察会占到60%以上的权重。直接说出你打了哪几次胜仗,每场由于环境的变化你灵活使用了哪些兵法来克服困难,在某些特别的条件下,你灵活使用了一些没用过的兵法取得了良好效果。如果你发现过去缺少独立打仗的机会,请看下一条。
    • 岗位成长性差。这一点无关答辩技巧,更多是路线规划与上级主管的培养问题。由于注重结果导向,大部分主管更多精力会放在项目的交付及进度,对下属的安排主要是工作的分配及是否按时完成的监督,而对员工的技术成长、路线规划等则会偏少。碰到这种情况,更多的跟上级在专业发展方面进行交流。确定你的技术成长路线并寻求上级的资源支持,大部分上级也会很乐意提供资源的配合。

    (PS:曾打算写一篇晋升攻略,但考虑到每个人的目标及成长路线的多元化,很难给出公式化的建议,因此仅罗列一些误区供读者思考。)

    寡头时代的技术大会


    尽管大部分技术大会的演讲材料会后公开了,但是大家还是看重现场去参加并聆听。参加一场技术大会,简单的理解是扩大自己的认知圈,感受一下不同的思维方式,深层次是希望通过讲演的感染力,获得思考、借鉴或者力量。如 @霍泰稳 在QCon上海大会keynote致辞中提到,“你正在改变世界,我们在影响你”,在一场大会中,大家通过演讲的材料或者讨论来相互影响。

    在另外一方面,技术大会的参会人员大多是一种仰望学习的心态,这种情况下,演讲也会具有一些局限性。

    • 知识的局部性,讲师为了内容的感染力及趣味性及易理解性,倾向于挑选领域中一些特色点来介绍,也会通过重复一些“正确的废话”获得大部分群体的共鸣。演讲不等同于老师上一堂课。
    • 时间的局限性,大部分演讲时间在半小时~1小时,较难将问题深入展开并让听众领悟;另外考虑到听众多元化的背景,也尽量选择最通俗的内容来讲解
    • 环境的局限性,具有丰富知识性的材料较难通过slide充分展示,同时,对于slides内容,观众由于需要跟随讲师演讲思路,未能有充分时间去理解、思考材料内容,也常常还未看清材料讲师已经翻到了下一页

    基于这些看法,并考虑到对听众实际生产力改进的影响,我最近更看好小班培训对于知识学习的效果。

    从讲师的角度,一场好的演讲,准备永远都是不充分的,演讲确实是一个厚积薄发的过程,尤其在内容的深度方面。除了表述的问题之外,有可能还是讲师自身认识的体系性与深度的问题。有些讲师虽然自己做过一些不错的系统,但也有可能未去深入去抽象其中的普遍性的规律,单纯复述一个强大系统的feature并不能让听众满足。讲师通过一次演讲的机会,可以整理自己的思想及体系,获得外界在领域内的反馈,更虚一点,一次好口碑的演讲,可以赢得社区的尊重及声望、建立技术品牌。

    技术大会也变得越来越国际化,由于互联网传播的速度,国内公司与国外在认知层面差距不是很明显,表现为老外的技术架构栈,国内公司搭建起来的似乎非常相似。但是从内在来看,开发文化的差异短期之内不太能改变,以及在开发工具、开发框架精细化方面尚有距离。

    不管在技术架构还是大数据处理分析上,大型公司都具备在架构实践及大数据挖掘方面的人才及环境的领先优势,至少从最近的一系列技术大会来看,这是一个寡头的时代。

    Cassandra代替Redis?

    最近用Cassandra的又逐渐多了,除了之前的360案例,在月初的QCon Shanghai 2013 篱笆网也介绍了其使用案例。而这篇百万用户时尚分享网站feed系统扩展实践文章则提到了Fashiolista和Instagram从Redis迁移到Cassandra的案例。考虑到到目前仍然有不少网友在讨论Redis的用法问题,Redis是一个数据库、内存、还是Key value store?以及Redis和memcache在实际场景的抉择问题,因此简单谈下相关区别。

    首先,Redis和Cassandra完全是适合不同的使用场景的NoSQL产品。前者是适用小规模内存型的key value或者key list数据,后者适合存储大规模数据。因此这篇文章提到切换主要原因或许还是前期Redis使用场景不合适,在初创公司项目初期,以顺手的工具快速实现功能的做法也可以理解。

    Redis的几种使用场景

    • 访问量大
    • key value或者key list数据结构
    • 容量小,可控,可以全部放入内存。由于Redis是单线程设计,因此大value会导致后续的请求一定的堵塞。另外hashset当hgetall时候由于存在遍历操作,也不适合集合太大。如果数据超过单机容量可以使用常规的sharding方法分布到多台机
    • 需持久化的场景

    上面四点一般情况下应是必要条件。因此常见网站的用户资料、好友列表就适用用Redis来保存。由于Redis具有memcached所有的特性,也有讨论说memcache是否可以退出了?在以下情况下,我会倾向于选择memcached而非redis

    • 简单无需持久化的key value,比如100字节以下。这种情况下使用memcached空间更节约且维护更简便。
    • 有滚动过期需求,如网站的session,每个新登录的用户定期过期。

    相关观点也可参考Memcached真的过时了吗

    几个问题

    1. 既然Redis可以持久化,用Redis保存的好友列表是否还需要保存到关系数据库?
    2. 手机游戏Clash of Clans中的城堡属性、及用户的金币、圣水、奖杯适用用什么数据结构保存?