创业感悟:工程师的自我突破

前言

第一次写非技术分享的话题,而促使我提笔的动力源自去巴黎参加Openstack Kilo Design Summit大会之行,由于我从外国工程师的身上深深感觉到了他们对于技术的执着。在本文中,我想探讨的是如何实现工程师的自我突破,由于初入茅庐的工程师更关心的是如何从一个菜鸟成长为某个领域的专家。那么这个关键的突破点在哪?前端

 

Emilien的故事

故事从一年前提及,我正在参与Puppet-Openstack社区开发和代码审查,来了一位名叫Emilien Macchi的新面孔,他持续地向社区提交了大量高质量的patch,我开始关注他,了解到他是eNovance公司(年初被RedHat收购)的一名Openstack开发工程师。他很是积极主动,我和他在Gerrit和IRC上有过许多交流。后来他加了个人Linkedin,因而我随意瞄了一眼他的profile,第一印象是惊讶:git

  1.  翔实的简历:从他的我的经历介绍中,任何人均可以迅速了解他从07年到14年专业上的经历,大学上过的课程,实习经历,工做过的公司等等全部和专业技能相关的经历,参与过的项目,拥有的证书,以及同事和上司对他工做上的评价一一具有;
  2.  最让我吃惊的是,这哥们的先前工做经验是作网络设备维护的,有一堆网络相关的证书。

他是在12年末才开始接触Openstack,13年开始专一Puppet和Openstack相关的自动化部署工做。我记得在HongKong Design Summit上,他并无参与太多的讨论,而在时隔一年后,在Paris的Design Summit上,他不只主持会议的Agenda,更重要的是他在社区作出了不少重量级的贡献,虽然他的语速很轻缓,但他的发言却变得掷地有声。程序员

一个彻底没有Openstack项目经验,一个彻底没有Python和Puppet语言基础的网络工程师如何在这么短的时间内实现自我突破?面试

会议当天恰好是他生日,会后我送给他一个从国内带去的小礼物,我好奇地问他:Hey, How do you make it ?后端

他腼腆地对我笑:I write puppet codes except eating and sleeping.服务器

Wow.  我和边上的人都在惊叹。网络

他走后,我站在法国国际会议中心的Room 101门口思考了很久。架构

故事到此就结束了,细节可能不止这些,但这并非本文的重点。我想就此去谈谈工程师如何去摆脱固定思惟的束缚,突破自我。运维

OLYMPUS DIGITAL CAMERA

图1:  Emilien Macchi在主持Puppet-Openstack Kilo Design Summit工具

态度决定一切

有句老话叫做:态度决定一切,你的态度如何,在必定程度上已决定你是失败仍是成功。我以为这点在作技术时体现得淋漓尽致,就以Openstack项目为例,在其中发现一个bug,其实不是难事。那么在发现某个Openstack服务的bug时,不一样的工程师有着不一样的态度:有的人随意Google一下找到解决方法而后接着干活,有的人尝试阅读源码后去自行修复bug,有的人会把写好的bugfix尝试推送到社区的upstream去。咱们都会以工做太忙为理由,只以问题的解决做为目的驱动,从不去细究问题的源头。所以,这就致使了若干年后,有的工程师还只在原地踏步,有的已经不只深刻掌握源码,还能快速地作二次开发,还有的人不只养成了良好的代码风格,还能积极地参与到upstream的开发中去。

记得在刚进入Sina云计算部门的时候,团队协做平台的副标题是28号加粗的一行文字:Develop is not easy。虽然不知道是哪位大牛写的,直到如今我仍然记忆犹新。Develop不光狭义地指开发,而是囊括了全部的技术岗位,咱们要时刻清晰地认识到把事情作好并不是易事。这里不只指技术自己,还涉及许多相关的细节,这些细节经常被多数工程师忽略,而正是这些细节才能体现出一个工程师的闪光点。

我常使用业务素质一词来评论工程师:这个工程师的业务素质很高,指的是他不只在专业技能上出类拔萃,更重要的是在作事上很是认真,事无巨细,小到代码格式,注释,变量名称,代码提交信息,文档等每一个细节都能体现出认真两字有多么可贵难得。凡是作过技术的朋友应该都会有所共鸣,而且从脑海中立马浮现出那些闪闪发光的人名来。

 

