我指导初级开发人员的经验

对于任何成功的公司来说，妥善地指导和培养初级开发人员至关重要。

遗憾的是，许多公司对这一过程重视不足，期望初级员工从第一天起就能高效工作，却很少提供支持。他们的上级和经理忙于完成项目，无暇在初级员工身上“浪费时间”。

他们不明白的是，这段时间不是“浪费的时间”，而是对公司未来的投资。

由于这些糟糕的流程，许多有才华的开发人员流失了。

从我担任软件工程师之初，我就一直与初级开发人员密切合作。

在这篇文章中，我将分享我的经验，并给出一些我认为可以帮助你成为一名优秀导师的建议。

我的故事以及我与低年级学生的初次接触

我的第一份工作是在一家小型创业公司，我在公司工作不到两年，他们就决定从大学招一些实习生来进行为期六个月的实习。

当时我入行不久，还在努力提升自己的开发技能。我也没有任何管理或指导经验，但由于那是一家规模很小的创业公司，而我虽然只有两年的工作经验，却已经是公司里经验最丰富的开发人员之一，所以自然而然地，我负责了新员工的入职流程和支持工作。

后来，我跳槽到了现在这家公司，公司规模比以前大了十倍，我现在担任高级工程师。现在，支持团队里的初级开发人员是我日常工作的重要组成部分，我非常喜欢这项工作。

如何成为一名优秀的导师

了解你的受指导者

你将与​​人打交道，而每个人都各不相同，所以你的首要任务应该是了解他们。

他们的背景是什么？这是他们的第一份工作还是他们之前有过相关经验？他们更喜欢从事哪方面的工作（后端、前端、某种特定语言）？他们对工作/职业发展有何期望？他们喜欢怎样的工作方式？等等。

这也是你展现你乐于助人、让他们感到自在的机会。

通过深入了解他们，你就能更好地了解他们需要什么样的指导。

请耐心，并理解每个人的学习速度都不一样。

有时你可能会把下属看作是自己的镜子，如果你学习能力很强，而公司又要求你保持其他“高级”任务的节奏，如果他们的学习速度不如你预期，你可能会感到沮丧。

请耐心等待。

每个人的学习速度都不一样。关键在于你应该逐渐看到一些进步，即使进步很小。

我有一个非常有趣的故事，讲述了背景相似的人如何变得如此不同，需要不同类型的指导。

在我工作的第一家公司，有两位开发人员参加了为期六个月的实习。他们毕业于同一所大学，年龄也相仿，同时加入了这家公司。

它们完全不同。

其中一位学习能力极强，求知欲也很强，我几乎不用跟他解释什么。他可以轻松地通过谷歌搜索找到问题的答案。我们讨论的内容则更偏向于代码模式、代码组织方式等等“高级”话题。

另一个孩子性格比较内向，需要更多指导才能理解一些“基础”概念。他的自主性也较差。

第一个人实习结束后留在了公司，第二个人则没有。

他们两人最终走上了截然不同的道路，但现在都成为了优秀的软件工程师。

成长并非线性过程，而且因人而异。我认为很多晋升机制都存在缺陷，因为它们预设了线性增长。（例如：一次只能晋升一级，或者不能在连续两次考核中晋升）。不过，这又是另一个话题了。 ;)

这有点像足球运动员。有些天才少年18岁就达到世界级水平，但也有很多人要到25岁甚至更大才能达到巅峰。

即使在同一家公司内部，也有许多因素会影响绩效和学习速度，例如项目或团队环境。

也许团队氛围不够友好，让她不好意思提问？或者她正在参与一个非常复杂的项目，需要处理大量遗留代码？又或者她频繁更换技术或框架，导致无法集中精力深入学习。

作为导师，你的职责是了解具体情况，并努力创造最佳环境，让她能够成长。

结对编程

结对编程常常被低估，但它却是分享知识的绝佳方式。

我认为在很多情况下，对学员和导师来说，一起花一整个下午从头到尾解决问题，比各自忙自己的事，不断打断对方提问，效率要高得多。

