订阅业界RSS CSDN首页> 业界

专访陆其明:技术牛人的蜕变之路

发表于2014-06-18 05:52| 次阅读| 来源CSDN| 0 条评论| 作者张勇

摘要:社区之星第49期采访了爱奇艺研发总监陆其明,他分享了个人生涯、管理和程序员素养等。管理上他认为对人要领导,要管的是事;而在程序员素养上,他则引用Jeff Atwood的话称,成为优秀程序员的方法就是抛开编程。

陆其明,北京爱奇艺科技有限公司PPS上海公司研发总监。2000年毕业于南京大学,自2004年起,连任4届微软MVP(最有价值专家)。辛勤耕耘十余载,在技术研发、团队建设、流程控制、项目管理等方面积累了丰富的经验。已经出版的著作有《DirectShow开发指南》、《DirectShow实务精选》、《Windows Media编程导向》、《脚本驱动的应用软件开发方法与实践》,译作有《代码之道》、《高效能程序员的修炼》、《程序员的修炼——从优秀到卓越》。

陆其明,一个很爱分享的牛人

CSDN:从微博上获知,你在某个公司待了将近九年,今年才换了份工作,到了PPS,之前是做什么岗位的?到了PPS后,又是做什么的?

陆其明:因为PPS已经于去年5月份被爱奇艺公司收购,所以我现在实际上在爱奇艺工作,任研发总监一职,负责爱奇艺PPS影音PC客户端软件的研发工作。在此之前,我在一家美资企业里工作了将近9年,要说这家公司的名字,其实还是挺复杂的。我在2005年加入的时候,公司的名字叫速尼软件(上海)有限公司(英文名为Sonic Solutions,为美国上市公司);后来这家公司于2011年被另一家美国上市公司Rovi Corporation收购了,中国公司的名字也变更为乐威软件(上海)有限公司,离开时我任职为Senior Engineering Manager(高级研发经理),负责视频娱乐分发系统的PC和移动客户端软件的研发工作。

CSDN:能聊聊你的CSDN博客吗?因为博名还有博客风格很特别。

陆其明:我是CSDN10多年的老会员了,以前做程序员的时候在CSDN论坛的“多媒体/流媒体开发”板块相当活跃,积累了很多专家分。那时候应用DirectShow技术比较有心得,我在网上发表了很多文章,后来又转发到杂志上,最终有幸于2003年12月出版了个人的第一本书:《DirectShow开发指南》。自那以后,有了点小名气,做多媒体开发的大都知道有个“陆老师”。因为推广DirectShow技术所做出的贡献,我在2004年首次获得了微软MVP(最有价值专家)的荣誉称号,并在随后连任了4届。

我在CSDN的网名是Happydeer,现在看起来虽然有些幼稚,但从名字上也可以看出,我一直是一个乐观开朗、追求快乐的人。我相信,我的快乐很大程度上源自于我的分享精神。有人曾经问我,“你这样把技术都说白了,不怕别人超过你吗?”我说,“我不怕,因为我也一直在进步!”况且,我相信,特定的技术都是有保鲜期的,唯有分享才能发挥它的最大价值。我只后悔自己当年分享得还不够,有一些代码至今还沉睡在我的硬盘里,而它们现在已经几乎没有任何价值了。我在博客首页上放了这么一句话,“穷则独善其身,达则兼济天下。”我很喜欢这句话,因为它很好地概括了我的价值观。

CSDN:你过去曾是名DirectShow大牛,聊聊这段经历吧?

陆其明:2000年,我从南京大学毕业,来到上海,加入了一家做视频监控系统的初创公司。从那时起,我的职业生涯便与视频结下了不解之缘,直到十几年后的今天还在延续。在那家公司里,我第一次接触到了DirectShow。DirectShow是微软公司提供的一套在Windows平台上进行流媒体处理的应用框架和开发包,用它可以实现音视频数据的采集、转码、多媒体文件播放等功能。因为工作需要,我对DirectShow研究得比较深,包括SDK文档里的每一篇文章、每一个API,还有SDK附带例子里的每一行代码。当年的巅峰状态是,我5分钟之内就能做出一个Filter。我也喜欢写写小结,把自己的心得发布到网络上。这么做也许是因为比较孤独吧,那时我算是国内接触DirectShow比较早的那一批人,而分享是快乐的!

