测试开发人员与开发人员

by Will Hughes

威尔休斯(Will Hughes)

如何升级为开发人员 (How to Level up as a Developer)

Being a productive developer is something you can learn through experience, books, or trial and error. But, one of the best ways to become a productive developer is to learn directly from a developer who is already productive. I interviewed some of the most productive engineers at Facebook in order to find an underlying structure for how these developers operated at peak productivity.

作为一名富有成效的开发人员，您可以通过经验，书籍或反复试验来学习。 但是，成为有生产力的开发人员的最好方法之一就是直接向已经有生产力的开发人员学习。 我采访了Facebook上一些最有生产力的工程师，以便找到这些开发人员如何以最高生产力工作的基本结构。

级别1：减少不必要的麻烦 (Level 1: REDUCE UNNECESSARY DISTRACTIONS)

This section may seem obvious, but it’s the little things that add up and cost us the most in productivity.

该部分可能看起来很明显，但它是一些小事情，它们加起来并导致我们在生产力上的花费最大。

PUSH BACK ON MEETINGS

回覆会议

“I go to as few meetings as possible. I generally don’t go to any recurring meetings. This might not work for everybody b/c managers like to schedule recurring meetings and you don’t want to piss off your manager. but then I’d recommend showing the cost of a meeting (10 engineers x 30 minutes/week + 10 minutes of task switching overhead = we paid an engineer to spend half a day/week in that meeting. that’s a lot of time. I always push for replacing recurring meetings with scheduling a meeting when there is something to discuss or a quick standup.” — <anonymous>

“我去参加的会议越少越好。 我通常不参加任何定期会议。 对于可能希望安排定期会议的每个b / c经理来说，这可能并不奏效，您也不想惹恼您的经理。 但是我建议您显示一次会议的费用(10个工程师x 30分钟/周+ 10分钟的任务切换开销=我们付钱给工程师在该会议中花半天/周的时间。这是很多时间。当有需要讨论的话题或需要快速站起来时，总是要用安排会议来代替定期会议。” — <匿名>

Something many engineers pressed hard was that meetings can be valuable when the meeting is needed. But, we must maintain a critical eye and determine whether each individual meeting is worthwhile.

许多工程师迫切需要解决的问题是，当需要召开会议时，会议可能会很有价值。 但是，我们必须保持批判性的眼光，并确定每次单独的会议是否值得。

BE PREPARED TO DO SMALL TASKS

准备小任务

“While building or diffing[1] I quickly clear out my email queue to stay at inbox 0” — Michael Novati

“在构建或差异[1]时，我会Swift清理我的电子邮件队列以保留在收件箱0中” – Michael Novati

There may be a time where you have just finished a task and now have 5–15 minutes before a meeting, or maybe you just started a test run that will take 1, 5, or 15 minutes. The common reaction is “I can’t get any significant work done in that amount of time”. Which seems logical, many tasks may take from 30 minutes to an hour of focused concentration, but not all tasks. Many of the engineers mentioned that they keep lists of small tasks that they can easily take care of in these slower moments throughout the day. Catching up on emails, diff reviews, responding to internal posts, or even small diffs/refactors can fill in these time slots in order to make you more productive and up to date throughout the day.

可能有一段时间您刚刚完成一项任务，现在距会议还有5至15分钟，或者您可能刚刚开始进行测试需要1、5或15分钟。 常见的React是“我无法在这段时间内完成任何重要的工作”。 看来合乎逻辑，许多任务可能需要30分钟到一个小时的集中精力， 但不是所有任务。 许多工程师提到，他们会保留一些小任务清单，以便在一天中这些较慢的时刻轻松完成这些任务。 可以在这些时间段内获取电子邮件，差异评论，对内部帖子的回复，甚至是很小的差异/重构，以使您一天中的工作效率更高且最新。

GET NOISE CANCELLING HEADPHONES

获得降噪耳机

If you’ve ever been to one of the younger software companies, you’ll notice how floors are set up as large open areas. This is a double edged sword for engineers. On one hand, you are physically closer to your team. Collaboration and camaraderie between teammates reaches an all time high when you can ask questions and bond with your teammates. The downside to this is that now your precious development focus can be sidetracked by noise in the surrounding area. Sound travels, and when you’re trying to grasp a problem, a loud conversation behind you can be detrimental to your productivity. This is where noise cancelling headphones come in. Technology is far more advanced than simply putting large walls around your ear and turning up the volume. Real noise cancelling headphones cancel out background noise and muffle conversations in the immediate vicinity. After my interview with Michael Novati I bought the headphones he recommended and I honestly could not see my development process without them. It becomes so evidently clear how much background noise exists in offices once you have something to compare it to.

如果您曾经去过一家较年轻的软件公司，就会注意到如何将楼层设置为大型开放区域。 对于工程师来说，这是一把双刃剑。 一方面，您在身体上更接近团队。 当您可以提出问题并与队友建立联系时，队友之间的协作和友爱达到了前所未有的高度。 不利的一面是，现在您宝贵的开发重点可能会因周围区域的噪音而偏离。 声音在传播，当您尝试解决问题时，背后的大声交谈可能会损害您的工作效率。 这就是消除噪音的耳机的用武之地。技术远比简单地在耳朵上盖大墙壁并调高音量要先进得多。 真正的降噪耳机可以消除附近的背景噪音和马弗声。 在接受Michael Novati采访之后，我买了他推荐的耳机 ，说实话，没有它们我看不到我的开发过程。 很明显，一旦您有比较的背景噪音，办公室中就会有多少背景噪音。

WORK WHEN PEOPLE CAN’T BOTHER YOU

当人们无法忍受您时的工作

(On dealing with interruptions) “Moving to NY two years ago probably helped a lot” — Adam Ernst

(关于处理中断)“两年前搬到纽约可能有很大帮助” —亚当·恩斯特

“I usually save harder, more complicated tasks for Wednesdays (when I work from home uninterrupted)” — Bob Baldwin

“我通常会在星期三(当我不间断在家工作时)省去更艰巨，更复杂的任务” —鲍勃·鲍德温

“I’m not able to actually get much done during ‘normal’ working hours and rely on the extra time to actually accomplish stuff” — <anonymous>

“我无法在'正常'的工作时间内完成很多工作，只能依靠额外的时间来实际完成工作” – <anonymous>

“I often get more done between 6 and 9 than during the rest of the day. long uninterrupted time is critical.” — <anonymous>

“我通常在6到9点之间比一天中的其余时间做更多的事情。 长时间不间断至关重要。” — <匿名>

I’ll admit it, one of the biggest takeaways from talking to the engineers was that many of them work long hours. Some interesting tidbits about why they worked such long hours were interesting though. During the early mornings, late nights, and weekends, these engineers revelled in the fact that no one was interrupting them. By finding times throughout the day when they had minimal interruptions, they had the time to push through large tasks and get code out.

我承认，与工程师交谈的最大收获之一就是其中许多人长时间工作。 但是，一些有趣的关于为什么他们要工作这么长时间的小知识很有趣。 在清晨，深夜和周末，这些工程师陶醉于没有人打扰他们的事实。 通过在一天中找到中断最少的时间，他们有时间完成大型任务并获得代码。

REDUCE NOISY EMAILS/NOTIFICATIONS

减少嘈杂的邮件/通知

“I turned off all non-emergency email alerts. Only getting emails that need action and forcing myself to check the tasks/review pages at a reasonable rate actually helped me miss fewer things by assuming they were spam” — Ari Chivukula

“我关闭了所有非紧急电子邮件警报。 仅收到需要采取行动的电子邮件并强迫自己以合理的速度检查任务/审阅页面，实际上，我假设它们是垃圾邮件，从而使我少了一些东西。

If you stopped to check your email every time you got a new mail, your day may get completely derailed by distractions. By reducing and filtering notifications to only essentials, you can work longer periods undistracted.

如果您每次收到新邮件时都停止检查电子邮件，那么您的一天可能会完全被干扰分散。 通过将通知减少和过滤为仅基本内容，您可以长时间分散工作。

DON’T LOSE STATE

不要失去状态

“When I’m interrupted (or have to go to the bathroom) I “save state” in my head, like saving state in a Gameboy Emulator, so that I can return and recover as fast as possible” — Michael Novati

“当我被打扰(或不得不去洗手间)时，我在脑海中“保存状态”，就像在Gameboy Emulator中保存状态一样，以便我可以尽快返回并恢复。” — Michael Novati

“Always stop the day midway through a fairly simple or mechanical task. This gives you an easy place to pick up the next day and get back in the zone, instead of starting from scratch.” — Adam Ernst

“总是在相当简单或机械的任务中途停止一天。 这为您提供了一个轻松的地方，让您第二天就可以起身回到区域，而不必从头开始。” —亚当·恩斯特

For me, losing state in terms of programming is when I’m thinking deeply about a problem, I’m interrupted, and I forget what I was thinking about, meaning that I have to go through the whole thinking process again.

对我来说，在编程上处于失落状态是当我对问题进行深入思考，被打扰，忘记了我在想什么的时候，这意味着我必须重新经历整个思考过程。

One of the best things to do in the case of an interruption while you’re in “the zone” is to defer the interruption. If you’re interrupted while focusing, tell the person that you’ll get back to them in a bit, make a quick note of it, and continue working until you hit a reasonable stopping point. Once you hit that stopping point, knock off all stacked interruptions.

在您处于“区域”中时发生中断时，最好的办法之一就是推迟中断。 如果您在专注时被打断，请告诉对方您会很快与他们联系，快速记录下来，然后继续工作，直到达到合理的停止点为止。 到达该停止点后，请消除所有堆积的中断。

When an interruption can’t be put off, there are many ways to “save your state”. This can be done by writing down your current thought process, writing a failing test, or by simplifying the problem in your mind.

当无法推迟中断时，有很多方法可以“保存您的状态”。 可以通过记下当前的思考过程，编写失败的测试或简化您的想法来完成。

第2级：写出“更好”的DIFFS (Level 2: WRITE “BETTER” DIFFS)

Good code can mean many things. It can be functional, easy to review, sustainable, etc.

好的代码可能意味着很多事情。 它可以是功能性的，易于审核的，可持续的等。

WRITE SMALLER DIFFS

写较小的差异

“Lots of small diffs is like “showing your work” when doing a problem set in engineering” — <anonymous>

“处理工程中遇到的问题时，很多小的差异就像“展示您的工作”” — <anonymo us>

Every engineer I interviewed stressed hard how splitting your code changes into logical modules made it easier for other people to understand and accept quickly. By reducing the cognitive load of the diffs they sent out, reviewers were more confident in accepting changes. Also, by reducing the size of the diffs, the changes were less intimidating for reviewers to look at, so the throughput was faster.

我采访的每位工程师都在努力强调，如何将您的代码更改分成逻辑模块，以使其他人更容易快速理解和接受。 通过减少他们发送的差异的认知负担，审阅者对接受更改更有信心。 此外，通过减少差异的大小，这些更改对于审阅者而言并不那么令人畏惧，因此吞吐量更快。

Full disclosure, I gathered the list of engineers questioned for this article by querying which engineers had committed the most diffs during the preceding six month. That would likely lead to a subset of engineers who write many small diffs, as opposed to fewer large diffs.

通过全面披露，我通过查询在过去六个月中差异最大的工程师，收集了本文所质疑的工程师列表。 这可能会导致一部分工程师编写许多小差异，而不是更少的大差异。

STACKING DIFFS[2] && MULTITASKING

堆叠DIFFS [2] &&多任务

Most of the engineers mentioned that they will stack diff changes on top of each other, creating dependencies for their logic as they go:

大多数工程师提到，他们会将diff更改彼此叠加，从而在逻辑上创建依赖项：

“Sometimes, when I have a really big diff that developed organically, I will go back and start over and divide it up into logical steps and that often results in me changing things along the way that improve the code quality overall.” — <anonymous>

“有时候，当我有一个非常大的差异并有机地开发时，我会回过头来重新开始，并将其划分为逻辑步骤，这常常导致我改变方式来改善整体代码质量。” — <匿名>

“I never stack diffs, rather I’ll have a few independent things I’m working on in parallel and alternate between them as I wait on reviews. Also breaking up a large change into independent pieces works really well, e.g adding an interface, adding an endpoint with some // TODOs in it… effectively stacking without hard dependencies between the diffs and using placeholders instead. Structuring your code so that you don’t need stacking or sub branches generally means that each diff is easily reviewable, shipable, and revertable.” — Michael Novati

“我从不堆叠差异，相反，我将并行处理一些独立的事务，并在等待审查时在它们之间交替进行。 将大型更改分解为独立的部分也可以很好地工作，例如添加接口，添加其中包含一些// TODO的终结点……有效地堆叠而无需在差异之间形成硬依赖性，而使用占位符。 对代码进行结构化，以至于不需要堆栈或子分支，这通常意味着每个差异都易于检查，可运输和可恢复。 —迈克尔·诺瓦蒂(Michael Novati)

“If I feel like I’m putting multiple diffs into a single diff, then I pull it up in the stack and put one of the logical pieces underneath” — <anonymous>

“如果我想将多个差异放入单个差异中，那么我将其拉到堆栈中，并在其中放置一个逻辑部分” – <anonymous>

“Small, or at least easy to review, diffs. Not only are they easier and faster to review, they make me write better code because I think through what I’m doing one logical piece at a time, and I waste very little time debugging as a result. Also, expertise with stacked diffs to make the small diffs manageable” — Ari Chivukula

“差异很小，或者至少易于查看。 它们不仅更容易，更快捷地进行检查，而且使我编写更好的代码，因为我认为我一次完成一个逻辑部分，并且因此浪费了很少的时间进行调试。 此外，还具有堆叠式差异的专业知识，使小型差异易于管理” – Ari Chivukula

“I use stacked diffs extensively. Beyond letting me stay unblocked while I’m waiting for code reviews, thinking about ways to split up code into smaller diffs often makes me think about the big picture of what I’m working on, and even simplify the architecture.” — <anonymous>

“我广泛使用堆叠式差异。 除了让我在等待代码审查时保持畅通之外，思考将代码拆分为较小差异的方法还常常使我想到正在研究的全局，甚至简化体系结构。” — <匿名>

Whether engineers used stacked diffs or worked on multiple diffs in parallel appeared to have little effect on their outgoing productivity, indicating that both methodologies allow engineers to be incredibly productive.

工程师使用堆叠式diff还是并行处理多个diff似乎对他们的输出生产率几乎没有影响，这表明这两种方法都使工程师的生产率令人难以置信。

UNIT TESTING

单元测试

“I test the minimum amount to make me feel comfortable” — Michael Novati

“我测试了使我感到舒适的最低量” – Michael Novati

“People feel more confident accepting code that has unit tests.” — <anonymous>

“人们对接受具有单元测试的代码感到更加自信。” — <匿名>

Unit testing can be a contentious issue at some tech companies, and, for the most part each team and company will have it’s own guidelines for whether engineers should write tests. One thing can be said though, if you’re at a company where someone else is going to be changing the code you’ve written, the best way to make sure that someone else doesn’t break that piece of code, is to enforce its functionality in tests.

在某些科技公司中，单元测试可能是一个有争议的问题，而且在大多数情况下，每个团队和公司都会有自己的准则来决定工程师是否应该编写测试。 但是可以说，如果您在一家公司中，别人将要更改您编写的代码，那么确保别人不会破坏该代码段的最佳方法是： 在测试中加强其功能。

COMMUNICATE

通信

“For trickier diffs, I will add a small number of appropriate reviewers, share the diff in appropriate groups. I’ll usually ping a diff once a day regardless, if it doesn’t get any action. If there is no action for a few days, I’ll ask people what they find intimidating about the diff and make changes to the structure. Finally I always communicate as much as I can in the title. I always start with “[product/tag]” — so people know vaguely what the diff is about, and if I expect a quick accept I’ll put something like “[product-ASAP]” or “[product-PUSHBLOCKER]”” — Michael Novati

“对于棘手的差异，我将添加少量适当的审阅者，并在适当的组中共享差异。 无论是否采取任何措施，我通常每天都会对diff进行一次ping操作。 如果几天没有采取任何行动，我将询问人们对差异有何恐惧，并对结构进行更改。 最后，我总是在标题中尽可能多地交流。 我总是以“ [product / tag]”开头-这样人们就模糊地知道了差异是什么，如果我希望快速接受，我会输入“ [product-ASAP]”或“ [product-PUSHBLOCKER]” ” —迈克尔·诺瓦蒂(Michael Novati)

This one should be obvious, but, there are many ways to communicate on your diff reviews. A general rule of thumb is to play it diff by diff. If the diff will be reviewed by someone who doesn’t interact with you on a daily basis, you may want to include more context in the description and title than you normally would if you are just getting a review from a teammate. You can also comment on the sections of your diff that you really want people to double check you on, in case the logic gets a bit complicated.

这应该是显而易见的，但是，您可以通过多种方式就您的差异评论进行交流。 一般的经验法则是逐次比较。 如果差异将由每天不与您互动的人进行审核，则与仅从队友那里进行审核相比，您可能希望在描述和标题中包含更多上下文。 如果逻辑有些复杂，您还可以对差异部分中您确实希望人们再次检查的内容发表评论。

Setting expectations early through design meetings may also ease the process of writing the code, building good APIs and structure in order to integrate systems can be a huge pain reliever further down the development line.

通过设计会议尽早设定期望，也可以简化代码编写过程，建立良好的API和结构以集成系统，这可以进一步减轻开发线的痛苦。

Don’t be afraid to ping reviewers on your diff. If they really don’t want to review your diff, they can resign, or suggest someone else. Diffs that stick around in queues forever are just asking for merge conflicts in the future.

不要害怕对您的差异进行审核。 如果他们真的不想查看您的差异，他们可以辞职或建议其他人。 永远留在队列中的差异只是在将来要求合并冲突。

第3级：成为团队合作者 (Level 3: BEING A TEAM PLAYER)

Coding is a team sport, and as with all team sports, there is an upper limit to how much you can accomplish working alone.

编码是一项团队运动，与所有团队运动一样，您可以独自完成的工作量有一个上限。

REVIEW OTHER PEOPLE’S CODE

查看其他人的代码

“Quick scan, read through, patch it, test it, comment.” — <anonymous>

“快速扫描，通读，修补，测试，评论。” — <匿名>

Doing more reviews to increase your code output sounds like an oxymoron. We can reframe “doing more reviews” as “clearing other people’s queue”. When you change perspective like this, it becomes clearer, that if you’re clearing the diff queue of other engineers, those engineers are more likely to review your diffs and unblock you.

进行更多评论以增加代码输出听起来很矛盾。 我们可以将“进行更多评论”重组为“清除其他人的队列”。 当您以这种方式更改视角时，就会很清楚，如果您要清除其他工程师的差异队列，那么这些工程师更有可能查看您的差异并解除阻止。

BUILD TRUST WITH YOUR REVIEWERS/TEAMMATES

与您的评论者/团队建立信任

“I have a core group of engineers with whom I’ve built up a relative sense of trust, and we generally make an effort to review each other’s code quickly” — <anonymous>

“我有一个核心的工程师团队，与他们建立了相对的信任感，我们通常会努力快速审查彼此的代码” – <anonymous>

This point merges a bit into the previous one. If you have a core group of reviewers who trust each other to write good code, you can move forward with changes relatively safely, trusting that if an engineer does break something, they will work really hard to fix it the moment it’s discovered.

这一点与上一个合并。 如果您有一个核心的审阅者小组，他们彼此信任可以编写出色的代码，则可以相对安全地进行更改，并相信如果工程师确实破坏了某些内容，他们将在发现问题后立即努力解决。

BE TRANSPARENT ABOUT WHAT YOU’RE WORKING ON

对您正在做的事情保持透明

“Use RFC (Request for Comment) diffs when doing greenfield development. The churn of getting feedback on headers/proposed APIs is well worth the time saved compared to changing direction later.” — Adam Ernst

“在进行未开发的开发时，请使用RFC(征求意见)差异。 与稍后更改方向相比，节省标题/提议的API反馈的花费是值得的。 —亚当·恩斯特

If people don’t know what you’re working on, the amount of information they’ll need process when reviewing a diff will be far more confusing. By keeping reviewers/teammates in the loop early, they can give feedback before large swathes of work are done, removing roadblocks down the line.

如果人们不知道您在做什么，那么在查看差异时他们将需要处理的信息量将更加令人困惑。 通过让审阅者/团队成员尽早进入循环中，他们可以在完成大量工作之前给出反馈，从而消除了生产过程中的障碍。

GIVE GOOD FEEDBACK

给予良好的反馈

“Focus on giving high-level feedback, rather than nit-picking. Point out bugs if you see them, but trust engineers to have tested (and that they’ll fix any bugs that arise)” — Bob Baldwin

“专注于提供高水平的反馈，而不是挑剔。 指出错误(如果您看到的话)，但请工程师进行测试(并且他们会修复可能出现的所有错误)” – Bob Baldwin

“Skim to get high level picture, leave feedback if I don’t understand or have changes to suggest. If the high level seems good, read at a deeper level to check for best practice/nit issues, if there are enough request changes, otherwise accept with a few notes.” — Ari Chivukula

“跳过以获得高水平的图片，如果我不理解或有任何更改建议，请留下反馈。 如果较高的级别看起来不错，请更深入地阅读以检查最佳实践/优先级问题，是否有足够的请求更改，否则接受一些注释。 —阿里·奇武库拉(Ari Chivukula)

A common trend across most of the responses for “What’s your strategy for reviewing a diff” talked about understanding the diff from a high level first. After the basic structure of the diff is understood, go into the code style and logical checking.

在大多数答复中，“对差异进行审查的策略是什么”中的一个共同趋势是，首先要从高水平理解差异。 了解差异的基本结构后，进入代码风格和逻辑检查。

REQUEST CHANGES

要求变更

“Use Request Changes frequently — the worst that can happen is they re-request review (encourage the author to, if they think your Request Changes was in error)” — Adam Ernst

“经常使用请求更改-可能发生的最糟糕的情况是他们重新请求审阅(如果他们认为您的请求更改有误，鼓励作者这样做)”-Adam Ernst

“If I can see myself breaking it, ask for unit tests or a refactor so I’m less likely to break it. If it’s too large and too complex and it’s clear no one wants to bother with it, ask them to break it up, or at least give suggestions for good ways to do so in the future” — <anonymous>

“如果我发现自己破坏了它，请进行单元测试或重构，这样我不太可能破坏它。 如果它太大，太复杂，而且显然没有人愿意去打扰，请他们分手，或者至少提出一些建议，以备日后这样做的好方法。”-<匿名>

Requesting changes on diffs for non-standard things can be awkward. However, In the long run, encouraging better coding practices and validation are likely to pay off as engineers learn from their mistakes and improve.

请求对非标准商品的差异进行更改可能很尴尬。 但是，从长远来看，随着工程师从错误中吸取教训并加以改进，鼓励更好的编码实践和验证很可能会获得回报。

ADMIT WHAT YOU DON’T KNOW

承认您不知道的内容

“If I don’t know much about a part of the codebase I won’t BS that part and I’ll admit it straight up.” — Michael Novati

“如果我对代码库的某个部分不太了解，我将不会对此部分进行BS学习，而我会直接承认这一点。” —迈克尔·诺瓦蒂(Michael Novati)

You don’t really add much to a conversation by pretending to know something you don’t. Be up-front about your knowledge, and encourage people to seek engineers more knowledgeable about certain systems.

假装知道自己不了解的内容，实际上并不会增加对话的内容。 提前了解您的知识，并鼓励人们寻找对某些系统更了解的工程师。

4级：组织和奋斗 (Level 4: ORGANIZE & HUSTLE)

TODOS

托多斯

“I’ll block off personal things on my Calendar and make notes to do things later in the day, by adding meetings. If I don’t add a reminder to my calendar I will forget.” — Michael Novati

“我将阻止我日历上的个人事务，并通过添加会议记录来做某事，以便在当天晚些时候进行。 如果我不给日历添加提醒，我会忘记的。” —迈克尔·诺瓦蒂

For the most part, the engineers I interviewed each used different tools to keep track of the tasks they were working on. This combined systems such as paper, tasks, email, calendar, lists, high-level goals, etc. But, many of the engineers had a “hierarchy” for determining what task should be done next as well as triaging systems for organizing the tasks and emails that were heading their way.

在大多数情况下，我采访的工程师都使用不同的工具来跟踪他们正在执行的任务。 这种组合的系统包括纸张，任务，电子邮件，日历，列表，高级目标等。但是，许多工程师具有“层次结构”，用于确定下一步应执行的任务以及用于组织任务的分类系统。以及正在前进的电子邮件。

FAIL FAST, ITERATE

失败，反复

“I try to turn around code fast when possible even if I’m not sure it’s optimal (to get comments) and prefer failing fast trying ideas over thinking through 100%” — Ari Chivukula

“即使不确定不确定(获取评论)是否是最佳选择，我也会尽可能快速地处理代码，并且宁愿快速尝试的想法失败，也不愿通过100％的思考” – Ari Chivukula

“I’m not intimidated by code and I can get in the zone easily and crush through stuff” — Michael Novati

“我不会被代码吓到，我可以轻松进入该区域并摸索东西” – Michael Novati

One thing that will probably hold back a lot of engineers (myself included) is fear of failure. Trying to create the perfect product off the bat can be intimidating and cause us to overthink problems. Getting into a habit of jumping into code without knowing exactly how it will turn out can allow us to iterate much faster and see results.

可能会使很多工程师(包括我本人)受阻的一件事是担心失败。 试图立即创造出完美的产品可能会令人生畏，并导致我们过度思考问题。 养成在不确切了解结果的情况下跳入代码的习惯，可以使我们更快地进行迭代并查看结果。

WORK/LIFE BALANCE

工作与生活的平衡

“It helps to have a <significant other> who spends more time at work than you do. smile emoticon otherwise, I do sprints where I work really hard and then take it easy. sometimes like 2 months hard and 1 month easy. that’s more effective IMO than 3 months at the same pace (but doesn’t work for everyone) b/c work is non-linear” — <anonymous>

“有一个<重要的>人在工作上花费的时间比您多，这会有所帮助。 否则，微笑表情符号，我会在我非常努力的地方冲刺，然后放轻松。 有时候像2个月艰苦而1个月轻松。 这比同等速度的3个月IMO更为有效(但并非对每个人都有效)b / c工作是非线性的” – <anonymous>

“the “thinking about a problem in the shower” trope has some truth to it” — Adam Ernst

““思考淋浴中的问题”字眼有一定道理” —亚当·恩斯特

Let’s face it, these engineers work really hard. They spend large amounts of time working to get their vast amounts of code out. Though I didn’t ask a specific question about work-life balance, bits and pieces of their work life slipped through, and, though many of the engineers seemed to be wholly focused on work, I was equally surprised by the engineers who drew strict work/life lines and were able to keep up a similar pace to the “all in” engineers. A big takeaway I found was that you can be one of the most productive and have a good work/life balance if you’re willing to optimize your workflow.

面对现实，这些工程师非常努力。 他们花费大量时间来获取大量代码。 尽管我没有提出关于工作与生活平衡的具体问题，但他们的工作生活却零散地溜走了，尽管许多工程师似乎完全专注于工作，但同样让我感到吃惊的是，工程师们对工作与生活保持了平衡。工作/生活路线，并能够与“全能”工程师保持相似的步伐。 我发现一个很大的收获是，如果您愿意优化工作流程，那么您可以成为生产力最高的人， 并拥有良好的工作/生活平衡。

分手思想 (PARTING THOUGHTS)

“Treat other people the way you want to be treated doesn’t get you far past kindergarten. You need to be the kind of engineer other people want to work with, and most of that is learned through feedback. Ask early and often, people who feel heard are people who feel valued” — Ari Chivukula

“以其他方式对待您想要得到的对待不会使您离幼儿园很远。 您需要成为其他人想要与之合作的工程师，并且其中大多数都是通过反馈来学习的。 经常提早问，那些被听到的人就是那些被重视的人” – Ari Chivukula

After going through these interviews, I’ve seen my development process evolve bit by bit (Teammates have to try really hard to get my attention now that I have noise canceling headphones). Splitting diffs, requesting reviews, and TODO lists existed in my development process before, but now I am more robust in how I go about using these tools. I can honestly say I am a way more efficient engineer after implementing these practices.

经过这些采访之后，我看到了我的开发过程正在逐步发展(由于我拥有降噪耳机，因此Teammates必须非常努力地吸引我的注意力)。 在我的开发过程中曾经存在过区分差异，请求审阅和待办事项列表，但是现在我在使用这些工具的方式上更加强大。 老实说，在实施这些实践后，我是一名效率更高的工程师。

I’d like to give a huge thanks to all the Facebook engineers I interviewed, Michael, Adam, Ari, Bob, and all the others who wished to remain anonymous. And I’d like to give a huge thanks to Kent for pushing me to write this article, and to Aimee and Andrew for helping me edit it.

我要非常感谢我采访的所有Facebook工程师，Michael，Adam，Ari，Bob以及所有希望保持匿名的其他人。 在此，我要非常感谢Kent促使我撰写本文，并感谢Aimee和Andrew帮助我进行了编辑。

指数 (INDEX)

1. Diff: When a Facebook engineer talks about a diff they are referring to a differential revision created using the open-source tool phabricator. These revisions are code changes that have been put into phabricator for other engineers to review. Engineers can comment, request changes, and accept the code change before it is shipped into production and starts affecting real users. This is done as a validation step for every piece of code written at Facebook (and many other companies) and guarantees constant collaboration and feedback between engineers.

   差异 ：当Facebook工程师谈论差异时，他们指的是使用开源工具phabricator创建的差异版本。 这些修订是代码更改，已添加到相位调整器中，供其他工程师进行审核。 工程师可以在代码更改投入生产并开始影响实际用户之前对其进行评论，请求更改并接受代码更改。 这是对Facebook(以及许多其他公司)编写的每段代码的验证步骤，并确保工程师之间的持续协作和反馈。

2. Stacked Diffs: Stacking diffs is a level above regular diff creation. When you stack diffs you are creating a logical dependency between your diffs where the diff at the top of the stack is building on top of the functionality of all the diffs below it. This allows engineers to build out features in small, simple changes that can be viewed as incremental progress to a larger goal.

   堆叠差异：堆叠差异是常规差异创建之上的水平。 当您堆叠差异时，您将在差异之间创建逻辑依赖性，其中堆栈顶部的差异建立在其下方所有差异的功能之上。 这使工程师可以在小的，简单的更改中构建功能，这些更改可以看作是实现更大目标的增量进度。

First seen in my Facebook note

首次在我的Facebook笔记中看到

翻译自: https://www.freecodecamp.org/news/how-to-level-up-as-a-developer-87344584777c/

测试开发人员与开发人员