这样做，你还可以教给他们其他重要的技能，比如如何与他人合作，如何集思广益、讨论想法。你甚至可以发现一些可以改进他们开发工作流程的方法。例如：一些他们可能不知道的IDE实用快捷键。

务必确保两人经常轮换角色，从驾驶员变成领航员。不要让他们过于安于现状，只扮演一个角色。

持续且及时的反馈

我曾经在某处读到过这样一句话：“如果在绩效评估阶段，你发现自己的绩效很差，那么肯定是评估过程出了问题。” 这句话说得太对了。

如果你是管理者，不要等到绩效评估阶段才告诉员工他们的表现。要持续给予反馈，指出他们做得好的地方和需要改进的地方。倾听他们的顾虑，了解他们的职业目标，并为他们实现目标创造条件。

代码审查

代码审查是导师最重要的工作之一，千万不要掉以轻心。

Don´t wait till the task is finished where the probabilities of them having to refactor big part of it are quite high. Instead do frequent discussions about a possible implementation of the solution (Ex: in pair programming session).

When reviewing their code, make sure you understand well the context and their ideas regarding the implementation. Make actionable comments and explain the rationale behind them. Dont just say, "this is wrong, do it this way".

If possible do the review together, so they can better explain their ideas behind the implementation and discuss alternative ways if necessary.

Let them take decisions and make mistakes

Everyone make mistakes. And its a great way to learn.

It might be tempting for you to micro-manage and try to make sure they do everything in "your way". Don´t to that. Give them some freedom to try their own approach to a problem.

If it goes wrong, explain how they could have done it in a different way. If it goes right, congratulate them.

Failure is simply the opportunity to begin again, this time more intelligently -Henry Ford

A new pair of fresh eyes, can often see things and propose simple solutions, that people who are already so deep in the problem can´t see.

They wont learn, if you put them in a protected "bubble" from the outside world and give them all the answers.

Let them riding the bike without training wheels sometimes.

Help them defining their Career Path

There are so many career paths in our industry, that can be hard
for someone that just get off the university and get their first job, to know exactly what they would like to do.

As a mentor, you can help them a lot with that. You could, for example, show or let them working with different technologies from frontend to backend, ops, etc so they can get a feel of what they like more. But be careful. Dont let them become overwhelmed by the possibilities. I believe a junior has to focus on becoming really good at something first, before expanding their horizons.

But that´s why you should "Get to know your mentee". So you can understand their concerns and expectations and help them accordingly. May be she already knows exactly that Backend Development is their passion? Everyone is different.

If you are a Junior reading this ...

I also have some advice to you.

Always ask questions!!

Just make sure you spend a little time on your own first.

Many questions can be answered with a simple Google or Stack Overflow search. Always put a time limit on your search. It could be 30min, 1h, but if you feel stuck, ask for help!! The worst thing it can happen is you become stuck for hours in a problem just because you were afraid to ask or didn´t want to interrupt your mentor or someone in the team.

Also, be proactive and think about possible solutions for the problem first and present them to your mentor. It will be a much more interesting conversation and you will learn much more if you deep dive into a problem yourself looking for solutions, than always waiting for someone to give you the right answer.

Be curious and show interest.

Challenge your mentor. The fact that she has much more experience than you, doesn't mean she is always right.

Celebrate your achievements together ;)

Conclusion

Mentorship of Junior Devs is a very important process. I believe, it should be part of any Senior / Team lead daily job. But I also understand that not every Senior Dev have the skills required to be a great mentor. The worst thing you can do is to force a top developer into a bad mentor.

Its not an easy job, specially when you have your own tasks and deadlines and you dont have enough support for your managers.

Its an invisible work many times, at least in short term, and others from outside might think you are getting less productive in your coding tasks, because you are "loosing" time in your mentorship tasks.

But its also very rewarding when you see your mentees growing and doing great things ;)

That´s all for today.

Thanks for reading and feel free to comment.

PS: If you are a Junior Dev looking for a mentor online, or if you are a more experienced dev and have the time and interest to mentor someone, please check the amazing new project of Emma Wedekind, Coding Coach.