查看原文
其他

我带的实习生,转正了!

歪歪 why技术 2022-09-10

你好呀,我是歪歪。

我最近带了一个实习生。其实说最近,也都整整三个月了,已经在走转正流程了。

还记得他来的时候,为了和他套个近乎,有一天聊完正事之后,和他拉了拉家常。

然后我说:在我们组里面,不必拘谨,大家在平时沟通的时候也没有上下级的关系,敞开心扉,不要有太多顾虑。我们的氛围是很 open 的,多多沟通。其实你别看我长的老,我年龄也不大,我 94 年的。对了,你哪一年的?

他答:2000年。

那一刻其实有冲击到我。

因为我惊奇的发现,原来 00 后也慢慢的走入职场了。

他们从我们 90 后手中接下“垮掉的一代”的接力棒后,马上就要顺利的把接力棒交接给 10 后了。

岁月如梭啊!

反馈和思考

他加入团队之后,遇到一个很好的契机是刚好那个时候接到一个新的需求,为了完成这个需求,我要从 0 开始搭建一个微服务。

我让他从项目设计阶段就参与了进来,最后跟到了项目上线。体验到了一个项目上线的全流程。

对他而言,是一个契机。

对我而言,其实算是一个挑战,因为这个项目的整体时间给的不算充裕,分配到开发环节那就是更加紧张了。为了保障进度,当时紧急从项目组里面抽调了另外两位同事和我一起专门干这事,就这样人力资源还是尤为紧张。任务进度需要按天为单位进行推进。

领导问我:这个实习生你想怎么安排呢?

我说:让他和我们一起开发这个项目吧,我来给他分配任务,汇报开发资源的时候算半个人力投入。

其实,我说“半个”人力的时候,自己心里都在打鼓。因为他并不是通过我面试进来的,加入项目组大概一周多时间,我甚至都还没见过他写的代码,不知道他的技术能力在什么水平。

但是从最终的结果上来看,其实他在项目里的交出的成绩单是远大于半个人力的。

换句话说就是:整体表现是超出预期的。

举个例子。

我给他拆分一个任务,讲清楚需求背景之后,让他去落地代码。

他写着写着会发现某个地方是需求没有考虑到的细节问题。

于是他会很快的反馈给我,同时带着自己的解决方案,问这样去实现可不可以。

带着解决方案的问题反馈。

听起来是一个很简单、再自然不过的事情,但是我发现在职场中越是新人做的越好。

而老油条们,包括我自己,其实很多时候都做的不够好。会去拖、会去掩盖、会觉得这其实也没啥大毛病、会去自己找个想当然的方案就改了...

但是我觉得这个简单的事情背后有好几层逻辑。

第一层逻辑是:自己发现了问题。

能发现问题,至少说明你对自己写的这段代码的背景有一定程度的了解。

只有在需求了解到位的基础上,才能在落地环节自主的去发现问题。

这一层,一般来说大家都可以做到。

第二层逻辑是:发现了问题,到底反不反馈?

不反馈其实从责任划分的角度,就算出了问题,主要责任不在我呀,当时提需求的时候就没有考虑到这个问题。

反馈上去了,最后解决起来,增加的是我的工作量。

到这一层,有些同学就会经过激烈的思想斗争后决定:时间来不及了,先就这样吧。不反馈了,不是啥大问题。

千里之堤毁于蚁穴呀。

在项目里面小问题多了,是会出大问题的。

如果真的是很小的问题,哪怕你打个 TODO 在那里标识一下呢?防止自己以后也遗忘了。

其实大多数情况下,这样的问题在测试环节也能被揪出来。

但是如果自己能预判到,为什么要延迟到测试环节才暴露出来呢?

或者说经过激烈的思想斗争后决定:这个地方我知道怎么改,直接改了就行了,就不和别人商量了,懒得去反馈了。

这里其实就是大忌,很容易埋坑的。

比如就是一个字段你不知道从哪里取值,需求上也没有明说。但是你可以自己从某个地方取出来,也可以由上游传递过来。

于是你决定自己去取就行了,不麻烦上游了。

