一个研发人员的自我修养

这个话题是在今年刚结束的ESRI开发者大会上,由北京数字政通的副总分享的。

虽然话题的分享者本人现场演讲可以说挺糟糕的,但不代表这个话题不值得讨论。

全职工作三年有余,从给别人打杂的,变成给自己打杂的,这个转变也可以说是挺艰难的。你要找到适合自己的位置,要保持自己的竞争力,也许在薪资水平还不足以说明你的重要性的时候这不是问题,但人往高处走,迟早是需要面对的。

在第一个项目里,我是以只写过不过一两千行代码的纯小白身份加入,所以只能是别人告诉我怎么做,尽力去实现。想想一个SDE的交互模块,非常简单的空间数据下载业务而已,我花了一个月完成,最后代码还被完全重构了一遍。不过也是那之后,好像突然就开始承担更多的事情了。第一家公司里我是全职的遥感算法工程师,主要负责CS项目的遥感部分。那个时候做的工作,实际上是把常用的遥感计算模型,用C#实现一遍而已。可能你们看博客会觉得好笑,这算哪门子算法。我也这么认为,因为我至今也相信,树,图这样的才叫算法,我那叫模型。然而我工作的更多时间是在Envi下测试这些模型。起先是我做一个基本的设计,同事会提供一部分数据给我,或者告诉我哪个区域需要被计算,我自己去找合适的卫星数据。然后就是不断地修改参数,调整模型的流程等等。当时客户有遥感专家,但他们依然和所有的甲方一样,不愿意在领导感觉可以省钱或者不花钱的地方多付费。所以我们只能用免费的、时效性极差的数据来做这些模型的设计和验证。 这种过程就像做研究一样,只是我们需要比科研更进一步,要让这些算法能够处理大多数的通用情况。对于刚从学校出来的我而言,这种做法简直是不负责任的。

然而很多解决方案最终是被业务逼出来的。我和当时一起的几个同事,外加总部的博士一起,还是做出了让甲方专家认同的成果。这个时候我突然明白为什么是工程师(Engineer),而不是科研人员(Scientist)。工程应用一个理论,会从原理出发进行思考,但更重要的事情是结合实际。而科研,则是尽可能创造一切理想条件,让你验证理论。本质上大家都是做一样的事情,创造成果。但只有理论和实践的结合才会最终成为可应用的产品。而这是我的兴奋点,也是我在第一份工作里最大的收获。之后,随着一部分老同事的跳槽,我在第二年正式成为了项目技术负责人,开始带了一组人进行产品的开发。说来走运,不是每个人都有机会在刚参加工作就得到很多挑战的机会,虽然我这是不能和互联网里那些天赋异凛又勤奋的同龄人相提并论的成绩,不过如果没有这样的机会,可能我还得迷茫好一阵子。 

带人的过程有些不容易。比如刚入职,经验更多的人要听你指挥,他们会有所怀疑,这时候特别需要镇定以及自信。当然,谦逊是最重要的一点。即便你评价对方是一年经验复用多年,有可能在某些特定情况下别人是有解决问题的好思路的。作为一个项目负责人,最重要的是让团队能够高质量产出,而和谐的氛围是保持高效的基本条件。好在当时遇到的同事都很友好,即便先入为主怀疑你的能力,也会在和你接触后互相学习。 那会儿我们团队最成功的事情是每周五的技术沙龙。每周一人轮流做半小时的技术报告和demo演示,一周的时间能给每个人充分的准备时间,而互相学习能让人保持一定的紧迫感。作为一个技术人员,学习是最重要的事情。无论你是学习api使用还是语言本身,或者很纯粹的一些技术理念的实践,都会在未来成为你谈待遇的基础。

从第一家公司离职后,我留了差不多三个月的假期给自己。期间去面试了一些公司,遇到了各种各样的单位。有很好的,也有很自负的,当然也发现自己的短板和被人看重的地方。这个阶段我是想跳出我的专业本身的,因为有一种预感,未来我的专业的价值会被放大,但是具体到应用,则必须以特定行业为背景。我学的是地理信息专业,而第一次参加行业大会时候听到的理念,是截至目前让我十分受用的。地理信息的数据量之庞大,几乎可以和80%的各类数据有交集,而在那一年,并没有多少应用真正意识到这些数据的价值所在。直到今天,国家测绘局的一些规范和数据格式依然没有透彻的完成理念上的转变。这是我的判断,只有被应用到行业上的地理信息,才能真正大量变现。 所以优步和滴滴很成功,所以高德被阿里高价收购。所以当你从技术本身的变化去思考行业的前景,你能获得一个比较准确的判断。这是关于判断力。

至于到技术本身,目前我在一家有高校背景的小公司里几乎全权负责核心平台产品,在实践过程中间,和各种各样的人合作过。印象最深的是两个来自国内某领域一线品牌工程师,他们负责他们品牌产品的二次开发。半创业公司的尴尬是,前期非常容易走弯路,所以早期的v1版产品,核心技术交给这两位负责,而团队里没人能够评审这些代码是否适合用到项目里。外加对技术只知皮毛的项目经理对技术难点的判断失误,导致v1版产品推迟了3个月交付上线,而我刚加入不久,那三个月我几乎在通宵加班重写这两个工程师做的部分。我觉得技术提升的一个明显特征就是,你能一眼看明白别人想怎么做实现,同时能够判断出这样做是否合理。所以当我的评价报告汇报给公司后,公司完全同意把这两个工程师踢出局。代码优劣的标志,不是你的语法多么高级多么优美,而是你的实现思路是否真的考虑适应需求。显然,这两个资深并没有这样的判断力,同时在代码能力上也显得很弱智。今天我认为这是作为一个技术人员最大的恶,20年后我还是会这么认为。换句话讲,这是一种不负责任的行为。

所以一个技术人员的研发修养应该是怎样? 在这个话题分享者眼里,他认为,研发人员应该是坚持不懈,尽全力而为。另外一位分享的总工则补充,判断力也很重要。而在我自己看来,研发人员首先要不断学习,之后是对你所愿意呆的行业具备判断能力。这两点能确保你在工作生涯里的竞争力,而工作中,首先是有原则的责任感,其次是明白怎么和人打交道。原则和责任感确保你在工作中能够做出最合适、最负责的方案,而和人打交道,是大多数技术人员都有所匮乏的一环。随着项目越来越大,打交道会成为工作能力评价里非常重要的部分。

原文地址:https://www.cnblogs.com/DannielZhang/p/6946209.html