你是一个新毕业的软件工程师（译文）

[yanyue404]

原文链接 https://evanliman.to/2019/10/06/so-youre-a-new-grad-software-engineer.html

Or, “What I Wished I Had Done When I Started as a New Grad Software Engineer”, but that’s too clickbaity.

或者，“当我开始作为一个新的研究生软件工程师时，我希望我已经做了什么” ，但是这太过于点击了。

It’s your first day of work after graduation.

今天是你毕业后第一天上班。

You walk through the office entrance and greet the receptionist, secretly relieved that you no longer have to endure yet another visitor check-in on Envoy. Someone cheerfully greets you, motioning to follow them to your desk, where everyone on your new team looks deeply engrossed in work. You reassure yourself that this is the opportunity you’ve been looking forward to.

你穿过办公室大门，向接待员打招呼，暗自松了一口气，因为你不用再忍受另一个来访者登记特使了。有人兴高采烈地向你打招呼，示意跟着他们到你的办公桌前，在那里，你的新团队里的每个人看起来都在全神贯注地工作。你向自己保证这是你一直期待的机会。

The next few days pass by in a blur, punctuated with onboarding talks whose dense content you’ll probably forget, and coffee chats with more co-workers than you can count from various teams at the company. You eventually settle into a routine, doing biweekly sprints with your team, building new features, engaging in one-on-ones with your team members, et cetera.

接下来的几天过得模糊不清，不时有新员工上岗谈话，其内容密集到你可能已经忘记了，还有与公司各个团队的同事喝咖啡聊天的次数，你都数不过来。你最终会习惯于一个例行公事，和你的团队每两周进行一次短跑，构建新的功能，和你的团队成员进行一对一的交流，等等。

Eventually, you begin to ask yourself: how do I actually succeed at this job?

最终，你开始问自己: 我怎样才能在这份工作中取得成功？

As a new grad engineer, what I would’ve loved when starting out is a concrete list of less obvious aspects of the job that I could’ve focused on to perform more effectively and grow faster. Think side quests in your favorite RPG that, when completed, give you experience, gold, and maybe, special items.

作为一个刚毕业的工程师，当我刚开始工作的时候，我喜欢的是一个具体的清单，上面列出了一些我本可以专注于工作的不那么明显的方面，这些方面可以使我工作更有效率，成长得更快。想想你最喜欢的 RPG 中的侧任务，当完成时，给你经验，黄金，或许，特殊物品。

In this post, I outline a few thoughts as advice I would’ve given my younger self. These are the most important lessons I’ve taken away in my first year working as an engineer at Plaid, ones I wish the younger Evan knew and performed.

在这篇文章中，我列出了一些想法，作为给年轻时的自己的建议。这些是我在 Plaid 当工程师的第一年学到的最重要的课程，我希望年轻的 Evan 能够了解并且能够完成。

Lesson #1: Understand the End-To-End Service Architecture

第一课: 了解技术架构

In your first few weeks, you’ll likely be tasked with building new functionality and fixing a handful of bugs. Most likely, this work will be constrained to only one or two services. Furthermore, you may be overwhelmed by the abundance of information that you need to pick up to properly start contributing to your team.

在开始的几个星期里，你可能要负责构建新的功能和修复一些 bug。最有可能的是，这项工作将仅限于一个或两个服务。此外，你可能会被大量的信息所淹没，而这些信息正是你开始为你的团队做出贡献所需要的。

I would argue that one of the most valuable pieces of learning you can acquire is a strong mental model of all the existing services. Learn what each one does at a very high level, and how they talk to one another in the overarching dependency graph. Understand the philosophy behind each service and the objectives they’re trying to achieve. Then, drill deeper into the implementation details as you encounter opportunities to work on a service. It helps to think about this like Elon Musk does with knowledge.

我认为，你可以获得的最有价值的学习方法之一，就是对所有现有服务建立一个强大的心智模型。了解每个人在非常高的级别上做什么，以及他们如何在总体依赖关系图中相互交流。了解每项服务背后的哲学，以及他们试图实现的目标。然后，在遇到服务工作机会时，深入钻研实现细节。像伊隆 · 马斯克那样用知识去思考这个问题是有帮助的。