保持努力

我不想在努力这一点上举例来讲明努力是多重要的因素,由于咱们从小就开始灌输努力的重要性。我只想强调在正确技术突破的道路上,你必须不停地更新本身的知识和技能,才能越走越远。

我认识的另外一位朋友,社区核心开发者,我询问他圣诞节打算去哪里过,他给个人回答是:I'm not going anywhere, just writing codes at home. 因此,那些外国工程师之因此如此牛逼,并不是他们生来如此,而是他们的不懈努力。

因此请必定要作到保持这份干劲,而且时不时买些心灵鸡汤激励一下本身,或者按老罗所说:恶心一下本身,保持大脑亢奋。如今我脑子里只要一想到Emilien的那句“I write puppet codes except eating and sleeping“,就开始失眠,这鸡血的剂量使得个人生物钟又延时了一个小时。

 

充满热情

在我认识的技术人中,作得出色的人大都有一个相同特色:富有激情,他们总以一种积极主动的态度去对待生活和工做。我相信全部刚入IT行业的同窗们都是满怀对于将来的憧憬,只是这种弥足珍贵的热量很容易被许多外界的负面因素慢慢磨灭:工做单调乏味,生活压力太大…但不要所以就把你的热情埋藏起来,一旦你习惯了埋藏,你将是一个了无生气的人。若是你失去了对于追逐技术的热枕,那么很难在技术的道路上有所突破。激情,在不少时候,每每能点燃咱们创新的本能。有了激情就有了不竭的动力,你的心里同时也会变化,愈加有信心,别人也会逐渐认识到你不同凡响的价值。

 

善于沟通

工程师们经常把精力放在编码上,而不多去关注本身沟通能力的培养。我曾遇到过一些大牛,有的不屑写文档,有的不会用git等团队协做工具,还有的连话都说不清。不可否认他们在本身各自的领域中耕耘得很深,可是在分工如此细化的时代,大多数项目都须要团队协做才能完成,所以沟通是没法避免的:产品经理和设计师之间的沟通,后端组和前端组之间的沟通,研发部和运维部之间的沟通…为何有时候对方听不明白咱们想表达的意思,致使跨部门的工做步履维艰。

TED上有个有趣的演讲题目叫做:怎么说话人们才听,声音学专家朱利安给咱们上了生动的一课,列举了为何没人愿意听咱们说话。所以,咱们在与别人打交道的时候,咱们必须明白对方在想什么,也要让对方明白咱们想表达什么。

除此以外,对于工程师而言,沟通能力并不局限在语言沟通上,还有在协同开发时的沟通,例如对于使用git作版本控制的项目,如果没有掌握好git工做流,沟通将异常困难。代码审查系统上的交互,也是沟通方式的一种,你须要理解他人给你的意见,你可以向他人表达清楚你的意思。

 

了解本身,把握方向

在大学课堂里,工做面试和入职培训时经常能听到一个词:职业规划,就是对职业生涯乃至人生进行持续的系统的计划过程,它包括职业定位、目标设定、通道设计三部份内容。职业定位主要是指:一是肯定你是谁,你适合作什么工做;二是告诉别人你是谁,你擅长作什么工做。人生是应该有一个规划,这样能够对于将来设立一个指望,明白前进的方向。但这类职业规范每每过犹不及,觊觎经过把本身的人生画在纸上,而后按图施工的想法是不切实际的。仔细想一想你真的能在刚踏入社会时就能真正了解你擅长作什么工做,适合作什么工做?

乔帮主说过一句话:“若是你了解本身,可以明白地作本身,职业规划如同虚设”。因此,你只要清楚本身想要什么,而后朝着这个目标去作本身想作的事,就能够了,为何要给人生设限?何不尝试一下跨界?

前文中我谈到了一个网络工程师的华丽转身,接着聊一聊咱们运维团队从UnitedStack成立伊始到如今发生的故事。

从理想国际大厦走出来开始创业的第一天,一个现实摆在了咱们面前:采购服务器和交换机,选择IDC。在新浪,服务器选型有专门的部门作,采购硬件有专门的部门作,交换机配置有相应的部门作,服务器上架有相应的部门去作,咱们只有基础运维和业务运维的经验,原先所擅长的只是一个狭小的领域…