我出过两本DirectShow方面的书。说起出书,也算是机缘巧合吧。我在网上发表了很多DirectShow相关的技术文章之后,突然有一天,一位网友联系我,说他认识出版社的人,如果我有兴趣的话可以把我发表过的文章整理成书。真是不可思议!我就这样出了第一本书,并且从此一发不可收拾。那位网友真是我的贵人啊,只是我们至今未曾谋面……因为出了书,也就有了一定的知名度,渐渐地有人开始称呼我“陆老师”了,但我自认为不算是什么大牛,因为我相信有很多的技术牛人只是自甘寂寞或者不善表达,但不可否认他们在技术上真的很牛,比如MPEG的编解码,或者流媒体传输协议、P2P之类的,而这些我都只知道些皮毛。好就好在,DirectShow是一个系统性框架。我知道怎样把各种组件融合在一起,然后控制输入、输出以满足应用软件的需求……这就是我的一技之长。

对我而言,DirectShow是一段光辉的历史。这个技术如今基本上已经过时了,但它让我学会了系统性思维,至今我仍然受益匪浅。如今的我早已不做具体的技术工作了,我甚至都不想别人再把我的名字与DirectShow联系在一起。但不管怎么说,DirectShow曾经带给我很多快乐,虽然技术不再,但我会将快乐继续下去!

CSDN:你是从什么时候开始翻译程序员英文文章的,为什么会去做这项工作?这样的习惯给你带来哪些收获?

陆其明:大概是2008年的事吧。微软的MVP群里广播了一条消息,说有几本微软出版社的英文书,有兴趣的可以报名翻译。那时那刻,我已经写了4本书了。出书对我来说已经是熟门熟路的事了,我唯独没有做过翻译,想尝试一下。于是,就有了我的第一本译作:《代码之道》。

在过去的十几年里,我一直在美资软件公司里工作,英语还算不错吧。做英文翻译本来也是我能力范围之内的事。至于翻译什么样的书,我是有自己的选择标准的,最关键的一条是书的内容必须与我的工作密切相关,并且能让我有所长进。我把翻译当成是自己学习的一个过程,而最终形成的译作相当于把我的学习笔记分享给其他人,希望其他人也能从中受益。

拿《代码之道》来说吧,它至少让我铭记在心,“成为一名优秀的管理者,所有你要做的就是确保你的人能够工作,并且把他们当人(而不是资源)去对待。”其实,管理不难!

CSDN:你很多博文都翻译自Jeff Atwood,能不能介绍下这位牛人,顺便再说说你为什么如此推崇他吧?

陆其明:在翻译《高效能程序员的修炼》和《程序员的修炼——从优秀到卓越》这两本书之前,我其实并不知道Jeff Atwood这个人。但我知道Stack Overflow这个网站,因为在碰到一些难以解决的技术问题时,如果用Google搜一下,答案往往就在Stack Overflow上了。Stack Overflow类似于国内的CSDN,是国外的一个技术问答型网站,而Jeff Atwood恰恰就是Stack Overflow的联合创始人。

Jeff Atwood本人是一名程序员,他至今仍然在写代码,虽然他已经离开Stack Overflow了。因为Stack Overflow的成功,Jeff也就堪称杰出了。他还有一个博客网站,叫Coding Horror。作为一个与众多程序员同行沟通的窗口,Coding Horror上有很多精彩文章,主题涵盖程序员的素养、价值观,还有关于编程风格、软件测试、团队合作、用户体验、社区管理、网络安全等方面的讨论。Jeff的文章观点独到,一针见血,很多困扰着程序员的问题,在读过他的文章后便豁然开朗了。作为程序员,能够做到技术过硬,视野开阔,又能有效地与别人沟通,实在是可谓楷模了!

