Suckiness 的局部最小值

2021-08-09 01:49:40

我通常不做绝对的事情,但我现在知道一件事从根本上是正确的:没有人能靠自己成为一名优秀的软件工程师。但在一个一直以超级巨星忍者、独狼、自学天才的神话而自豪的行业中,优秀的开发人员似乎不是天生的——他们从地下崛起,完全成型并不断涌现PRs 他们的醒。迄今为止,在我的职业生涯中,我还没有见过一个人能够在不向他人学习的情况下成功成长为一名称职的开发人员。而且,我担心,作为一个行业,我们并不经常积极谈论这样一个事实,即我们需要其他人在工作中帮助我们学习东西,并且我们需要在我们的开发和工作规划过程中为这种学习留出空间.在“专家初学者的崛起”中,我每隔几年重新阅读一篇文章,Erik 谈到了开发人员如何停止学习。他的基本论点基于先前对技能习得的研究,是人们开始习得技能的速度非常快。但是,在学习过程的某个时刻,他们会停滞不前,因为他们作为初学者学到的技能将使他们成为专家。想一想能够编写打印到终端的函数与创建一个具有返回文本的方法的类之间的区别,这些方法将文本传递给其他检查已处理输入的方法,然后将其传递给前端。现在假设该类是一个必须打包才能在云中工作的函数。而且,最重要的是,假设该函数必须在一个 repo 中进行版本控制,其中 5-6 人定期合并代码,通过 CI/CD,并且是返回某些机器学习模型输出的系统的一部分有延迟限制。您可以很快地用任何语言编写打印语句(假设您克服了在本地机器上安装它的麻烦)。但是要理解如何从打印(“Hello World”)到“这是一个为您实时进行机器学习预测的应用程序”需要很长时间。那么我们如何让我们团队中的每个人都到那个地方呢?我们如何帮助其他人走出黑暗、令人沮丧的地方,即专业初学者的局部最低点,越过繁星,进入云端?而且,我们如何帮助自己成为更好的开发人员?也就是说,如果您擅长编写代码但不擅长审查,那么您将编写大量代码而不会进行大量审查,因为对您的审查的最初反馈将是负面的。你必须克服吸吮的局部最小值。

— Vicki Boykis (@vboykis) 2021 年 7 月 26 日 在我自己的职业生涯中,我注意到开发人员需要变得更好的三件事:这是我最近发现的对我们现在称为心理安全的现象的最佳描述:违反直觉但确实如此:您将与那些让您感到很自在的人一起做最聪明的工作 — jckbtchr (@jackbutcher) 2021 年 7 月 18 日 简单的故事是,在良好、高效的软件环境中,您有混乱的空间向上。初级开发人员中断生产,使公司损失数千美元,这是关于这是如何工作的虚构故事。看到这个之后,他开始把桌子上的所有东西都放在一个盒子里。首席执行官走到他面前说:“你要去哪里?” “我只是花了公司这么多钱,我以为我被解雇了。” “我们只是花了数千美元来培训你。我们为什么要放你走?”这是另一本真实的书,来自我正在阅读的一本很棒的书,Gerald Weinberg 的“计算机编程心理学”,我强烈鼓励所有从事或接近开发工作的人阅读这本书,因为它解决了我们思考时的大多数问题每天考虑编程——项目规划、团队结构和障碍物,还有额外的令人兴奋的警告,所有这些都已经在 1971 年讨论过并写过。

我不能再强烈推荐《计算机编程心理学》了。它涵盖了我们今天在工业中谈论的每一件事。它是从 1971 年开始的。例如,这里是心理安全。 pic.twitter.com/I0jltWWZwx — Vicki Boykis (@vboykis) 2021 年 8 月 1 日这个轶事是关于开发人员比尔的,他正在研究(表面上)导弹防御系统,指令是用机器代码编写的。他到了一个他认为他想通了的地步,但由于您可能需要对导弹防御系统进行第二次观察,他让玛丽莲检查他的代码。那时,代码审查仍处于初期阶段,温伯格写道:“他的价值体系,在编程方面,表明秘密的、占有性的编程是不好的,而开放的、共享的编程是好的。可能在他编写的代码中发现的错误——这里没有使用术语“他的代码”——只是为了未来的改进而进行调查的事实,而不是对他个人的攻击。 “玛丽莲在 13 行代码中发现了 17 个错误。比尔没有生气,而是四处转转,​​告诉大家这段代码是多么不可能,而且她发现了 17 个错误是多么有趣。正当他这样做的时候,有几个人加入了进来,因为此时这是一个游戏,并且发现了更多的错误。一个可能以比尔指责玛丽莲阻止他或比尔隐藏他的代码而结束的场景,因为他认为其他人会认为他是一个糟糕的开发人员,结果好得多,因为事情是公开的。好的公司为错误和草稿留有余地。这并不意味着工作可以马虎。相反,检查一段代码的人越多(达到特定数量 n,其中更多的代码审查实际上开始有害),代码的防错能力就越强。相反,优秀的团队会为开发人员留下一些松懈的空间。他们知道这将需要任何开发人员,无论其技能水平如何,入职时间如何,而且最终,开发人员都是具有偏见和不同技能水平的代码的人。定期审查彼此代码的团队会相互升级。在此过程中,他们还添加了保护措施:运行手册而不是手动输入、易于回滚的生产系统、随时可以回答问题的团队成员、良好的文档,并且他们有人员那些经历入职培训的人对相同的过程做出了贡献。

