文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏

如果你是一个技术领导,你所做的最重要的工作是帮助其他工程师成长,并为他们的成功而设计计划。这意味着要确保他们拥有好的工具,保护和自信,他们需要从第一天开始有一个良好的影响。但是说起来容易做起来难。每一个优秀工程师都有一种不同的学习风格,每一个开发经理,都有一个不同的领导风格。对于入职来说,确实没有一刀切的方法,但我想我们都同意,前30天是每一个新员工的关键。

第 1 段(可获 1.25 积分)

HubSpot的TLs非常适合新员工,个人来说,我认为这比送他们去为期一周的“新兵训练营”要好。 我会说,我们在入职工程师培训方面做得很好,但是我们正在努力如何分享最佳实践,并对一些有意义的过程进行标准化。 所以我在内部分享了几个入门事宜的想法,以及在最初的几周时间里我是如何与新员工相处的,希望这些分享也有助于外部工程经理。

任务选择

第一,最重要的,你能做的最关键的事情就是认真考虑任务选择。这意味着为你的新员工列出一份详细的任务清单,并仔细考虑他们需要什么技能来完成每一项任务。 我强迫自己为每个新雇员写一个计划。 我将其保存在Google文档中,以便在完成任务后对每个任务进行删除。

第 2 段(可获 2.05 积分)

任务选择提示:

1. 每周都有小的胜利,这样他们就可以轻松地拥有任务和项目。保存一些更大,更美味的奖励,直到他们开始提升为止。 这样,他们对客户的影响就会更有意义。

2.避免从公司特定的事情开始。 理想的第一项任务是一个带有单元测试的、中等规模的需要改变行为的方法。 直到他们准备好之前,我通常不会深入HubSpot。

3.首先自己先开始这个任务。 如果你发现你需要调整Mothra,PR另一个项目,读另一个项目的源码,opengrok一些东西,那么这不是一个好的、用于新人的第一项任务。

第 3 段(可获 1.44 积分)

4.想想这些任务需要多长时间。 按周分组,以便您可以看到他们是如何按照您的期望进步的。 (要及时让他们设置好他们的工作站。)

5.制定每周的主题(不要忘了告诉你的新员工主题是什么)。 我会跳过JIRA / Sentry / Monitoring然后开始。 将他们作为3-6周的“主题”将会非常棒。

6.在第四周努力达到一个中等大小的功能,这具有挑战性但有明确的界限。 理想情况下,这将是他们在你决定授予他们权限的、代码库的任意部分上的第一个主要工作。

第 4 段(可获 1.44 积分)

当你写下你的计划时,把它看成是给你的新员工“讲一个故事”。 “首先我们要学习A.然后我们将学习B.然后我们将看到A + B如何一起工作。” “我们正在做的A的原因是因为...”“不要担心任何与操作相关的事,我们将用几周的时间做这些”。给人们一个时间轴可以使得成长期压力变小,因为他们不觉得他们会马上做所有的事情。

编码导师

将新员工与编码导师配对不是我们一直在做的事情,但我认为这对某些人来说真的很有用。理想情况下,导师将是一名更初级的编码人员,他们正在扩大自己的范围,或者比您的新员工在学习曲线上提前了几步。 (除了一些为进行深入代码审查的高级编码人员。)这个人应该在他们去Slack上提问,ping他们的编码风格/格式帮助器,或检查您的资源参考之前,冲到一线解决问题。如果您是后端技术主管,试图使用新的前端或者带有新后端的前端,这是特别有益的。

第 5 段(可获 2.64 积分)

等等,但为什么你自己不这样做呢? 有几个原因。首先,它将把他们介绍给组织中的其他人,由于技术主管更容易被打扰,它应该为他们提供更可靠的可用资源。 其次,我认为更重要的是,这使你的角色更像是一位教练而不是老师。 它促使你指导他们学习的方法而不是成为他们的神谕(译注:即直接告诉他们答案)。

拉请求(Pull Requests)

拉请求是HubSpot工程文化的通用语言,但有一些陷阱需要避免。

第 6 段(可获 1.24 积分)

1.考虑拉请求(PR)如何左右你的“模型”。 如果所有新员工都看到您调整代码和修复样式约定,那么这将是他们关注的。 如果您已经按照上述建议将他们与编码导师配对,那么他们的导师应该负责样式约定。

2.小心不要做太多的质量保证。 修复新员工PR中的细微错误将导致你们之间的相互作用,即他写代码而你负责质量检查。 相反地,推回PR以确保他们有一个关于如何安全地部署它的计划,以及他们将如何验证它在生产环境中是可以工作的。 你不希望你的“lgtm”意思是“此代码已经得到了我的个人认可,确认它在生产环境中是按预期的方式工作”。

第 7 段(可获 1.76 积分)

3.在他们开始编码之前,对系统结构图达成一致。 拉请求是一个不幸并且昂贵的地方来重做解决方案的架构。编写代码,发起一个拉请求,然后听说他们重新发明了轮子因为“ServiceXYZ”已经做了这件事,这是非常令人沮丧的。 如果这发生在你的新员工身上,那你就没有提供他们成功所需要的东西。在开始编码之前与你的新员工一起,仔细研究每个任务,以限制浪费的工作。 我很幸运地用结构图来反复地讨论一些复杂的建议; 这是我在开始一个相当复杂的项目之前我的团队和我提出的最终结构图的例子:

第 8 段(可获 1.46 积分)

Onboarding_Engineer.png

4.重点关注代码的命名和清晰。 拉请求应该易于审查,因为变量,方法和代码组织是明确的。 优化和筛选,直到拉请求容易阅读,因为代码的意图和效果非常清楚。

5.避免大量拉请求,但始终保持主分支可部署。 这说起来容易,但是做起来难。 我们如何协调可部署的主分支,避免长期的分支? 功能标志是我们的主要武器。 帮助您的新员工制定一项策略,使其所有的代码进入生产环境,但隐藏在标志之后。 更好的是,将拉请求分解成几个可以独立验证的逻辑块,甚至将其放在功能标志后面,这样即使它们不工作也可以安全地部署。

第 9 段(可获 1.78 积分)

结对编程

如果存在一种方法可以传递你所有的智慧而不需要整夜整周的工作,这难道不好么? 你有没有感觉到你没有时间为新人以及培训新人制作详尽的计划?为什么不尝试结对呢?只需一周中的几个小时,坐在他们边上,和他们一起免费低价的工作一个小时你就可以成功使得你的新员工上手。

玩笑归玩笑,结对(两个人为解决同一个问题而写代码,可能是小问题,也可能是大问题)是一个很棒的方式让你的新员工迅上手。IntelliJ的提示和技巧?核对。怎么分解一个问题?核对。在代码方式上迅速反应的能力?检查。高效的教他们什么工具和服务是可用的?核对。所以,你还在等什么?今天就立刻开始结对编程吧。

第 10 段(可获 1.99 积分)

文章评论