Doing this is much easier if you’re working at a small startup; the scale and complexity of services often correlate strongly with the size of the team. If you’re working in Big Tech, do this for your engineering group or division, and limit the scope to the immediate customer-facing product your code will affect.

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

This is important for a number of reasons.

这一点很重要，原因有很多。

• It helps contextualize how your work will eventually affect end users. 它有助于了解您的工作最终将如何影响最终用户
• It improves your understanding of how the product works. 它提高了你对产品工作原理的理解
• It’s important for engaging in high-level architectural discussions. 参与高层次的架构讨论是很重要的
• It will enable you to drive changes across multiple teams. 它将使您能够跨多个团队进行更改

Conveniently, engineering teams are usually structured around service boundaries, so this could be a nice mnemonic to aid in learning about the various services. Granted, it may be difficult to internalize, but having a diagram of boxes and connecting arrows definitely helps. Get a senior engineer to draw one for you and stare at it before you go to sleep every night.

方便的是，工程团队通常是围绕服务边界进行结构化的，因此这可以作为学习各种服务的一个很好的助记符。当然，这可能很难内化，但是有一个盒子和连接箭头的图表肯定有帮助。每天晚上睡觉前，找一个高级工程师给你画一个，然后盯着它看。

Not doing this has been one of many regrets I’ve had over the past year. I should’ve done this immediately during the onboarding process, but I shook it off as unnecessary at the time. Realize that knowledge compounds over time, and having a strong mental model of the entire service stack is a crucial building block in better understanding how an engineering organization works.

在过去的一年里，我有很多遗憾，其中一个就是没有这样做。我应该在上岗的时候就这么做的，但是当时我认为没有必要这么做。认识到知识会随着时间的推移而不断增加，拥有整个服务堆栈的强大心智模型是更好地理解工程组织如何工作的关键基石。

I apologize to my past self for the foregone growth.

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

Lesson #2: Learn the Fundamentals of your Tech Stack

第二课: 了解技术的基础知识

You can get by well just knowing how to code and conjuring magical data structures and algorithms from thin air, as was taught in college. In fact, this is mostly what companies test for in software interviews. However, building systems involves so much more than just writing code. Consider what it takes to get production-level code running.

就像大学里教的那样，你只需要知道如何编码和凭空变出神奇的数据结构和算法就可以了。事实上，这大多是公司在软件面试中测试的东西。然而，构建系统所涉及的不仅仅是编写代码。考虑一下如何使生产级代码运行起来。

Here’s a quick list off the top of my head. Logging, Secrets, Metrics, Containers, Servers, Databases, Load Balancers, Queues, Inter-Service Communication, Continuous Integration, Deployments, and so on.

下面是我脑海中的一个快速列表。日志、机密、度量、容器、服务器、数据库、负载均衡器、队列、服务间通信、持续集成、部署等等。

Unfortunately, most of these are things you will never learn in college, at least if you went through the traditional US computer science curriculum. That’s fine. You’ll pick up the necessary skills quickly on the job, and learn to utilize these fancy, powerful tools in no time.

不幸的是，大多数这些东西你永远不会在大学里学到，至少如果你通过传统的美国计算机科学课程。没关系。你会在工作中迅速掌握必要的技能，并且学会在短时间内利用这些奇特而强大的工具。

Nonetheless, I would argue that it’s valuable to go beyond just “knowing how to use tool X from skimming examples” to “understanding the internals of tool X or language Y by reading online documentation, blog posts, and code”.

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

For example, there is a substantial difference between knowing how to use gRPC — ”Oh, this lets us call typed functions in different services? Cool!” — and grokking that the underlying implementation utilizes HTTP/2 and maintains persistent connections between clients and servers. From experience, investing a bit of time into reading documentation and blog posts about the internals of gRPC has enabled me to make better architectural decisions and quickly debug failure modes in your system. Furthermore, since this is often something that few people do, you get to be an expert in a niche part of your company’s tech stack. People will eventually come to you bearing gifts in exchange for your sage advice.

例如，知道如何使用 gRPC 和知道如何使用 gRPC 之间有很大的不同ー“哦，这使我们可以在不同的服务中调用类型化函数？酷! ”ー以及探索底层实现利用 HTTP/2 并维护客户端和服务器之间的持久连接。根据我的经验，花一点时间阅读关于 gRPC 内部构造的文档和博客文章，使我能够做出更好的架构决策，并快速调试系统中的失败模式。此外，由于这通常是很少有人会做的事情，所以你可以成为公司技术堆栈中某个利基领域的专家。人们最终会带着礼物来找你，以换取你的明智建议。