他们还提拔重视所有这些技能的人:耐心、指导,以及要求卓越技术同时承认实现目标所需条件的人。你提拔的人会告诉你的组织结构图你希望组织的外观,所以重要的是要突出分享这些价值观的人并为组织定下基调。在中世纪,社区在行业中将最佳实践传递给后代的方式是通过学徒制。如果你的父母希望你在 12 岁左右成为一名酿酒师,你会收拾行囊,在葡萄园里住上几年(一个诱人的想法),在那里经验丰富的酿酒师会支付你的住房和住宿费用以换取你做了所有繁重的工作,最终会导致你在你的交易中变得熟练。没有学习如何构建 Docker 容器或处理生产中断的学徒期。我们个人拥有的只有书籍(如果它们能够跟上技术变化的速度)和互联网资源,这些资源可能正确也可能不正确、过时或收费。解决这个问题的方法是让一位优秀的资深人士陪伴在身边,他至少可以给你一点时间。通常,这完全是偶然发生的,我希望我有一个很好的方法来专门为你实现它,但是我共事过的所有非常好的人,我在我的职业生涯中完全随机遇到了他们.但是,有一种方法可以告诉您组织中的这些人是谁,并在可能的情况下尝试与他们合作。优秀的高级开发人员会问很多问题才能找到问题的根源,通常他们会公开提问,以便其他人找到答案。优秀的高级开发人员会弄清楚复杂系统的工作原理。优秀的高级开发人员会仔细审查 PR 并提供反馈,他们也会回答问题。很难定义一个优秀的开发人员会做什么,但你很可能知道你组织中谁是优秀的人,因为你总是听说他们,而且因为如果你有问题,他们是你的第一个人想一想什么时候去寻求帮助。一旦你找到他们,想办法靠近他们并吸收他们的知识。当他们说话时倾听,并观察他们如何审查代码。做到这一点的一种好方法是要求在 PR 评论中标记团队。如果您还不能进行代码审查,请帮助他们编写文档。如果你能从他们的盘子里拿走一件小事,他们下次会感谢你的帮助。如果您自己在这种情况下是优秀的资深人士,请注意,成为优秀的资深人士不仅仅是编写良好、正确的代码的责任,尽管这本身就是一项重大而重要的责任。这也是在训练其他人像你一样富有成效。

到目前为止,我们已经讨论了组织、团队和高级人员在帮助他人升级和提高生产力方面的作用。在引导我们的学习中,我们自己的角色是什么?学习如何在正确的时间提出正确的问题是成为开发人员的基本技能之一。提出正确的问题需要花费大量时间、大量试验和努力,并需要大量修补不同的解决方案,直到问题变得有意义为止。尤其是作为一名大三学生,提出好的问题可能会让人望而生畏。我最近意识到,前辈善于提问的原因之一是他们已经知道自己的专业知识。 “我是一名高级开发人员,我只是查找了如何创建 NumPy 数组等。”但我刚刚从这条评论中意识到一个问题:作为资深人士,我们可以这样做,因为我们知道我们需要查找什么。 https://t.co/KZT6nrWyaC pic.twitter.com/iZsQZIHzCl — Vicki Boykis (@vboykis) 2021 年 7 月 29 日这就是为什么可以提出愚蠢问题的环境很重要。我见过的最好的处理方法之一是在 Slack 上有一个#dumbquestions 频道。另一个是让优秀的资深人士在会议上提出看似简单的问题,以增强他人的能力。如果这三件事就这么简单,我们为什么不每天都做呢?我们为什么不雇佣大量的初级人员并培训他们,我们为什么不创造人们可以学习的地方,我们为什么不教人们如何提出好问题?

令人沮丧的答案是,所有这些都是完全不可见的,并且在任何单个特定产品或公司的底线中几乎都不明显,而且几乎不可能解释它们,因为知识工作仍然无法衡量生产力。在大多数情况下,它们是一个不错的选择。而且,此外,在执行层面,很难告诉那些指导和进行内部培训的团队,而不是仅仅基于内部流程的团队,并奖励那些投入工作的团队,除非优秀的团队是还擅长营销自己,并在培训时尽快发布好的代码。但是,我坚信即使开始谈论事物并给它们起名字也是事物的开始,所以我在这里分享这个,因为我希望更多的人将其视为他们的一部分日常工作流程。