因为来源有两处,哪怕在你写代码的当时这两处来源他们一定是强相等的,但是随着系统的发展,也许会出现不一样的情况,而当这样的情况出现的时候,这里就是坑。

也许到那个时候,你自己都忘记了,这个值是你去某个地方获取的,而不是由上游传递下来的。

当这真的出现问题的时候,你一查代码:这是哪个 sb 写的代码?为什么不让上游传递进来呢?

然后气冲冲的一看历史提交记录,你就开始默不作声了。

第三层逻辑是:反馈的时候带着自己的解决方案。

在我看来,主动反馈是应该必须要做到的事情。

至于能不能带着解决方案,难说。

因为有的时候由于自己对于全局的把控不到位,确实是只能发现问题,不能解决问题。

所以,这一点对于新员工或者实习生来说不能强求,但是能做到那便是最好不过的事情了。

比如这个实习生,每次来找我反馈问题的时候,说完问题之后就会说自己想到的方案,问能不能这样做。

其实很多时候他给的方案并不好,比如他想根据某个返回值去做处理,而我觉得更好的方案应该是基于数据的某个状态去做,或者说加个数据库字段专门来干这事。

这样更加符合程序设计的逻辑。

他给的方案不是不能用,是有更好的。

但是,这里面体现了他自己的进一步思考。

而从实际情况来看,他也提出了很多很好的实现方案,被我采纳了。

能带着解决方案,说明自己有更深一步的思考,挺好。

思考和反馈,不论是什么阶段,都很重要。

我自己有时候都做的不够好,但是我会这样常常提醒并要求自己。

再举个例子

再举个关于反馈的小例子:

我给他分配完任务后,告诉他什么时候之前要做好。

在这期间,他会主动告诉我自己做到什么进度了。如果自己在预期时间之前做不完,他会提前告诉我困难是什么。

他这样会让我及时掌控到整个项目的进度,让我提前预防风险。

我之前也带过工作过几年的同事,有时候任务进度滞后,都是由测试同学反馈上来的,会搞的我很被动。

当然我也应该偶尔去主动询问进度。

但是在我的逻辑里面:大多数情况下,你没说,没有找我协调,那么我就认为项目是按照正常的进度在推进的。

我觉得任务如果有风险,提前几天反馈,可是太重要的事情了,这应该是基本的职业素养。

至于怎么去定义风险的低中高,从而拿出什么样的姿态去应对,那就是另外一项本事了。

同时在整个项目开发的过程中,其实我是不断在给他施压的,在有来有回的试探中,我也知道了他的能力还是不错,有很强的执行力。

所以,在这个项目完成之后,紧接着的另外一个项目中,我给了他一坨关键节点上的开发任务,并告诉了他这个开发任务在整个调用链路上的关键意义。

从目前的开发进度上看,他完成的还是很不错的。

老实说,最开始的时候我就是给他分配了一些“脏活累活”,因为这些事情必须有人做。

做为一个新人或者实习生,即使你有翻天的本领,在我不知道你能力到底如何的情况下,只能从这些简单的活儿开始试探。

如果要说说不足之处的话,那就是他最终拿出来的代码,从功能上来说是可以用的。

但是从代码分层、代码规范、后续扩展、编程习惯上来说,还是有所欠缺。

这些问题我从最开始就给他提出来了。

从现在他提交的代码上看,有一定的进步,但是还有很大的提升空间。

现在他可能还处于刻意模仿的阶段,也许理解不了为什么代码最后的架子是这样的,反正项目里面就是这样写的。

由于他的代码我每次都会重点 review,其实每次 review 都会发现一些编码结构上的问题。

比如他可能会把一个接口中的对象一路传递到 dao 层里面去;比如他可能会在每次和数据库交互的地方都写一个新的 sql 去与之匹配,没有考虑到复用性;比如他会把非常多的逻辑都放到同一个方法里面...

我觉得对于刚刚走进工作岗位的学生来说,这是一个必然的过程,他们从自己的 Demo 级别的代码,转变为写实际工程级别的代码,势必需要一个适应和磨砺的过程,这个事情不是一蹴而就的,就是在反复的开发实践中锤炼出来的东西。

