Practice make perfect

所以你是个刚毕业的软件工程师(译)

或者,“当我作为一名刚毕业的软件工程师开始工作的时候,我希望我做了什么 ”,但这实在太可笑了。

这是你毕业后的第一天上班。

你走进办公室门口,向接待员打招呼,心里暗暗地松了一口气,您再也不需要再在Envoy上进行访客签到。有人兴致勃勃地跟你打招呼,示意跟他们走到你的办公桌前,你的新团队里的每个人看起来都在全神贯注地工作。你安慰自己,这是你一直期待的机会。

接下来的几天过得很模糊,中间穿插着一些你可能会忘记的密集内容的入职谈话,以及与公司各个团队的同事喝咖啡聊天,多得你数不过来。你最终会形成一种习惯,和你的团队每两周进行一次冲刺,开发新功能,与团队成员进行一对一的交流,等等。

最后,你开始问自己: 我是如何在这份工作中取得成功的?

作为一名刚毕业的工程师,当我开始工作时,我喜欢的是一份具体的清单,上面列出了工作中不太明显的方面,这样我就可以更有效地工作,更快地成长。考虑一下你最喜欢的RPG中的支线任务,当它们完成时,会带给你经验,金币,甚至特殊物品。

在这篇文章中,我概述了一些想法,作为我可能会给自己年轻的建议。这些是我在Plaid担任工程师的第一年所学到的最重要的课程,我希望年轻的Evan知道并执行这些课程。

在这篇文章中,我列出了一些我对年轻时的自己的建议。这些是我在格莱德当工程师的第一年学到的最重要的经验,我希望年轻的埃文能够掌握并实践这些经验。

第1课:了解端到端服务架构

在最初的几周里,您可能要构建新的功能并修复一些bug。最有可能的是,这项工作将被限制在一个或两个服务中。此外,你可能会被你需要获取的大量信息所淹没,而这些信息是你开始为你的团队做出贡献所需要的。

我认为,你能学到的最有价值的知识之一,就是所有现有服务的强大心智模型。了解每个人在非常高的层次上做了什么,以及他们如何在总体依赖关系图中相互交谈。理解每项服务背后的理念和它们试图实现的目标。然后,当您遇到处理服务的机会时,深入研究实现细节。这有助于像埃隆·马斯克(Elon Musk)那样思考知识。

如果您在小型创业公司工作,这样做会容易得多。服务的规模和复杂性通常与团队的规模密切相关。如果你在一家大型科技公司工作,那就为你的工程团队或部门做这件事,并把范围限制在你的代码会影响的直接面向客户的产品上。

这很重要,原因有很多。

  • 它有助于了解您的工作最终将如何影响最终用户。
  • 它增进了您对产品工作原理的理解。
  • 这对于参与高层架构讨论很重要。
  • 它将使您能够推动多个团队更新。

方便的是,工程团队通常围绕服务边界而构建的,因此这可能有助于学习了解各种服务。当然,可能很难内部化,但是具有方框和连接箭头的流程图确会有帮助。找个高级工程师给你画一张,每天晚上睡觉前凝视它看。

在过去的一年里,我有很多遗憾,没有做到这一点就是其中之一。我应该在入职过程中立即这样做,但当时我认为没有必要这样做。要认识到,随着时间的推移,知识会变得复杂,对整个服务堆栈有一个强大的思维模型是更好地理解工程组织如何工作的关键构件。

我为错失的成长向过去的自己道歉。

第2课:学习技术栈的基础知识

就像大学里教的那样,你只需要知道如何写代码,就能凭空变出神奇的数据结构和算法。事实上,这是大多数公司在软件面试中测试的目的。然而,构建系统涉及的远不止写代码。考虑运行生产级代码需要什么。

这是我最想知道的清单。 日志,Secrets,Metrics,容器,服务器,数据库,负载均衡,队列,服务间通信,持续集成,部署等。

不幸的是,其中大部分是你在大学里永远学不到的东西,至少如果你上的是美国传统的计算机科学课程的话。没关系。你会在工作中迅速掌握必要的技能,并很快学会使用这些神奇而强大的工具。

尽管如此,我仍然认为,通过阅读在线文档、博客文章和代码来超越仅仅知道如何使用工具X(从浏览示例到理解工具X或语言Y的内部原理)是有价值的。

例如,了解和如何使用gRPC有很大的不同——“哦,这让我们可以在不同的服务中调用类型化函数?酷!”,以及底层实现使用HTTP/2并维护客户端和服务器之间的持久连接。从经验来看,花点时间阅读关于gRPC内部的文档和博客文章能使我能够做出更好的架构决策,并在你的系统中快速调试bug。此外,由于通常这是很少有人做的事情,你可以成为公司技术领域的专家。人们最终会带着礼物来找你,以换取你的圣贤建议。

这适用于您的工程组织所使用的各种技术。当然,在学习上投入太多时间的回报会递减;你仍然有一份日常工作来创造商业(业务)价值。我经常使用的一个很好的试金石是看我能多好地向别人解释一项技术的好处和坏处。你应该渴望能够走到随便一个工程师面前,就这个问题展开5分钟的长谈。

现在,继续阅读贵公司的日志基础架构。

第3课:快速行动并改善事物

