职场新人总结一下新入职程序员的各种经验教训

转一下好文:

楼主是作为new grad入职G家接近半年的程序员,犯过各种各样的错,有时候还难免惹烦同事,这里总结一下职场新人的一些经验教训,有些地方我依旧还没做好,希望以后能有进步。以下不讨论任何公司内部信息。

★1.多熟悉企业内部平台和工具

大公司一般都会有自己内部使用的开发平台和工具,跟平常用的可能不完全一样,比如说我自己平时用Git操作比较多,经常在Github里上传下载各种代码之类的,但是当我到了我们公司就发现他们都不用外面的这些东西,内部会有自己的版本控制系统和开发环境等等,包括代码提交和审核流程都有一套规范,新人刚来肯定会有各种不习惯,但也只能强迫自己努力适应和熟悉相关操作。

我就比较“慢热”,接触这些内部的新东西总是很慢,甚至花了很久才弄明白怎样使用命令行的build,run,test操作,带我的mentor也多次提醒我要尽量熟悉开发环境。当然,随着新人参与的project变多,干的活儿多了对这些基本操作也就慢慢熟了,但是自己平时多研究一下总还是比让别人反复提醒要好,至少能留下一个不错的最初印象,让其他人感受到自己有一定的学习能力和适应能力。

★2.养成看文档和看源码的习惯

因为公司里有各种各样的平台、工具、可供调用的API,而程序员参与的项目往往会用到多种编程语言、多种工具和库,很多可能是自己以前从未用过的,这时就需要依靠看文档和看相关的代码来熟悉。我以前看到这种大段的英文说明书文档就会产生畏惧心理,看了一半经常就会走神感觉看不下去,现在我渐渐开始换一种心态来看这些文档:其实人家费心思写这些说明文档就已经很不错了,而且很多文档还附带入门实例有实际的代码调用例子供参考,这总比我自己去看他们这些库的源代码来琢磨怎样调用更加轻松吧?所以要怀有感恩之心来看这些文档啊。如果看了一遍没看明白就过段时间再慢慢看一遍,也不用急。

很多时候老板或mentor给我分配了新任务,我往往内心就是急着要开始写代码把它搞完,但事实上等真正开始干了才发现很多要用的工具自己完全不会用,这时候也只能耐心地去看那些文档来熟悉,急也没用。老板也跟我说过,我们公司大多数时候并不需要员工很快地把事情做完,其实更多时候是要“透彻”地把它做完,就是把用到的相关工具和这个任务产生的前因后果等等东西尽量都弄明白,能够有更深入的理解。

当然,有些小工具比如某些公司内部的库函数可能根本就没有文档,这时候只能靠看源代码来琢磨怎样调用这些函数。至于为什么一定要调用这种几乎无人问津的函数,请参阅第3条“不要重复造轮子”。我刚开始看这些源代码的时候也还是有畏难情绪,心想这么高深的代码,我肯定看不懂的吧!后来开始慢慢转变心态,其实对于我要调用的函数,我并不需要太关心它是怎么实现的,我只要知道它大概是干啥的,输入格式是什么,输出格式是什么,这样就足够我调用了。当然我最好还是多瞧几眼,学习一下他的实现方法,但实在弄不懂就算了。有的时候因为这些代码写得比较繁琐,我可能连输入输出的数据格式都看不太懂(比如C++里面各种template和smart pointer,很容易把我弄晕),这时可以试着在公司的代码库里尝试搜索其他人调用这个函数的代码,照着别人的方法调用就可以。如果连这也搜不到,那还是及时问一下同事,避免耗费太多时间。

★3.不要重复造轮子

很多常用的函数往往别人已经写好了,这时候尽量不要自己写,直接调用别人写好的函数。这样做最主要的好处是维护整个公司代码库的清洁,减少冗余的代码,便于维护,打比方说如果那个要调用的函数本身逻辑需要改动,而所有人都是在调用这个函数,那么只需要把这个函数改一下就行;但如果这个函数被不同的人在不同的地方写过好几次,你调用你写的,我调用我写的,而现在需要改动这个函数,那么就需要所有人都把自己写的函数改掉,如果有的人忘了改那他那部分代码就会出错。

比如之前我写的代码里需要根据输入数据里某个field的值来判断它是哪种类型的数据,我最开始是自己定义了一堆常量然后用条件判断,当这个field的值是"AAA",“BBB”,“CCC"的时候认定它是X类型的,当它的值是"DDD”,“EEE”,“FFF"的时候认定是Y类型的,如此等等。后来我的同事在review我的代码的时候就对我说,这个地方不要自己写这种判断逻辑,因为肯定有其他人也需要做这种判断,一般都会有已经写好的函数来判断,我应该去调用已有的函数。我在代码库里还费了些时间去搜索,总算搜到了对应的函数,然后把我的代码改了过来。因为目前我们判断当那个field的值是"AAA”,“BBB"或"CCC"的时候认为它是X类型,也许以后某一天就变了,变成当这个field的值是"AAA”,“BBB”,"FFF"的时候才认定它是X类型,那么如果我们大家都是调用的同一个函数来判断,就只需要改动那个函数本身就行,我自己的代码都不需要改动。反之,如果我自己另写了这一段条件判断的代码,那么我自己还要专门改一下我的代码,而事实上我可能以后完全忘了要改这个地方,那就会出bug。