看来惟有本身动手,才能丰衣足食,咱们着手开始调研服务器的选型,交换机的配置,IDC的选择。经过不断的摸索,如今咱们制定了一套成熟的机制去根据不一样业务来选型服务器,造成了一套完善的网络拓扑去链接分布在全国多个机房的公有云和托管云集群,也有了稳定的IDC合做伙伴。

许多朋友可能还记得UnitedStack去年发布的UOS 1.0发行版,其后端代码彻底由运维组编写。当时,咱们转身从运维变成研发,调研了主流的StackOps, Fuel Web,根据产品设计的需求,开发了一套由Python+Puppet编写的后端代码,实现了Openstack集群的自动化部署;内部的持续集成&持续发布系统也全由运维组负责,咱们根据研发工程师的实际需求对持续集成工具链作了屡次整合以匹配整个研发体系的平常工做;14年初公司业务开始涉足公有云和托管云,咱们和研发部门共同设计了公有云,托管云的总体架构。因为业务量的急剧上升,咱们着手开发了资产管理,节点管理等多套运维平台。同时,和通常的运维团队不一样,咱们还负责虚拟服务器的镜像自动化制做和维护,参与Openstack最庞大的计算项目Nova的定制开发并一直保持与社区upstream同步,参与puppet-openstack社区的开发,一直在向社区贡献源码。

由于咱们清楚所作的一切都是为了能把“事”作成,所以作什么并不重要。并且经过这两年的磨练,咱们在技术上最大的收获在于你们的视野再也不局限于各自的一亩三分地里,在面对新问题时,能够站在不一样的角度去思考,这种在大公司里没法得到的经验就显得弥足珍贵。所以了解你本身,明白你本身想要什么,而后把握好方向。

 

全面 vs. 专精

以部署系统为例,早先的部署系统彻底为公有云打造,要求作到细粒度控制,但操做起来比较繁琐;而如今要求同时管理公有云和数量庞大的托管云集群,而且每家在架构上都会有所差别,这就要求部署逻辑解耦,灵活可变,支持不一样环境,不一样拓扑,不一样软件栈,还要解放实施人员,减小部署时间。

但因为每一个人的精力都被分散到多个领域,所以很难集中精力把部署系统作好,因而咱们开始从多面手向专注转变。也正是由于这两年咱们什么都作,猛然一回头你们有些迷茫:本身什么都懂,但又什么都作不精。那么问题来了,学技术究竟是…究竟是精通一种仍是全面发展好?

Take it easy,在技术的道路上看似会有两种大相径庭的方向:横向扩展和纵向深刻。横向的犹如瑞士军刀,十八般武艺样样精通;纵向的是削铁如泥的倚天剑,倚天不出,谁与争锋。横向扩展能够拓宽你的视野,让你再也不局限在某一种技术中,并也给你的将来多了一种可能;而纵向扩展,可使用你深入理解一项技术的细节,让你静下来思考问题的本质,你可能会惊讶地发现某些原理都是相通的。这两个方向都没有对与错,发展到必定程度都会相互溶合,就比如中国佛家禅修的南顿北渐,其实到了最后,渐悟与顿悟是同样的,顿由渐中来。

不过哪一个在前,哪一个在后,我我的认为仍是先作到对某一个领域有较深的理解和掌握后,进而去学习其余方向,这个道理就如同精通一门语言的程序员再去学习其余语言时就能驾轻熟路。

关于这两点的结合,我有很深的印象,如上面提到的状况,刚开始的时候,运维相关的事情繁杂,每一个人都得是多面手,要去cover多个领域,也由于此只能把每件事情作好而没法作精。在集群规模不断扩大和业务量的增加后,原先不是问题的地方开始暴露出来,这就有精通该领域的工程师来独挡一面。这是一个自我学习,自我改变的过程,也是自我突破的关键。

 

结尾

在互联网的浪潮下,产品在快速地推陈出新,技术在不停地推陈出新,在这种大环境下,人心趋于浮躁,每每很难静下心专心作技术,惟有耐得住寂寞,才守得住繁华。

但愿诸位在面对机遇和挑战时,可以发掘自身的瓶颈,实现自个人突破。

相关文章
相关标签/搜索