你可能听过现在硅谷著名的名言: “Move Fast and Break Things”。长话短说,你并不想体现这种精神,尽管毕业后你渴望编写代码和发布大量功能的兴奋之情被压抑着。虽然Break Things可能是一种夸张的说法,除非扎克伯格真的想让Facebook的工程师们犯错,但它确实灌输了这样一种思想:只要你行动迅速,发布打破常规的改变是可以的。

我更喜欢“快速行动,改善现状”这句话。这里的潜台词是,系统首先已经可以运行,即没有任何问题,以便您可以改进它们。我想说的是,作为一个已经通过了6英尺高的面试标准的工程师,快速行动和正确做事已经是我们所期待的。

另一方面,把事情做得更好更多的是一种后天习得的技能。首先,你必须注意到有些东西不见了;在我的经验中,这只有经验,你猜对了。原谅diacope其次,你需要主动与其他工程师沟通这个差距,或者分配资源(时间、精力)来自己解决问题。第三,也是最后,这种改变需要向关心他们的人宣布。因为,嘿,如果一棵树倒在森林中,你就明白了。改进工作并非难事,尤其是如果它们与您的冲刺目标无关时。然而,其他人会感谢你让他们的生活更轻松。

在过去的一年里,我已经做了足够多的事情,我的脑海里已经有了一个低悬高投资回报率的改进列表。给你,供你细读

  • 开发工具(代码检查(linting),第三方包版本)
  • 监控(指标,警报,日志记录)
  • 接口重构(提高代码的可读性和可维护性)
  • 你的(在这里插入你最喜欢的问题跟踪器)中的bug和待办事项,没有人愿意花时间去处理,当然它们有会更好,但并不关键

我想到的一个帮助我管理这样一个列表的方法是维护一个任务的待办事项列表(使用优先级队列),当你在冲刺的主要工作中被阻塞时,你可以从中挑选出来。我会把非紧急的生活质量改进和bug的修复放在这里。当然,项目工作将优先于这些所谓的“改进“。

类似地,这篇题为“完成,让事情变聪明”的博客文章也过于冗长,不利于睡前阅读。

第4课:了解流程(进程)是必不可少的

我们这里讨论的不是进程的操作系统概念。引自词典,流程是为了达到特定目的而采取的一系列行动或步骤。尽管这个概念很抽象,但直到我开始全职工作,我才完全内化了它。

我不是流程的超级粉丝,在我刚开始工作的时候,我对流程有一种强烈的蔑视。他们身上散发着官僚主义的味道,或者其他什么穿着西装的人整天做的事情,并且与快速移动和快速迭代等工程价值背道而驰。事实上,令我高兴的是,我确信与我一起工作的每个人都对流程有同样的蔑视。

然而,我已经意识到流程对于确保长期的业务价值是非常重要的。它们不仅确保可以完成并改进一组常用的任务,而且还可以最小化在大型团队中执行这些任务时的差异。流程确保了执行的一致性,这是必要的,因为与软件不同,人是经常出错的移动的部件。

的确,它们在完成更具体的事情时带来了摩擦和复杂性,但我已经意识到流程是必不可少的复杂。事实上,流程是组织在成长过程中维系组织结构的纽带。如果一个50人的团队中的每个工程师都使用游击战术来发布功能,但是他们每个人都更喜欢这样做,想象一下随之而来的混乱。

流程可以采用多种形式,包括以下内容。

  • 为大型项目撰写技术规范。
  • 记录系统的未知部分。
  • 对所有生产问题进行事后分析。
  • 将任何重要的更改给发消息告知系统

敏锐的读者可能会注意到所有这些中的一个共同点:它们涉及到向团队中的其他人传达关于某事的信息。不过也有一线希望,那就是过度沟通从来都不是坏事。除非你在处理机密信息的秘密项目,否则不交流几乎总是比交流更糟糕。

第5课:写更多的代码文档

具体来说,作为一名工程师,你的工作就是解决业务问题并为公司创造价值。这种方法的实现主要涉及编写代码和交付功能,但通常还有更重要的任务。如前所述,其中之一就是编写文档。

文档可以采用多种形式:代码注释、提交消息、电子邮件、谷歌文档、wiki条目、README文件等等。格式取决于使用信息的上下文。例如,电子邮件是一种广泛的、永久的、可搜索的文档格式,应该用于非紧急内容,如重要通知或长期异步对话。

以下是文档服务的两个不太明显但却至关重要的目的。

  • 它们减少了您团队的总线因素
  • 它们充当了不可避免的时态背景的永久档案。

您编写的文档越多,获得的文档就越好、越快。毫无疑问,在你的整个职业生涯中,技术写作都是一项宝贵的技能,现在是开始写作的最佳时机。它是信息扩散的最可扩展的方法之一(与语音和即时消息等更短暂的方法相比),并且随着组织的发展变得更加重要。现在,你想要改进吗?去写一些文档并发给你的团队吧。

这篇博客文章展示了一个有趣的小示例,它显示了针对单个字符代码更改的一整页git commit消息,这是有价值的文档的缩影。

结论

在过去的一年里,我在Plaid接触了很多系统,做了很多不同的事情,这5点是我最重要的收获。这些都是个人经验教训,可能并不适用于每个人,所以对这些要有所保留。我仍然希望它们对你蓬勃发展的事业有用。

感谢阅读!

特别感谢Joanne Lee,Jeffrey Wang和Michael Cypher慷慨地提供了他们的时间来审阅这篇文章。


翻译自 Evan Limanto So You're A New Grad Software Engineer

评论