This generalizes to various technologies used by your engineering organization. Of course, there’s diminishing returns in investing too much time into learning; you still have a day job to tend to creating business value. A good litmus test I often use is seeing how well I’m able to explain the benefits and downsides of a technology to someone else. You should aspire to be able to walk up to a random engineer and start a 5 minute long conversation about it.

这可以推广到工程组织使用的各种技术。当然，在学习上投入太多的时间是有报酬递减的; 你还有一份日常工作来创造商业价值。我经常使用的一个很好的测试就是看看自己能否很好地向别人解释一项技术的好处和缺点。你应该立志能够走到一个随机的工程师面前，开始一个 5 分钟的长谈。

Now go read up on the logging infrastructure at your company.

现在去研究一下您公司的日志基础设施。

Lesson #3: Move Fast and Improve Things

第三课: 快速行动，从微小的改善入手

You may have heard the now Silicon-Valley-famous quote, “Move Fast and Break Things”. Long story short, you do not want to be embodying this ethos, despite all that pent-up post-graduation excitement of wanting to write code and ship a ton of features. Though “Break Things” was probably meant as a hyperbole — unless Zuck actually wanted Facebook engineers to break things — it does instill the mindset that it’s fine to ship breaking changes, as long as you’re moving quickly.

你可能听说过现在硅谷的一句名言，“快速行动，打破常规”。长话短说，你不会想要体现这种精神，尽管毕业后有很多想要编写代码和发布大量功能的压抑的兴奋。虽然“打破常规”可能是一种夸张的说法ーー除非扎克真的想让 Facebook 的工程师打破常规ーー但它确实灌输了这样一种思想，即只要你行动迅速，就可以推行打破常规的变革。

I prefer the phrase “Move Fast and Improve Things”. The subtext here is that systems are already functional in the first place i.e. nothing is broken, for you to be able to improve them. I would argue that Moving Fast and Doing Things Correctly are things already expected of us as engineers who have passed the 6 feet high interview bar.

我更喜欢“快速行动，改进事情”这句话。这里的潜台词是，系统从一开始就已经在运行了，也就是说，没有任何东西被破坏，这样你才能够改进它们。我认为，作为一名通过了 6 英尺高的面试门槛的工程师，我们早就应该快速行动、正确做事了。

Making things better, on the other hand, is much more of an acquired skill. First, you have to notice that something is missing; in my experience, this comes only with, you guessed it, experience. Forgive the diacope. Second, you need to take the initiative to either communicate this gap to other engineers, or allocate resources (time, mental energy) to fix the problem yourself. Third, and finally, this change needs to be announced to people who care about them. Because hey, if a tree falls in a forest… you get the point. It’s a nontrivial amount of effort to improve things, especially if they’re not related to your sprint goals. However, everyone else will thank you for making their lives easier.

另一方面，让事情变得更好，更多的是一种后天获得的技能。首先，你必须注意到一些东西正在消失; 根据我的经验，这只会伴随着，你猜对了，经验。原谅我的外表。其次，你需要主动地与其他工程师沟通这个差距，或者分配资源(时间、精力)自己解决问题。第三，也是最后一点，这种改变需要向关心他们的人宣布。因为，嘿，如果一棵树倒在森林里... ... 你就明白了。这是一个不小的努力来改善事情，特别是如果它们与你的 sprint 目标无关。然而，其他所有人都会感谢你让他们的生活变得更加轻松。

I’ve done this enough over the past year that I have a mental list of low hanging, high ROI improvements dangling from my brain tree. Here it is, for your perusal:

在过去的一年里，我已经做得够多了，我的大脑树上挂着一张低悬、高投资回报率的改进清单。这里是，供你细读:

