我带的实习生，转正了。

你好呀，我是歪歪。

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

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

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

他答：2000年。

那一刻其实有冲击到我。

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

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

岁月如梭啊！

反馈和思考

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

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

对他而言，是一个契机。

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

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

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

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

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

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

举个例子。

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

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

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

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

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

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

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

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

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

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

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

第二层逻辑是：发现了问题，到底反不反馈？

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

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

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

千里之堤毁于蚁穴呀。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

再举个例子

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

这样不好，不好。

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

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

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

哦，对了。

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

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

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

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

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

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

于是我给他说：能不能先把音乐关了？

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

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

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

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

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

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

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

好了，就写到这里吧。