一个阿里巴巴码农的六年回眸

一个阿里巴巴码农的六年回眸

本文由淘宝开放平台技术产品负责人@放翁_文初撰写,它讲述了一个个冷冰冰产品背后的活生生的人了,也在讲述着一个码农的六年心路历程,“技术耐得住寂寞,低谷积累高峰冲刺,主动改变一切。”

  2012 年 10 月 13 日,关于淘宝开放平台技术部分的分享看到有些同学留言说有这样的机会和环境是幸运的,的确在阿里这些年赶上了公司的发展,赶上了互联网技术的发展,是幸运的。但是背后这个普通的人,从进入公司的低级程序员一步一步成长起来到底是怎么走过来的,也许可以让一些正在走的同学有值得思考的地方,我尽量少加一些自己的收获在里面,因为每个人看到这些场景感到了什么那就是什么。

  2005年:走出国企

  毕业 4 年多在一家通信国企做的顺风顺水(不是自己能力有多突出,是老板经常被挖,所以提升的不错),总感觉有点养老的味道,于是开始在招聘网站投简历,没想到一家叫阿里巴巴的杭州公司联系上我去面试,聊下来是类似于后台运维部门,兴趣不在此,就拒绝了,但其实埋下了伏笔。

  2006年:一切归零

  刚过完年,那家阿里的公司 HR 又联系我,说这次部门不太一样,去了,然后说了一些关于 Work at Alibaba 的想法,那时觉得互联网要比通信企业更有意思,所以不顾家人和未来老婆的反对,辞职去了这么一家以前都没听说过的企业。进公司以后,一切归零,工作四年后又从底层做起,虽然忙碌,感觉充实。半年后开始觉得有些无聊,该学的都学到了,剩下的就干一点常规的活,啥 Work at Alibaba 又没影了,心里落差很大。

  2007年:征召入伍

  突然被征召“入伍”,20来号人被拖到老马(马云)的福地“湖畔花园”创业去了,我的感觉就是莫名其妙,收购了一家公司(主要做 CRM 系统框架和模型驱动),然后就开始要搞创业了,不过起码 Work at Alibaba 的说法有找落了。一帮子人窝在 3 室一厅的房子里面,不同业务团队分在不同的小屋子里,测试和架构团队在客厅。虽然我是个没有背景的小兵,但老大还是给了我足够的机会,我没有去做业务支撑,反而成了团队里面做基础系统的,这里每个人的 level 都比我高 2 级,于是我背着“架构师”的名字开始努力奋斗。

  2008年:照猫画虎

  菲青老大加盟淘宝,成为淘宝的首席架构师,菲青组织集团所有架构团队的同学定期聚到西湖边上的“淘咖啡”(现在已经没了),相互间交流技术,我这毛头小鬼,托福也被拉了进来。翻着 Yahoo 的网站,看到了 Flickr(记得今年年初的时候还谈当年的 Flickr 是最能够成为今天 FB 的公司,结果给雅虎浪费了)的开放模式,于是照猫画虎,还就搞出了一个看起来还有点摸样的东西。接下来我的主业就放在这块上面了,这一年技术成长很快,因为开放平台是新事物,安全(数字签名,授权,加密),数据处理(xml 解析各种基础知识,json 的规范),REST 代理服务器实现等等,这些都是互联网的产物,都非常扎实落地,充实的日子过的总是很快。

  2009年:阿里软件解体

  阿里集团的不同公司的氛围是完全不同的,阿里软件团队氛围还是那种强调自上而下的管理,加上一些关系纠缠在里面,我这个苦脸码农一直都不入流,因此也想换换环境,加上看到当时 HSF 的成长中菲青老大能抗的住压力让毕玄最后坚持下去,心里还是酸酸的,但 HR 和 Boss 的左手大棒(你去哪家公司我们管不了你)右手胡萝卜(晋升名额本来就是你的),我能做什么呢(那些日子的经历让我记忆犹新,也许当时运气太好了吧,在淘宝快 3 年多了,每个 HR 都让我觉得受宠若惊)。但世事难料,年中的时候突然宣布公司解体,就这样我们笑话的说我们把公司搞没了,很多人非常伤感,我却非常开心,因为我有机会去淘宝了。

  2010年:空降淘宝

  空降淘宝,虽然新老板对我能力比较认可,但是淘宝的开放平台已经有了一个 10 个左右的小团队了,如何融入是最迫切的。我缺乏的是业务,了解的是平台,能力在于技术,于是天天帮助团队同学打杂,解决问题,慢慢的也用能力证明自己。一直处于一个团队攻坚和打杂的角色,技术能力还是得到了飞速的提升,因为这一年开放平台正式商业化了,对于基础平台的要求非常高。但这一年也有些不好的评价对我,有些同学觉得我太强势了,对于团队成员的发展会起到反作用,顺风顺水的我依然觉得用技术说话,判断力取决于技术能力。

  2011年:忐忑生涯

  经过一年多的基础平台建设,整体平台架构已经比较完善,而我的角色开始显得有些尴尬,叫架构师,但业务管不着,技术管一块,不带人,干活自己做。后来这年有个毛头小伙子听了我的课死活要加入开放平台(技术大学第一届),因此他成了我第一个徒弟式的同学,然后加上我是淘宝第一个做 App OPS(原来运维是独立于开发的,后来因为希望给开发更多空间,所以允许有开发有能力的人自己管理系统基础运维和发布,这类人被叫做 App OPS),另一个还在实习的愣头小伙子也成了我的徒弟式的同学,就这样我这个架构师有了一点人员资源干点可以干的活。

  事情总不按每个人的想象走,最后组织结构调整,开放平台技术部分人员可以让我来管,看我是否能够留下来,我比较坚定的要求就是我要带产品和技术两块,可以想象的是,老大看着一个从来没带过人的P,突然要带人了,还要带产品,那有多忐忑。最后为了风险可控,开放平台技术两个技术核心团队留给我,其他两个团队拆分,给我一个产品经理,其他产品经理还是统一组织管理。我给老大的承诺是:一年,除非老大你炒我,否则我会让你觉得放翁说到做到。

  2012年:感动着

  事情就这样开篇了,我开始带人了,开始跑业务了,象块海绵一样吸收各种信息,和三淘的各种团队打交道,作技术的久了总以为自己对业务很熟悉,能够分析出产品需求,当你真实的去做了,去落地了,你会发现这个世界在变,淘宝这个甲方的身份在变,开放平台能够承诺的事情落地是多少不容易。半年里面,人变化了很多,因为了解的更多,学会了更多的倾听和学习,学会更多的谦虚,遇到了很多好朋友 UED,测试,项目总监,这些人真的是为了开放平台而不顾我们组织结构调整到天猫继续支持着,很感动。

  最初打算写这个内容的时候有很多想写的,但是发现写完了就是一个乱,呵呵,权当看故事吧。总结几句话:技术耐得住寂寞,低谷积累高峰冲刺,主动改变一切,找到自己的特点,没有问题的时候最可怕,不同阶段追求不同的收获,先听再说,永远都要清楚你到底要什么!

  下面是自己的一些问答,觉得不靠谱的一笑而过。

  一、怎么看待老板?

  老板就像老婆,他能容忍你的个性就是最大的幸福,不要期望他成为你的老妈,对你百般照顾。要换老板的时候看看离开了他是否一样找不到“幸福”,如果是,那么问题在你,“离不离婚”其实不是那么重要。

  二、怎么看待技术重复造轮子?

  码农那么多,有时候重复造轮子也不一定是坏事,也许比直接拿别人的东西来用要靠谱,毕竟高P不会分工资给你的兄弟。原则就是对产品负责,对人负责,两句话很简单,作技术老大的自己把控和判断。(做不到只能说明你还处于被技术玩的阶段)

  三、怎么看待开源

  当年写了一个 Memcached 的客户端,阿里软件一直在用,就一直维护和更新,到了淘宝用 Tair 了,那个就废弃不更新了。有时候对于国内的公司的开源,我更倾向于叫做“晒代码”,只有自己参与,一旦自己不用就 Over 了。授之以鱼不如授之以渔,多把设计细节和代码片段分析说明作详细了就好了,至于开源,对于一般的业务或平台团队投入成本太大了(一来自己都保证不了几时内部都不用了,二来开源和晒代码最大的差别就是易用性和文档及长期更新),专职做基础设施的团队可以(操作系统,数据库,存储等)。TOP 技术分享月结束以后会把几个核心系统的设计和细节优化代码说明晒出来。

  四、怎么看待晋升?

  对晋升的人来说:

  1. 有时候不多想反而就成了。(因为你脑子只有一个,想多了这个,该想的就没想了)2.挫折未必是坏事。(我唯一一次被一棒子打回来的时候,头晕目眩,现场什么都好,结果就不给理由的说 no,但最后老大一句话点醒:如果不能承受这样的结果,你的心胸就还不够那个 level)

  对 Leader 来说:

  1. 给兄弟们创造更好的环境,你不是管人来的,你是来“创收”的,管人谁都会,“创收”才是真本事。2.让兄弟放心的去做事,自己做好各种准备来帮助到他们。(了解晋升真实的考核目标和需求)

  一句话:人都要养家糊口,都要付出得到肯定,以心相待。

  五、怎么看待带人?

  我告诉自己最多就只能带 20 个人左右(现在就这个极限了),一个团队必然工作有差异之分,但是让每个人都能够满意和满足就需要让所有人认同这个团队要做的事情,以及每一步的结果都是团队的结果,这个时候个人觉得靠“管”其实不太靠谱,更多的是靠“感染”。“感染”能力随着精力分散到技术和业务中一定是有限的,当然梯队化的感染需要每个梯队环节都能够做到位,那么就牛叉了。

  一句话:先让自己相信,别人才会相信,每个人都相信了,人就不是“管”出来的。(理想很美好,现实很骨干,有时候自己就说服不了自己)

  六、怎么看待技术兼顾业务?

  我第一个小软件也是修改了 flash 文件将操作光驱的代码植入,然后调研了各种业务场景,最后成功的传播出去并操纵了一把,那时我就默默的感到传播才是关键。今天也是如此,我和每个程序员包括我老板一样担心我自己分心到业务上是否会废了自己的“武功”,其实取决于:1. 你到底 code 了多少代码?(你会因为一个月用叉子吃饭忘记怎么用筷子么)2. 你到底是喜欢写代码做技术,还是为了生活所迫?(后者无论你写多少代码还是一个没内功的人)3. 写了 10 年代码以后你留下的只有那些代码和技术入门文档,还是有更多的设计理解。(你用了 hadoop 除了会配置,会修改部分性能代码,对他适用场景的理解,整个流程的瓶颈点设计,所有分布式都纠结的问题是否有感知)这么多年了,为什么只有那些 paper 不断的给人启示去做更多的工程化内容,因为用筷子吃面和叉子吃面没那么大的区别。(关键是吃的人怎么理解面难吃的原因)

  所以,前面1,2,3都是你在码农时候做到了,那对业务的理解只会让你如虎添翼(重要的是更多去学习和倾听,放空自己的程序员经历,做个用户)

  七、怎么缓解项目总监和开发的矛盾?

  开发角色:

  1. 开发要把项目总监的客户作为客户,而不是把项目总监作为客户,就和走棋一样,你会比他更能主动的把控下一招的变化,不会纠结于项目总监不断的变化。2. 量化!如果产品无法量化结果,无非就是需求不明确,所以追问。

  项目总监角色:

  1. 数字是基础但不是全部。2. 多一点兴趣爱好,多一点思考。blog 当年如果没有浏览量这个数字会怎么样?微博为啥要搞个双向关注才可以评论的设置?音乐播放器如何在用户不点击 like 反向收到用户喜好行为?

  八、怎么看待平台产品?

  先要活下来,服务好一个产品线,如果没有任何其他产品线过来,那么就不要在乎平台的称呼,留好口子就可以了。当有多个产品接入,同样要活下来,因为脱离单一业务线为了更好的平衡个体需求和平台发展,但重要的是要找到自己有群聚价值(也就是只有集成在一个平台上,多个业务得到的平台功能才会最大化),这样就业务方就不会独自建立平台来快速响应需求。最后如果业务非常繁荣,那么更多的考虑为业务方挖掘业务价值,而不要聚焦于平台,帮助别人就是帮助自己。(这是平台永远都正确的说法)

  九、如何学习技术?

  不用急着什么都学,珍惜每一次不同工作的机会,挖深做细,几年以后回过头来原来自己积攒了那么多!xml 解析分成几种模式,各种解析的优劣?http 1.1 协议中的 Header 中的缓存设置,返回头里面的 trunked 什么用途?分布式计算关键问题是什么(调度,协同,数据交互)?应用压力测试瓶颈如何评定,导致瓶颈的代码所属操作可能分成哪几类? …… 要留下更多疑问背后的答案,而不仅仅是那一点代码,那一些入门文档。

  码农活下来很容易,活的好不容易,好像各行各业都是这样,所以码农和其他行业的人一样,技能仅仅是一方面,更重要的是人的素质和能力,你要活的被动,那么生活就会赶着你走,你要活的主动,那么你就可以走走看看。

  结语:今天上午爬山回家,公交车上看到一对夫妻都是盲人,心里一阵感慨,如果自己看不到,还有活着的勇气么,因为我们今天那么脆弱的抱怨很多事情,当你看不见的时候那是怎么能够抗得住的打击。

it知识库一个阿里巴巴码农的六年回眸,转载需保留来源!

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。