• Developer Tools (linting, third party package versions) 开发工具(linting，第三方软件包版本)
• Monitoring (metrics, alerts, logging) 监视(度量、警报、日志)
• Interface Refactoring (improving readability and maintainability of code) 接口重构(提高代码的可读性和可维护性)
• Bugs and TODOs from [Insert Your Favorite Issue Tracker Here] that no one ever bothered to work on because they’re nice-to-haves, but not crucial 缺陷和待办事项[插入你最喜欢的问题跟踪器在这里] ，没有人曾经费心工作，因为他们是善待有，但不是关键

One hack I’ve come up with to help me manage such a list is to maintain a backlog of tasks (use a priority queue) that you can pick off from whenever you’re blocked on your main sprint work. I would place quality-of-life improvements and bug fixes that are non-urgent here. Of course, project work would preempt working on these so-called “improvements”.

我想出的一个方法可以帮助我管理这样一个列表，那就是维护一个任务的积压(使用优先级队列) ，当你在主 sprint 工作中遇到阻碍时，你可以从中挑选出来。我会提出生活质量的改进和错误的修复，这些都是非紧急的。当然，项目工作会先于这些所谓的“改进”。

In a similar vein, the blog post titled Done and Gets Things Smart is an excessively verbose rant that makes for good bedtime reading.

同样的道理，标题为“做好并聪明地做事”的博客文章过于冗长，有利于睡前阅读。

Lesson #4: Understand that Processes are a Necessary Evil

第四课: 了解开发流程

We’re not talking about the Operating System concept of a process here. As quoted from the dictionary, a process is “a series of actions or steps taken in order to achieve a particular end.” As abstract as the concept is, I did not fully internalize it until I started working full-time.

这里我们不是在讨论进程的操作系统概念。正如字典中引用的那样，过程是“为了达到特定目的而采取的一系列行动或步骤”尽管这个概念很抽象，但直到我开始全职工作，我才完全内化它。

I’m not a huge fan of processes, and held a stronger disdain for them when I first started on the job. They reek of bureaucracy — or whatever it is people in suits do all day — and are antithetical to engineering values like moving fast and iterating quickly. In fact, to my delight, I’m convinced that everyone I work with share a similar contempt for processes.

我不是过程的狂热爱好者，并且在我刚开始工作的时候对它们有着强烈的鄙视。它们散发着官僚主义的气息ーー或者说是那些西装革履的人整天都在做的事情ーー而且与工程学的价值观(如快速行动和快速迭代)背道而驰。事实上，让我高兴的是，我确信每个和我一起工作的人都对过程有着相似的蔑视。

However, I’ve come to realize that processes are very important for ensuring long term business value. Not only do they ensure that a commonly done set of tasks can be committed to and improved upon, they also minimize variance in doing those tasks in large teams. Processes ensure execution consistency and are necessary because unlike software, humans are moving parts that often make mistakes.

然而，我已经意识到流程对于确保长期业务价值非常重要。它们不仅可以确保一组共同完成的任务可以被提交和改进，而且还可以最大限度地减少在大型团队中完成这些任务时的差异。过程确保了执行的一致性，并且是必要的，因为与软件不同，人是移动的部件，经常会犯错误。

It’s true that they introduce friction and complexity into getting more concrete things done, but I’ve come to realize that processes are essential complexity. In fact, processes are what hold the fabric of an organization together as it grows. If every engineer in a team of 50 were to use guerilla tactics to ship features however every one of them preferred, imagine the chaos that would ensue.

的确，它们在完成更具体的事情时会引入摩擦和复杂性，但我已经意识到，过程本质上就是复杂性。事实上，过程是在组织成长过程中将其结构连接在一起的东西。如果一个 50 人的团队中的每个工程师都使用游击战术来发布他们所喜欢的功能，想象一下随之而来的混乱。

Processes can take many forms, and include the following things.

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

• Writing a Technical Spec for huge projects. 为大型项目编写技术规范
• Documenting unknown parts of the system. 记录系统的未知部分
• Doing a Postmortem for all production issues. 对所有生产问题进行验收
• Sending out a message to communicate any important change to a system. 向系统发送一条消息来传达任何重要的更改

The astute reader may notice a common thread among all of these: they involve communicating information about something to other people on the team. There is one silver lining here though, which is that overcommunication is never bad. Not communicating things is almost always worse than communicating, unless you’re working on secret projects with classified information.