CSDN:你出了不少本书,谈谈你的出书整体经历吧?

陆其明:《DirectShow开发指南》是我的第一本书,出版于2003年。在过去的10年时间里,算上自己写的和翻译的,我已经出版了7本书了。前面4本主要讲的是具体的技术,后面3本偏向于管理和人文。这跟我个人的职业发展恰好相符。有些朋友可能觉得我因为出书发了财,但如果你出过书,你就会明白这不是真的!出书所带来的经济收入是微薄的,写书或翻译的过程非常辛苦,但我从来没有后悔过,因为它至少带给我了一些成就感。我的工作和生活多多少少也受到了影响。只是,在今后的几年里,我不可能继续这样的出书节奏,因为我必须更好地平衡工作与生活。

再说说我最近翻译的两本新书吧,一本是去年7月份上市的《高效能程序员的修炼》,另一本是今年5月份刚刚上市的《程序员的修炼——从优秀到卓越》。两本书的作者都是Jeff Atwood,这两本书精选了Coding Horror博客上的精彩文章,凝聚了作者本人对程序员周边事物的看法,传递了很多正能量!包括我自己在内,我在翻译的过程中也感觉受益匪浅。我把这两本书的绝大部分文章都贴到了自己的CSDN博客,如果你不喜欢买书,那就去那里读吧!

从技术牛人变成管理者 感慨良多

CSDN:从技术向管理的转变过程中,有没有什么“坑”?

陆其明:一路上“坑”很多,我这里罗列几个主要的:

  • 思维方式首先要改变。做技术只要顾着自己就行了,而做管理的时候,要把关注点从自己身上转移到团队,要保证整个团队的可持续性高产出,“大家好才是真的好”。
  • 不能再以为“技术无极限”,不能再过于乐观,需要更多地做权衡和取舍。
  • 要站高了看问题,多从公司利益、业务需求、用户体验等角度去思考问题,这对习惯于讲逻辑、细节导向的技术人员来说是很难做到的。
  • 技术人员一般不善与人沟通。但既然做起了管理,这方面必须加强,既要做足内部的沟通协调,又要担当团队的保护者和代言人。

CSDN:从事管理工作后,还会偶尔深入到开发一线写代码吗?

陆其明:记忆中有过一次吧。在前一家公司里,我曾负责某个OEM客户项目。客户中途需要一个组件,但相关团队因为组织结构调整已经无意再开发了。于是,我就卷起袖子自己上了。这个组件虽然成功交付给了客户,但后续的支持工作还是花费了我很多精力。

以后不会再这样干了,也不能这么做。这绝对是一个“坑”!特别是团队很大的时候,比如有30~40人,对于管理者来说,绝对有比写代码更重要的事等着你去处理。团队里有这么多程序员,他们天天都在跟代码打交道,熟能生巧,写代码就是他们的工作。纵然过去你是编程高手,几年不练也就生疏了。要相信你的程序员一定能写出更好的代码,要是还不放心,那就亲自参与做代码评审,但也不要亲自去写代码。

CSDN:作为一名技术管理者,你是如何促进团队紧密协作的?

陆其明:协作的基础是相互理解和信任。要达成这个基础,就必须加强沟通。不管在任何公司或组织里,沟通永远是个问题!况且,程序员在沟通方面往往比较被动。我就要促进团队的沟通,及时发现沟通中的gap,在团队中发挥催化剂的作用。在众多沟通方式中,面对面的沟通是最有效的。有时候看到两个紧挨着坐的同事讨论问题也要邮件来邮件去,我就会很替他们着急,总会要求他们:站起身来,走到对方座位上去直接讨论吧,或者抓起电话!我喜欢工作方面积极主动的人,这种人本身会进步比较快,我还会让他们承担更多的职责,他们在团队里自然也会得到更好的发展。

涉及到跨团队的协作会更加微妙一点,因为不同团队的目标可能不一样。信息在沟通过程中还可能丢失或被扭曲。尽量让各个团队的技术人员直接对话,而不是通过管理者一层一层传话(因为有些管理者根本就不懂技术),合作的效果要好得多。团队之间要加强信息的共享,并且需要制定共同的目标和优先级。

