两年来,软件社区中一直存在关于初级工程师缺乏工作的在线讨论。 我对最佳头衔的投票是谁杀死了初级开发人员。
在Leaf职位发布后,我们正积极招聘初级工程师。 我们拼命地招聘这个职位,因为我们知道它将使我们更快,更好,更强大。 但是实际上,我们花了数月甚至数年的时间才能开发出How To Software™游戏,才使我们能够释放团队中拥有初级工程师的价值。 我希望本文可以缩短其他一些人的学习时间。
How To Software™是一个尝试,错误和学习的游戏。 我的一些尝试是以一些不幸的初级工程师的形式出现的,我们在Leaf的一生中很早就雇用了他们。 我的错误无数。 其中包括不合理的入职和指导,甚至根本不这样做。 很难回首并将其视为我们从中学到的东西-它更容易畏缩。 从我进行的数十次(甚至数百次)访谈中,我的直觉告诉我们,与行业相比,我们甚至还没有走下坡路。
尽管有所畏惧,但失败伴随着学习。 而这个游戏是我们无法承受的。 就个人而言,我希望在我的一生中继续保持“初级”的地位。 我想学习新技术(hi Rust和CRDT),与新团队合作或开发新产品。 因此,我花了一些时间学习如何在此特定游戏中获胜。
- 新年,是的,*可能**新我,该死…
- 如果您想提高生产力,请少做些。
- 我们正在学习的有关使用技术来增强团队合作,提高生产力和更有效地沟通的知识
- 使用这些生产力工具拥有您的电子邮件
- 如何创建引发FLOW状态的触发器。
总而言之,我们最后几名初级工程师的聘用最终成为了软件团队希望获得的一些最高杠杆“资产”。