精明的读者可能会注意到所有这些问题中的一个共同点: 它们涉及到向团队中的其他人传递有关某事的信息。不过，还是有一线希望的，那就是过度沟通从来都不是坏事。不交流的事情几乎总是比交流更糟糕，除非你是在用机密信息进行秘密项目。

Lesson #5: Write more Code Documentation

第五课: 编写更多的代码文档

Concretely, your job as an engineer is to solve business problems and deliver value to the company. The implementation of this mostly involves writing code and shipping features, but there are often more important tasks. One of these, as was hinted at earlier, is writing documentation.

具体地说，你作为一个工程师的工作就是解决业务问题并为公司提供价值。这种方法的实现主要涉及编写代码和发布特性，但通常还有更重要的任务。其中之一，正如前面提到的，是编写文档。

Documentation may take various forms: code comments, commit messages, emails, google docs, wiki entries, README files, and so on. The format depends on the context in which the information will be used. For instance, emails serve as a wide-reaching, permanent, and searchable documentation format that should be used for non-urgent content such as important announcements or engaging in longer-term async conversations.

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

Here are two less obvious, yet crucial purposes, that are served by docs.

这里有两个不那么明显但却至关重要的用途，由文档提供。

• They reduce the 他们减少了bus factor 总线因数 on your team. 在你的队伍里
• They act as a permanent archive for temporal context that will inevitably fade. 它们作为永久的档案，存放着不可避免会褪色的时间背景

The more documentation you write, the better and faster you get at it. Inevitably, technical writing is a valuable skill to have throughout your entire career, and there is no better time to start than now. It’s one of the most scalable methods for information diffusal (as compared to more transient methods such as speech and instant messaging), and becomes more consequential as the organization grows. Now, do you want to Improve Things? Go write some docs and send it out to your team.

你写的文档越多，你就能越快越好地完成它。不可避免的是，技术写作是贯穿你整个职业生涯的一项有价值的技能，没有比现在开始更好的时机了。这是一种最可扩展的信息传播方法(相对于更加短暂的方法，如语音和即时通讯) ，并且随着组织的增长变得更加重要。现在，你想要改进吗？去写一些文件，然后发给你的团队。

This blog post showcases a fun little example of a page-long git commit message for a single character code change, an epitome of valuable documentation.

这篇博客文章展示了一个有趣的小例子，一页长的 git 提交消息用于单个字符的代码更改，这是一个有价值的文档的缩影。

Conclusion

总结

Having touched a lot of systems and worked on a myriad of different things over the past year at Plaid, these 5 points have been my most important takeaways. These are personal lessons that may not apply to everyone, so take these with a grain of salt. I still hope you find them useful for your burgeoning career.

在过去的一年里，我尝试了很多系统，做了很多不同的事情，这 5 点是我最重要的收获。这些个人经验可能并不适用于每个人，所以不要轻信这些。我仍然希望它们对你蓬勃发展的事业有所帮助。

Thanks for reading!

谢谢阅读！

新人加入一个开发团队时，要干五件事。前面四件事是了解技术架构、了解开发流程、补强基础知识、从微小的改善入手（比如关掉几个 issue）。这些都是常识，但是第五件事，很多新人都没意识到，你应该要去做，而且完全有能力做，那就是 你要为团队写文档 。

国内的现状是，项目文档很少，或者索性没有，因为大家的精力都被开发占据了，没有余力写文档。新人了解技术细节的方式，就是别人跟你口头说一下，然后自己去看代码。你正好趁着熟悉代码的过程，补写一些文档。不需要写得很好，只要忠实记录代码的线索、架构的细节，能为以后的人（包括你自己）节省一点时间就可以了。

我自己的体会是，写文档对一个人的锻炼是很大的。（1）可以熟悉项目；（2）可以提高表达能力；（3）可以提高技术能力，因为只有理解了代码才能表达出来，文档越清晰，就代表思路越清晰；（4）可以提高个人影响力，文档写得越好，看的人就越多。久而久之，你就会成为项目的代言人，别人有问题就会来找你。

总之，新人要重视写文档，主动为整个团队写文档，对个人成长有帮助，对团队也会有帮助。不停地写，大量地写，现在就开始写。长期中，你会意识到这给自己带来的巨大价值。

-- 阮一峰

参考

• http://www.ruanyifeng.com/blog/2019/12/weekly-issue-87.html