★4.遵守代码规范

在公司里写代码跟在学校里写课程project不一样,需要遵循相应的代码规范,具体规则可能每家公司不一样,比如在公司里可能规定Java代码的变量命名要遵循驼峰命名法并且首字母小写(例如变量myEnglishScore),C++和Python要用下划线分割命名并且所有字母全部小写(例如my_english_score),函数名则采用驼峰命名并且首字母大写(例如GetMyEnglishScore),在每个函数定义的上方需要有注释说明这个函数是干什么的,等等。我们公司的系统甚至还能检测代码注释中的语法错误,比如你第三人称单数没有加s,或者单词拼写错了,都会提醒你改正。

刚开始的时候可能有很多规则让自己感觉不习惯,这只能说入乡随俗强迫自己适应,如果自己提交审核的代码总有这种不符合公司规范的地方以至于让别的reviewer反复留下相似的comments,这肯定会让其他同事对你的印象非常不好。像我之前给函数起名字的时候就经常把名字起得很抽象,比如"ProcessKeyValuePair"这样,同事就告诉我这名字一定要设定成很清晰的名字让别人一看就明了,例如"ConvertIdCountPairToList",因为原先的"KeyValuePair"就很模糊,这里就直接说明是把user id和count这种类别的key-value pair转换成list输出,就更加清楚。

★5.培养写文档的习惯

老板之前经常跟我说做过的project最好都写个文档记录一下,一方面是让自己记录一些比较重要的技术细节和debug的方法供自己以后参考,毕竟如果不记下来,以后我肯定会忘光的;另一方面也是供其他可能要做类似工作的人参考。尤其是一些比较难解决的bug,如果记录下来了那以后可以给自己和其他遇到相同bug的人省掉很多折腾的时间。

我刚开始写的一些文档上下文非常不通畅,过了一两个月当我再去读自己之前写的文档也的确感觉实在写得太差,可以说是狗屁不通,我的同事也跟我说尽量把文档polish一下。我也感觉到教科书里那些文段真是经过反复斟酌写出来的,如果像我这样随意地写出来那真是连读都读不下去。于是我只能自己把自己写的东西通读几遍,感觉不通畅的地方再改一下。码农不能只会写代码,尤其当以后级别慢慢提升了,书面表达和口头表达能力都需要提升,因为我们会越来越多地需要向其他人阐述我们的工作内容或者解释新的idea等等。

★6.注意职场礼节

工作的时候经常要跟其他人打交道,偶尔犯错在所难免,但尽量不要让别人第二次指出自己相同的错误。比如有一次我准备提交一些代码,先要申请review,这部分代码牵涉到我们组和另一个组的工作内容,需要我们组的A君和另一个组的B君都review通过之后才能提交。我当时就向这两个reviewer发出了review申请,结果另一个组的B君回复说先让我们本组的reviewer审核通过之后再让他来review。我按照他说的先请A君审核了我的代码,审核通过之后我再向B君发出了review申请,最后他审核通过了。

过了几天,我发现有几个地方的代码需要修改一下,要改动的地方不多,我感觉也没啥问题,改了几行就打算交上去了,因为这些代码也是涉及到两个组的工作范围,所以我又一次向A君和B君发出了review申请。这时A君快步走来对我说,上次那个B君就让我先等本组的人审核通过之后再让他review,这次我又直接给他发出review申请,这肯定会让别人对我印象非常不好。于是我赶紧撤下了对B君的reivew申请。一般来说,如果准备提交的代码需要多个团队的人审核,那么往往是先让自己团队的人审核通过,再让其他团队的人审核;先让较低级别的员工审核通过,再让高级别的员工审核(往往那些senior员工有一大堆代码要review可能会拖得比较久,这样做既是在帮忙减少他们的工作量也是在加快我们自己代码审核通过的速度)。俗话说“家丑不可外扬”,如果你要提交的代码里有一些低级错误,那么先让自己组里的人指出改正总比一下子让其他组的人和老前辈(大老板)们全看见了要好吧。

说到review这里就多聊几句,当新人对自己的工作领域慢慢熟悉之后,也会渐渐开始去review其他人的代码,审阅的时候应该尽量细心一点。我的mentor有一次向我发出了一个review申请,主要是让我多尝试一下review别人的代码,这代码的改动总共有三四百行(包括引用头文件,注释,测试代码等等),我当时只是看了个大概,瞧了瞧他每个函数是干啥的,代码看起来似乎也很规范,过了半个多小时,我点击了审核通过的按钮。结果我mentor过来跟我说,我应该认真review别人的代码啊,这么大段的代码连他都要review很久,如果我感觉自己没有能力review可以把自己从reviewer list中删去,既然要review别人的代码就要看仔细一点。于是我汲取了教训,以后只能更加谨慎地审阅别人的代码,如果只是几行代码的小改动那可以很快审核通过,但如果是几百行的大改动那就不要一下子直接approve了(可能三四个小时是比较正常的吧),会让别人感觉自己很不尽职,还是要多花点时间看看。假如别人提交上去的代码有错误,而我是其中一个审核通过的reviewer,那么我也是负有一定责任的。

