Lars Klevan
BetterUp的员工文化是固定在我们的共同价值观的勇气,工艺,嬉闹,毅力,同理心和强烈的兴趣。作为一个工程团队,我们想给生活带来创新的产品,这需要我们迅速行动,同时保持高安全标准,代码的质量,和用户体验。
代码审查,它就像是有一个“拿着线”之间的紧张关系的质量和我们想要快速行动,但通过我们的同情心的价值,我们能做的,这样做的方式表明了我们相互尊重和同情。
我在开会
作为一个评论家,我们可以让我们的同情心流动通过想象自己的鞋子的人编写代码。一个好问题首先是“作者目前的学习曲线BetterUp代码库吗?“这个问题有助于我们集中我们的反馈将是最有帮助的。
例如,经验丰富的同事,我的主要目标是提供第二双眼睛,只是为了确保不是他们没有思考和关注最关键的代码审查的安全性和系统的稳定性。假设我们有一个强大的关系我舒服离开简短的建议或者问题,“这个工作如果有现有的记录吗?”
工程师的新代码,我要把整个代码评审主要是一次学习的经历。因此我通常进行我的头几个代码检查新员工作为同步会议。这样我们可以花时间讨论关键决策,讨论备选方案,最重要的是使用评审为契机,学习我们的模型,指导方针和约定。
导致这一变化的是什么?
另一个问题是,“走进这个变化的环境是什么?“这可以容易回答如果更改是一个项目的一部分,你的深度参与。这可能并不总是正确的。所以,我们要问自己,“这是引人注目的项目的一部分吗?”“如果我请求一个根本性的改变将会发生什么?”
在情况变化是紧迫的,我们可以引导我们审核通过的心态,“我看到了一个主要问题与这种变化?”情况的变化不太紧迫,我们有豪华寻找更多的改进,就像,“这门课变得非常复杂,我们应该考虑重构?”考虑到上下文,我们可以避免一个工程师在压力下脱轨的交付和减少必要的反馈。
我应该怎么处理这个反馈?
作为一个代码作者,有时很难知道如何处理反馈得到的代码评审。“我必须解决这个反馈,还是对未来要记住?”“如果我得到了相互矛盾的建议吗?“作为一个评论家,可以使代码作者的生活更容易通过回答这些问题。
在BetterUp,我们经常使用公约的标记作为一个评论家暗示我们的意图。#可选可用于反馈,是为了刺激思想但不需要行动。#小是一个很好的方法来软化吹毛求疵。我们使用# namingishard承认选择名字的东西在软件非常困难,但很重要。和我最喜欢的是跟踪号,表明,该不该阻止,但它将是一个好跟踪一张票的问题。
回顾合作
结合这些实践,我们希望改变评论家从一个看门人的角色作为一个伙伴和老师。通过调整我们的反馈来作者的过渡阶段,我们可以释放速度和学习。通过理解和接受变化的背景下,我们需要时可以迅速行动,采取改进的机会。被有意与我们计划的反馈需要解决,我们可以确保我们的团队可以阻止只有真正需要的时候,我们可以建立合作伙伴关系的精神,让我们做神奇的事情。
关于作者
拉尔斯2016年加入BetterUp作为一个完整的堆栈高级工程师。他和他的配偶住在明尼阿波利斯和两个上小学的女儿。当他不绕着湖他可以找到玩桌面游戏或吃玉米片。
加入谈话