玩“如何使用软件”的第一步之一就是不要以面值表示诸如“初级使老年人慢下来”或“我们没有能力指导低级生”这样的主张。 这些类型的声明通常是代码气味的人工版本。
拥有一支高效的团队或雇用初级开发人员并不是二元决策。 实际上,存在直接聘用初级开发人员并因此创建生产团队的条件。
对于初级工程师来说,这是一个非常不错的地方:在大多数专业软件团队中(由几个人组成的黑客团队)。 在这种情况下,雇用初级开发人员可以而且应该使您的团队获得70%的经验,这是经验丰富的工程师的100%。 现在,这是一笔可观的投资回报。
团队动态从根本上讲是一个人的问题,但让我们忽略它。 应用数学并使用任意组合的示例可以充当代理的角色,以查看这项投资的回报。
Leaf的许多工作都与改善或增加活动分类管道的功能有关。 在这些项目中,我们根据历史数据进行测试,以了解功能将来如何工作。 假设我们要添加一项功能,该功能可预测何时完成耕种任务。
我们的要素工程流程如下所示:
- 协作头脑风暴//是
- 原型和代码//
- 质量检查+测试// eek
- 重构代码// meh或yay
- 质量检查+代码审查+测试// eek
- 部署+历史更新// eek
对于一项全新功能,没有神奇的自动化QA系统套件可以对其进行测试。 结果,第3、5和6步需要进行大量的手动检查,编写自定义脚本以及构建像可视化一样的工具来分析大量数据。 这部分很容易花费总时间的50%或更多时间来将某些内容发布到我们的分类管道中。
如果一项功能需要经验丰富的工程师花费2周的时间来构建,则他们可能会花5天的时间进行测试,质量检查并将有用的工具修补在一起。 当然,要感觉所有权和了解解决方案的有效性,必须进行一些质量检查和测试,但这是一个过多的时间。
而且不止于此。 如果我们的功能已准备好投入生产,则从开始就将其追溯应用到系统中的每个服务器场。 这不是一个微不足道的功能。 对于某些功能,这意味着重新映射可能受新功能影响的任何第三方数据。 从他们获得Leaf的第一天起,我们就“重写”服务器场以反映新功能。
多年来,为服务器场重写10万个任务,并与多个分布式第三方API交互不仅耗时或任务关键,而且也很脆弱。 我们通常仅与我们所集成的最弱的API一样强大(而且我们内部也不完美)。 即使使用测试,广泛的日志记录和事件监视器,也经常需要工程师安全,完整地引入流程。
因此,工程功能很耗时。 想象一下,我们有3位经验丰富的工程师正在使用我们的预测功能。 我们现在所说的是工程师在2周的冲刺测试,质量检查和更新历史数据中花费3个网络工作周。 这是“如何使用软件”的痛苦方式。
输入新玩家:初级工程师。 如果他们可以从他们的团队分担2/3的“ eek”任务,那么我们就可以及时获得相当于高级工程师的水平。 这不仅表现为纯粹的生产力提高。 这也提高了团队道德,并释放了创新的认知空间。
我们也不是强迫所有初级工程师从事“艰巨的工作”,也不要强迫他们一直在工作。 如果不深入了解AWS,Docker,Golang,Postgres以及众多日志记录和脚本编写工具,就无法在Leaf上真正从事此类工作。 初级工程师学习,Leaf完成工作。
这是双赢。
了解初级工程师的潜在价值后,您就可以得到一个。 How To Software™的下一步是弄清楚如何实现该价值。 在Leaf,它从入职路线图和里程碑开始。 以下是一些指导过程的有用问题:
- 有才华但经验不足的人需要多长时间才能拿起您的书架? 获得适当的领域知识? 获得足够的自我效能感以自行解决问题呢? (大约90天)
- 什么里程碑使初级工程师最快地获得高杠杆? 是否有正在进行的新功能需要测试,或者旧的功能没有得到很好的监控?
- 这些里程碑是否也考虑了新团队成员的最大利益? 他们是否正在学习可以促进职业发展的新技术? 他们是否正在了解您的问题空间?
- 在此路线图的最后,他们会为团队前进提供动力吗? 他们是否能够制定自己的目标并使他们与团队和公司保持一致?
Leaf的登机路线图是现成的文件。 他们必须随着团队环境的发展而变化(我们每两周审核一次,以确保其相关性并加以改善)。
路线图只是难题的一部分。 他们必须与经验丰富的工程师的时间和指导相结合。
以我的经验,每周要花几个小时进行配对,是2到3名经验丰富的工程师填写的新员工时间表。 当新的团队成员将他们从繁重的工作中解脱出来时,人们很乐意将这几个小时投入到新的团队成员中。
导师制本身会有所帮助,但是与工程经理进行明确和有条理的一对接会锦上添花。 除了技术学习之外,这还提供了一种机制,可将指导包括在同等重要的专业技能中,例如沟通,优先次序,组织等。
像生产力一样出色,积极雇用初级工程师也具有同等重要的战略作用。 您可以聘请那些尚未在专业领域充分发挥才能的非凡人才。 套利这一事实,即大多数团队都在回避他们的经验差距。
在过去的几年中,参与大学CS计划以及可行的替代教育途径(如训练营和学徒制)的人数激增。 这意味着比以往任何时候都有更多的才华横溢的人试图进入这个行业。 目前,我们的初级工程师职位招聘渠道包括来自CMU,普林斯顿,哈佛,斯坦福的本科生。 同样重要的是,它包括那些曾经获得过成功生活的人,这些人已经通过训练营等其他方式横向进入了该行业。
战略活动不只是原始人才。 我今天在初级申请人中看不到很多管道问题。 这可能是平衡分集方程的好地方。
在过去的几年中,有两种由多样性引起的团队动力在我眼前一跳。 一个是多样性创造了不同的创造力资源。 它与个人技能的交叉转移具有相似的效果,但适用于团队。 第二个原因是多样性可以在团队内部进行成熟,专心的沟通,因为您不能将彼此的想法视为理所当然。
在开始工作之前,我们的最新雇员获得了艺术学士学位。 同时,她获得了网络开发人员的实习机会,随后进行了训练营,并全职进入软件行业。
不要通过How To Software™走痛苦的路。 提倡团队中的初级工程师。 尽力帮助他们成功。 您的团队将更快地发货。 它将运送funner。 结果,您的公司将发展为更有才华和更加多样化。
注意:经常将人视为资产主要是嘲讽,讽刺的行业评论。