★7.尽力融入集体

这一点我一直做得不好,不管是以前实习还是现在全职,在团队中都显得比较沉默。平时有空的时候还是应该偶尔和小组其他成员聊聊,知道他们在干什么,也许会有自己感兴趣的project可以参与。要说我身上发生过的比较冏的事情,有一次就是去年在某金融公司实习的时候,工程部门举行员工hackthon的活动,实习生和全职员工一起参加,自由组队,我们小组的一些成员包括manager在内就组成了一队,比赛开始后我们要做个简单的应用,打算以网站的方式展示,然后manager作为队长就给每个人分配了一点任务。当时是让我把网页前端写一下,就是很简单的一个html页面,我完成后把代码提交给了manager,然后我就不知道该干啥了,看了一会儿其他成员在做的事情,他们一边写着代码一边聊着天,而我看着看着感觉有点累了就直接趴桌上睡大觉了…的确有点作死啊…当时manager没说啥,后来过了几天他跟我一对一谈话的时候就说,有时候他觉得我比较disengaged,不是很融入集体,比如之前hackthon的时候我干完活儿就直接"shut down"了,不怎么跟其他人交流。

几乎所有的公司都很注重员工是否具有team work的能力,而融入集体、保持跟其他人经常性的沟通的确是team work的一个重要因素。

★8.谦逊勤劳,踏实肯干

其实这是最重要的一点,哪怕你在其他方面有各种大大小小的缺陷(当然人品缺陷不能有,诚实守信是底线),只要你能保持一份谦卑好学的态度,努力按时完成他人分配给你的各种任务,那么大家就会觉得你至少还是个可塑之材,不至于到放弃治疗的地步。可能新人被分配到的任务会比较杂,有时候会是一些琐碎的小任务,这时候不要挑三拣四,尽力把一件件事情都做好就行,多在这过程中学习一下内部的系统运作机制,各个模块的原理等等。不过,如果你干了一年多发现自己依旧是在打杂,没有真正有分量的project,那可以考虑换组或者跳槽了。

我基本上还是一直保持着谦卑的态度工作(也有可能是以前自卑惯了),但偶尔也会表现得有些骄躁,比如在别人批评自己的时候进行顶撞或者设法为自己辩解,这简直是一种下意识的反应。有一次我的mentor看了我写的代码,向我指出代码中一些不规范的地方,结果他每指出一个地方,我就会向他解释一下为什么我那样写,表现出一种不想再改代码的感觉,尤其是对于其中一处问题他指出后我直接说“我看别人也是这样写的呀,所以我就这样写了”,当然我也意识到这个argument非常没道理,别人写的也不一定规范。我的mentor说:“哎,你不要反抗啊,我这是让你知道正确的写法,本来你的代码写得再差也跟我没关系,我这是指出你可以改进的地方。”

为了让自己不再有这种下意识的“反抗”,以后每次跟同事说话在开口之前最好稍微思考一下,什么样的话是应该说的,什么样的话最好不说。说话和提问都应该先动动脑,本来这也就是长辈们经常教导年轻人的事项。

另外完成任务时需要注意的就是细节,我的manager跟我说过不注重细节的后果,他画了个时间轴,也许在某个时间点上级安排了个任务给我,过了一段时间我提交了代码,任务解决,结果又过了一段时间,every thing is broken,我们只能把当初我干的事情推倒重来。他说,我们不需要试图很快地把事情做完,而是应当注重细节,努力把事情的方方面面很透彻地办完(似乎这跟facebook的理念不太一样),这样其他人就会感觉到我是个可靠的人,以后也才会有更多的机会,才能赢得更好的评价和更快地升职如此等等。反之,如果忽视了细节经常出现各种bug,上级可能就不太会把重要的项目分配给自己,个人发展空间也就变小了。

★9.拓宽视野,保持野心

从员工长期发展的角度来说,每个人也不能始终只满足于完成上级分配的任务,当新人慢慢成长为有一定经验的老员工后,他对内部系统各部分的认识会加深,有时应该努力从更宏观的角度去考虑如何改善目前的工作机制或添加怎样的新功能。我的mentor跟我说,刚开始我只是去完成别人安排给我的任务,但我慢慢地也要主动去了解其他相关的业务,比如小组内其他同事正在做的project,能够提出自己的idea,去drive一些新的project。当然不同的公司风格不同,有的公司会鼓励这种从下而上的决策方式,就是由工程师们提出新想法,然后上级领导审核同意之后启动相应的新项目;有的公司可能还是传统的自上而下的决策方式,领导说要干啥就干啥。无论公司怎样,都不应该让琐碎的工作完全淹没自己,需要有一点野心,观察和思考周边的事情,时时准备着提出新的idea来产生更多的impact。

1 Like