CSDN:很多管理人员都对团队的执行能力犯愁,你认为该如何提高团队的执行力?

陆其明:我曾经专门写过一篇文章讨论执行力的问题。执行靠的是团队;执行力不好,给人的直觉就是团队的能力不行。其实,很多的时候不是技术的问题,而是沟通或管理方面的问题。甚至我觉得,关键要看基层经理给不给力。老外常说“stay on top of issues”,强调的就是管理人员要到前线去督战,倾全力于执行。在以前的工作经历中,我看到VP级别的人都在没日没夜地跟踪很细的问题。没错,这种微观管理一定很累,但想要出成绩就不能贪图舒服,因为舒服是留给死人的。说起来其实很残酷!问问自己的人生目标吧,回答这样一个问题,“你究竟想要过怎样的生活?”

我们的CTO还说,“执行力取决于信念。”我非常赞同!反思自己,在外企待了10几年,为人太nice了。如今的企业环境变了,我也需要做出相应的调整。

团队管理不等于管人

CSDN:你是如何管理和激励你团队程序员的,有没有好的方法分享?

陆其明:对于团队,我不太愿意用“管理”二字,因为我相信人靠管是管不好的。程序员的智商都不低,自上而下的管制的结果必然是上有政策下有对策。对人要领导,而要管的是项目和事。Jeff Atwood认为,最有效的一种技术领导是“以身作则”。

所谓激励,就是要充分调动团队的工作积极性。一说到激励,可能大家的直接反应就是钱。其实,金钱并不是最好的激励方式。各人有各人的情况,每个人在不同的阶段也有不同的需求,因此激励的方式也应该是多样化的,比如一句鼓励或感谢的话、请他吃顿饭、培训机会、晋升机会等等,当然加薪、奖金、股票、期权有时也是不可缺少的。最关键的是,要将个人的发展与公司的发展紧密地联系到一起。对于管理者来说,尽量做到公平也是至关重要的!

CSDN:你是怎么看待“无我编程”的,在实际团队管理中,你们会运用“无我编程”吗?

陆其明:Jeff Atwood写过一篇关于无我编程的博文。但要真正做到“无我编程”是不容易的。我们会通过代码评审来提高代码的质量,我们也希望每个模块都有确定的责任人,一来可以提高开发效率,二来也是为了加强大家的责任感。出了问题就找他,逼着他提高代码的质量。

CSDN:有所成就的人往往在时间管理方面做得非常成功,谈谈你的时间管理吧?

陆其明:推荐大家读一本书吧:《高效能人士的七个习惯》。事情多的时候,就要理一理优先级,做到“要事为先”。另外,我对待时间的态度是:时间是挤出来的,要善于利用碎片时间。如果你24小时都在想着做好一件事(当然这有点夸张),你就一定能把这件事做好。凡事预则立,不预则废。

CSDN:再问个和团队看似无关却又有点关系的问题:有人说敏捷好,也有人说敏捷坏,对此你是如何看待敏捷开发的?

陆其明:我现在团队里推行Scrum,但我并不是敏捷的脑残粉,因为我知道,没有哪个流程是完美的。公司大了,没有一点流程肯定是不行的,否则早晚会出事。但什么流程最好呢?其实,根本就不用浪费时间去争论——适合自己的就是最好的。持续改进才是关键!

有了流程,也要保持一定的灵活性。别死板地遵循流程,它不能保证你成功。敏捷的具体方法有很多,别人成功了,并不见得你照做也能成功。我们应该追求的是敏捷的精神,也就是这四句话:个体和交互胜过过程和工具;可以工作的软件胜过面面俱到的文档;客户合作胜过合同谈判;响应变化胜过遵循计划。

0
0
  • CSDN官方微信
  • 扫描二维码,向CSDN吐槽
  • 微信号:CSDNnews
程序员移动端订阅下载

微博关注

相关热门文章