大家好，我是伟伟。我最近带了一个实习生。其实最近，已经整整三个月了，我已经在转正的过程中了。还记得他来的时候，为了亲近他，有一天我们跟他聊完之后，就跟他聊了起来。然后我说：在我们这群人里，没有必要小心翼翼。彼此交往时，没有上下级关系。敞开心扉，不要有太多的顾虑。我们的氛围很开放，需要很多交流。其实别看我多大了，我不是很老，我已经94岁了。顺便问一下，你是哪一年的？他回答：2000。那一刻真的击中了我。因为我惊讶地发现，00后也慢慢进入了职场。他们从我们90后手中接过“垮掉的一代”的接力棒后，很快就会把接力棒顺利交到10后手中。时光飞逝！反馈与思考他加入团队后，当时接到一个新的需求，遇到了一个很好的机会。为了完成这个需求，我想从头开始构建一个微服务。我让他参与项目设计阶段，最后跟着项目上线。体验了启动一个项目的全过程。对他来说，这是一个机会。对我来说，其实是一个挑战，因为这个项目整体时间不够用，分配到开发环节就更紧张了。为了保证进度，项目组紧急调了另外两个同事来和我一起做这件事，所以人手还是特别紧张。任务进度需要按天推进。领导问我：你想怎么安排这个实习生？我说：让他跟我们一起开发这个项目，我给他分配任务，上报开发资源的时候，算半个人力投入。其实，当我说“一半”人力的时候，心里是在敲锣打鼓的。因为他不是通过我面试进来的，他加入项目组大概一周时间，我连他写的代码都没看过，不知道他的技术能力到什么水平。但从最后的结果来看，其实他在项目中交出的成绩单，远远大于一半的人力。换句话说：整体表现超出预期。例如。我给他分了一个任务，把需求的背景说清楚后，让他去实现代码。在他写的时候，他会发现某处是需求没有考虑到的细节。所以他会很快给我反馈，同时会带来自己的解决方案，问是否可以这样实现。问题反馈与解决方案。听起来是一件很简单很自然的事情，但是我发现职场新人越多越好。而老油条，包括我自己，其实很多时候都做的不够好。我会拖延，我会掩饰，我会觉得没有什么不妥，我会想办法想当然地去改变……但我觉得这件简单的事情背后有好几层逻辑。第一层逻辑是：我自己发现了问题。能够找到问题起码说明你对你写的代码的背景有一定的了解。只有在了解需求的基础上，才能自主发现实施过程中的问题。一般来说，每个人都可以做到这一点。第二层逻辑是：如果发现问题，会不会有反馈？没有反馈其实从责任划分来看，即使出了问题，主要责任也不在我。我提需求的时候没有考虑这个问题。反馈上去了，终于解决了，增加了我的工作量。在这个层面上，有的同学经过激烈的思想斗争后会决定：时间来不及了，还是先做吧。没有反馈，没什么大不了的。千里之堤，毁于一蚁巢。如果项目中的小问题太多，就会出现大问题。如果真的是个小问题，你写个TODO标记在那里就算了？以防自己以后忘记。其实在大多数情况下，这样的问题在测试过程中也是可以发现的。但如果你能预测到它，为什么要推迟到测试阶段才能揭示它呢？也就是说，经过激烈的思想斗争，我决定：我知道改这个地方，我就直接改，不和别人讨论，也懒得反馈。这其实是一个很大的忌讳，很容易埋下一个坑。比如你不知道从哪里获取某个字段的值，需求没有写清楚。但是你可以自己从某个地方获取它，或者将它传递到上游。所以你决定自己去拿，而不打扰上游。因为有两个来源，即使你写代码的时候一定要强相等，但是随着系统的发展，可能会出现不同的情况，当出现这种情况的时候，这里就坑了。可能那个时候，你忘记了这个值是你从某个地方获得的，而不是从上游传下来的。出现问题的时候可以查看代码：这段代码是哪个sb写的？为什么不让上游通过？然后愤怒地看着提交历史，你开始陷入沉默。第三层逻辑是：反馈时带上自己的解决方案。在我看来，积极反馈是应该做的事情。至于能不能带来解决方案，不好说。因为有时候因为自己不能掌控大局，确实只能发现问题，而不能解决问题。所以，这一点对于新员工或者实习生不能强求，但是最好做到。比如这个实习生每次来找我反馈，说完问题，他就会说说自己想到的解决方案，问能不能做。其实很多时候他给的方案都不好，比如他想根据某个返回值做处理，但是我觉得更好的方案应该是根据数据的某个状态，或者增加一个数据库字段为了它。这个问题。这样比较符合程序设计的逻辑。他给的方案不是不能用，而是有更好的。然而，这反映了他自己的进一步思考。他还从实际情况出发，提出了很多很好的实施方案，我都采纳了。能够带来解决方案是很好的，说明你有更深层次的思考。思考和反馈，无论在哪个阶段，都很重要。有时候自己不够好，但我会这样提醒自己，要求自己。再举个例子，一个关于反馈的小例子：我给他布置任务后，告诉他什么时候做好。这期间，他会主动告诉我他有什么进步。如果他不能在预期的时间之前完成，他会提前告诉我难度是什么。这样他就可以让我及时掌控整个项目的进度，让我提前防范风险。之前也带过工作几年的同事，有时任务进度滞后，都是测试同学反映的，让我很被动。当然，我应该偶尔主动问问进度。但在我的逻辑中：大多数情况下，如果你没有告诉我或让我协调，那么我认为项目正??在按正常进度推进。我觉得如果任务有风险，提前几天反馈，但是太重要了。这应该是基本的敬业精神。至于如何定义低、中、高风险，以什么样的态度去应对，那就是另外一门学问了。同时，在整个项目开发过程中，我其实一直在给他施加压力。来来回回的试炼，我也知道他的能力还是不错的，执行力也很强。所以，在这个项目做完之后，在接下来的另一个项目中，我就给了他一堆关键节点的开发任务，告诉他这个开发任务在整个调用环节的关键意义。从目前的开发进度来看，他已经完成的很好了。老实说，一开始我只是给他分配了一些“脏活”，因为必须有人来做。作为一个新人或者实习生，即使你的技能很牛逼，但由于我不知道你的技能是什么，所以我只能从这些简单的任务开始。要说缺点的话，就是他最后拿出来的代码在功能上是可以用的。但在代码层次、代码规范、后续扩展、编程习惯等方面还存在一些不足。我从一开始就问他这些问题。从他现在提交的代码来看，是有一定的进步，但是还有很大的提升空间。现在他可能还处在刻意模仿的阶段，可能不明白为什么最后一架子的代码是这样的，反正项目里就是这么写的。因为他的代码，我每次都会重点review。事实上，每次审查都会发现编码结构中的一些问题。比如他可能把一个接口中的一个对象一路传到dao层；比如他可能每次和数据库交互都写一个新的sql去匹配，没有考虑复用性；比如，他会把很多逻辑放到同一个方法中……我觉得这对于刚进入职场的同学来说是一个必然的过程。他们已经从自己编写Demo级别的代码，变成了编写实际项目。代码的水平必然需要一个适配和磨砺的过程。这件事不是一蹴而就的，而是在反复的开发实践中磨练出来的。意识到这个问题，实践它并克服它就是成长。而且我发现他是故意模仿的，因为他看到他也会用一个大大的try-catch把整个代码块包起来，而他之前提交的代码不是这样的。有时我很懒，用一个大的try-catch包裹整个代码块。其实这样写的代码好用，但是不够优雅，不推荐。异常应该在需要捕获的地方捕获。整个方法都被包裹起来了，这是一个取巧的解决方案，说明你对自己写的代码的异常分析还没有完全完成，试图用粗暴的方式去摸底。这不好，不好。所以在发现这个问题之后，我也及时的和他沟通，同时对自己也提出了更高的要求。不要偷懒编码。坏习惯不能遗传。于是我开始慢慢意识到，这不仅是一个带新人的过程，更是一个严格要求自己的好机会。啊对。去参加他的正则化答辩会才知道原来还有导师拉票会。于是我赶紧在手机的笔记中记下几点：在我的职业生涯中，我遇到的每一个团队，每一个团队中的“导师”都对我很好，他们已经尽了最大的努力。与我分享你掌握的好东西。所以我也希望把这个好东西传下去。还记得实习的时候，从前端传入一个字段，最终会落到数据库中。它涉及几个对象在几个层之间的转换。我只是几个小时都做不好。我拉着同事坐在我旁边，他的耳机不时播放音乐。此刻焦躁的心情中，哪怕是一丁点儿音乐，都让我觉得烦躁。于是我就对他说：你能不能先把音乐关了？他听出了我的异样，关掉了音乐，说：你遇到什么难题了吗？最后，他教我如何解决这个问题。后来，我在一次吃饭的时候跟他提起了这件事：我说我当时觉得自己太坏了。这么简单的事情我几个小时都做不完，最后还得你做。他说：我不觉得你不好，也不怕你。我怕的是你自己搞定，搞不定别问我。如果你不问我，我不知道如何帮助你。有些事情超出了你的能力，你再努力也很难看到好处。有些东西是你能力范围内的东西，你应该知道但不知道的东西，那么你就应该提高自己的技能。难点在于你如何清楚地识别这些问题。比如你说的，你也应该知道，是你应该知道但不知道的，那你就应该提高自己的相关技能。你也犯过，现在又出现那个问题，应该很快就解决了。这就是成长。我带过实习生，也带过工作时间比我长的人。这行不像是一些古老的手艺，需要代代相传、传授。但是这个行业的前辈们总结出来的一些好东西，还是要传下去的。好的，让我们到此为止。