能意识到这个问题,并加以练习和克服,就是成长。

而我发现他刻意模仿,是看到了他也会用一个大的 try-catch 把整个代码块包裹起来,而他早期提交的代码并不是这样的。

我自己有时候偷懒,会用一个大的 try-catch 把整个代码块包裹起来。其实这样写出来的代码好用,但是不优雅,也不推荐。

异常应该就在需要捕获的地方捕获就行,整个方法包裹起来,是一种取巧的方案,说明你对自己写的代码的异常分析没有绝对的到位,企图用一种粗暴的方式来兜底。

这样不好,不好。

所以发现这个问题后我也和他及时沟通了,同时也对自己提出了更高的要求。

在编码上不能偷懒。不能把一些坏习惯传递下去。

所以我开始慢慢意识到,这不仅是一个带新人的过程,还是一个严于律己的好机会。

哦,对了。

我去参加他的转正答辩会的时候才知道,还有一个导师拉票的环节。

于是我在手机便签里面匆匆记录了几点:

传递

在我的职业生涯中,我遇到过的每一个团队和每一个团队里面的“导师”,对我都非常的好,他们竭尽所能的把自己掌握的好的东西分享给我。

所以我也希望把这一份好的东西一直传递下去。

犹记得我当年实习的时候,前端传进来一个字段,要最终落到数据库里面去,中间涉及到好几层之间的几个对象的转换,我硬是弄了好几个钟头都没有弄好。

带我的同事坐在我的旁边,音乐时不时的从他的耳机里面传出来。在当下那个焦急的情绪下,一丝丝的音乐都让我觉得烦躁。

于是我给他说:能不能先把音乐关了?

他听出了我的异样,把音乐关了,然后说:是不是遇到什么棘手的问题了?

最后还是他手把手教我怎么解决这个问题。

后来有一次吃饭我给他说起了这个事:我说我觉得那个时候的自己好差劲啊,这么简单的事情搞了好几个小时都没搞定,最后还得你出马。

他说:我并不觉得你差劲,而且我也不怕你差劲。我怕的是,你自己吭哧吭哧的搞,搞不定了还不问我。你不问我,我就不知道怎么帮你。有些事情,是你能力范围外的事情,你再怎么使劲,也很难看到收益。有些事情,是你能力范围内的事情,你应该会而不会的事情,那你应该去精进自己的技能。难的是你怎么去清晰的识别出这些问题。比如你说的这事,你应该也知道,就是属于你应该会而不会的事情,那么你就应该去提升自己的相关技能。你也去做了,现在的你再次遇到那个问题,应该很快就解决了。这就是成长。

我带过实习生,也带过工作年限比我高的人。

这一行不像是一些老手艺,需要有人传承,一代一代的教。

但是这个行业里面有前人总结出来的一些好的东西,应该传递出去。

好了,就写到这里吧。

最后说一句

好了,看到了这里了,转发、在看、点赞随便安排一个吧,要是你都安排上我也不介意。写文章很累的,需要一点正反馈。

给各位读者朋友们磕一个了:

本文已收录自个人博客,欢迎大家来玩。点击[阅读原文]即可直达。

https://www.whywhy.vip/

推荐👍 :劝退别人学计算机的人,都是王八蛋。

推荐👍 :绝了啊!无数网友正在曝光他们公司这事...

推荐👍 :CompletableFuture其实也就这么回事。

推荐👍 :不就是搭个博客吗?其实很简单的...

推荐👍 :送你一个并发编程的奇淫巧技,舒服的很...


··································

你好呀,我是歪歪。一个主要敲代码,经常怼文章,偶尔拍视频的成都人。


我没有进过一线大厂,沒创过业,没写过书,没进过大厂,也不是技术专家,也没有什么亮眼的title。


当年以超过二本线 13 分的优异成绩顺利进入某二本院校计算机专业,误打误撞,进入了程序员的行列,开始了运气爆棚的程序员之路。


说起程序员之路还是有点意思,可以看看。点击蓝字,查看我的程序员之路

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存