软件工程师工作经历

In 2018, I started working at Bloomberg. Things have changed a lot since then. I’m not the most junior member in the company anymore and I’ve mentored quite a few new engineers, which has been amazing. It helped me observe how others differ from me, absorb their best practices, and figure out things I’ve unconsciously been doing pretty well.

2018年，我开始在彭博 工作。 从那时起，情况发生了很大变化。 我不再是公司中最初级的成员，并且我已经指导了很多新工程师，这真是太了不起了。 它帮助我观察其他人与我的不同之处，吸收他们的最佳实践，并弄清自己在不知不觉中一直做得很好的事情。

Yearly work reviews are a good way to condense these lessons I’ve learned. They’re valuable for pattern matching, too. Only when I zoom out do certain patterns become visible. I can then start tracking these patterns consciously. The broad theme for this year is zooming out and challenging the boundaries. It’s also about zooming in and adding nuance to the sections from last year. It’s more fun if you’ve read last year’s review first: You can then differentiate my growth.1

每年的工作回顾是总结这些经验教训的好方法。 它们对于模式匹配也很有价值。 仅当我缩小时，某些图案才可见。 然后，我可以开始有意识地跟踪这些模式。 今年的主要主题是缩小范围并挑战边界。 这也是关于放大和添加细微差别的部分。 如果您先阅读了去年的评论，那就会更加有趣：然后您就可以区分我的成长了。1

It all began with a question: How do I grow further/p>

一切都始于一个问题：我如何进一步发展

使用不同的抽象梯子进行增长 (Growing Using Different Ladders of Abstraction)

Entering my second year, I had all the basics in place. I had picked all the low hanging fruit, and my rate of growth slowed down. Not good. The big question on my mind was “How do I grow further

进入第二年，我掌握了所有基础知识。 我已经摘下了所有悬而未决的水果，我的成长速度放慢了。 不好。 我脑海中最大的问题是“我如何进一步成长

There was only so much I could do to improve my coding skills. Most blogs espousing techniques to write cleaner code, repeating yourself, not repeating yourself, etc. are micro-optimizations. Almost none of them would make me instantly impactful.2

我只能做很多事情来提高自己的编码技能。 大多数博客拥护写更清晰的代码，重复自己，不重复自己等的技术，都是微优化。 几乎没有一个能让我立即具有影响力。2

However, I did figure out something insightful. I’m working inside the software development lifecycle, but this lifecycle is part of a bigger lifecycle: the product and infrastructure development lifecycle. I decided to go broader instead of deeper. Surprisingly, the breadth provided more depth to what I knew.

但是，我确实发现了一些有见地的东西。 我正在研究软件开发生命周期，但是这个生命周期是更大生命周期的一部分：产品和基础架构开发生命周期。 我决定更广泛而不是更深入。 令人惊讶的是，广度使我所知道的更加深入。

I zoomed out in three broad directions: learning what people around me are doing, learning good habits of mind, and acquiring new tools for thought.

我向三个主要方向进行了扩展：学习周围人在做什么，学习良好的心智习惯以及获取新的思考工具。

了解我周围的人在做什么 (Learning What People Around Me Are Doing)

Since we’re not in a closed system, it makes sense to better understand the job of the product managers, the salespeople, and the analysts. In the end it’s a business making money through products. The goal isn’t to write code, it’s to be a profitable business.3

由于我们不在封闭系统中，因此有必要更好地了解产品经理，销售人员和分析师的工作。 最终，这是通过产品赚钱的业务。 目标不是编写代码，而是要盈利。3

Most big companies aren’t doing just one thing, which means there are different paths to making money in the same company. Everyone is on at least one path, if they weren’t, they wouldn’t be here.Tracking these paths, and the path I’m on was pretty valuable. It helped me see how I matter, and what levers I can pull to become more effective. Sometimes, it’s about making the sales jobs easier, so they can make more sales. Other times, it’s about building a new feature for clients. And some other times, it’s about improving a feature that keeps breaking.

大多数大公司不只是做一件事，这意味着在同一家公司中有不同的赚钱途径。 每个人都至少在一条道路上，如果没有，他们就不会在这里。踪这些道路以及我所走的道路非常有价值。 它帮助我了解自己的重要性，以及可以提高效率的方法。 有时，这是为了简化销售工作，以便他们可以增加销售量。 其他时候，这是关于为客户构建新功能。 在其他时候，这是关于改进一项不断突破的功能。

Product managers are the best source for this. They know how the business makes money, who are the clients, and what do clients need. Over the year, I set up quite a few meetings with everyone on my path. A second benefit this gave me was the context of other’s jobs. It helped me communicate better. Framing things in the right way is powerful.

产品经理是最好的选择。 他们知道企业如何赚钱，谁是客户以及客户需要什么。 在过去的一年中，我与沿途的每个人都召开了很多会议。 这给我带来的第二个好处是他人工作的背景。 它帮助我更好地沟通。 以正确的方式构架是强大的。

For example, one conversation helped me appreciate why Sarah in Sales wants a bulk update tool. Some companies have lots of employees, and updating them one by one is a pain. The code I write would literally ease Sarah’s pain.

例如，一次对话帮助我理解了为什么Sales中的Sarah想要批量更新工具。 一些公司有很多员工，而一个接一个地更新他们是一个痛苦的过程。 我写的代码从字面上减轻了莎拉的痛苦。

学习良好的心智习惯 (Learning Good Habits of Mind)

Software engineering entails thinking well and making the right decisions. Programming is implementing those decisions. A habit of mind is something your brain does regularly. This could be thinking of X whenever you see Y happen, or applying thinking tool X to problem Y. In short, habits of mind facilitate better thinking. I suspected if I learn the general skill, I should be able to apply it better to software engineering.

软件工程需要认真思考并做出正确的决策。 编程正在执行这些决定。 习惯是大脑定期做的事情。 每当您看到Y发生时，这可能就是在思考X，或者将思考工具X应用于问题Y。简而言之，思维习惯有助于更好的思考。 我怀疑如果我学习了一般技能，我应该能够将其更好地应用于软件工程。

好好思考 (Thinking Well)

Software engineering is an excellent field to practice thinking well in. The feedback loops are shorter, and gauging correctness doesn’t take too long. I dove into cognitive science studies. It’s a permanent skill that’s worth exploring, a force multiplier for whatever I end up doing, and pays dividends throughout my life. One output was a framework for critical thinking. It’s compounding, and compounding is powerful.

软件工程是一个很好地进行思考的极好的领域。反馈循环更短，并且度量的正确性不会花费太长时间。 我从事认知科学研究。 这是一项值得探索的永久技能，是我最终所做的事的力量乘数，并终生付出。 一种输出是批判性思维的框架 。 这很复杂，而且强大。

There’s lots of good things that came out of this, which I’ll talk about in a bit. They deserve their own section.

由此产生了很多美好的东西，我将在稍后讨论。 他们应有自己的职责。

提高日常效率的策略 (Strategies for Making the Day-to-Day More Effective)

The other side of the coin is habits that allow you to think well. It starts with noticing little irritations during the day, inefficiencies in meetings, and then figuring out strategies to avoid them. These strategic improvements are underrated.

硬币的另一面是让您好好思考的习惯。 首先要注意白天的烦恼，会议效率低下，然后找出避免这种烦恼的策略。 这些战略改进被低估了。

You decide what to do, and then let it run on automatic, freeing up the brain to think of more fun stuff. Of course, that’s what a habit is, too. Some good habits I’ve noticed:

您可以决定要做什么，然后让它自动运行，使大脑有更多的精力去思考更多有趣的事情。 当然，这也是一种习惯。 我注意到一些良好的习惯：

• Never leave a meeting without making the decision / having a next action

  决不做决定/不采取下一步行动就离开会议

• Decide who is going to get it done. Things without an owner rarely get done.

  决定谁来完成它。 没有所有者的事情很少能完成。

• Document design decisions made during a project

  记录项目期间做出的设计决策

This pattern became visible during the review, so I’m keen to pay attention and collect more strategies next year. Having an excellent scrum master who holds me accountable has helped me get better at following these strategies.

获得思想和心理模型的新工具 (Acquiring New Tools for Thought & Mental Models)

New tools for thought are related to thinking well, but more specific to software engineering. Tools for thought help me think better about specific engineering problems.

新的思考工具与良好思考相关，但更特定于软件工程。 思考工具可帮助我更好地思考特定的工程问题。

I’ve adopted a just-in-time approach to this. I look for new tools only when I get stuck on something, or when I find out my abstractions and design decisions aren’t working well.

我采用了一种及时的方法。 我只会在遇到问题或发现抽象和设计决策无法正常工作时才寻找新工具。

For example, I was recently struggling with a domain with lots of complex business logic. Edge cases were the norm, and we wanted to design a system that handles this cleanly. That’s when I read about Domain-Driven DesignI could instantly put it to practice and make a big difference. Subsequently, I grasped these concepts better. I acquired a new mental model of how to create enterprise software.

例如，我最近在一个具有许多复杂业务逻辑的领域中苦苦挣扎。 边缘情况是常态，我们希望设计一个可以清晰处理这一问题的系统。 那就是我读到有关域驱动设计的内容。 我可以立即将其付诸实践并发挥很大的作用。 随后，我更好地理解了这些概念。 我获得了有关如何创建企业软件的新思维模型。

The second way I keep learning and acquiring new mental models is via reading what surfaces on Hacker News. They are interesting ideas, some of which I’ve put to practice, but this is a lot less effective than the technique above. The only reason I still do this is to map the territory, it keeps me aware of techniques that exist, so when I face a problem, I know there’s a method that might help.

我不断学习和获得新的心理模型的第二种方法是通过阅读Hacker News上的内容。 它们是有趣的想法，我已经将其中一些实践了，但这远没有上面的技术有效。 我仍然这样做的唯一原因是绘制区域图 ，它使我知道存在的技术，因此当我遇到问题时，我知道有一种方法可能会有所帮助。

The final way I acquire better mental models is by learning new diverse languages. The diversity bit is important. Learning yet another dialect of lisp has a lot less benefit than say, learning C++03, a functional programming language, a dynamic typed language, and a lisp. Today, J seems interesting, and one I might consider learning. It’s a thinking model I haven’t used before.

我获得更好的心理模型的最后方法是学习新的多样的语言。 分集位很重要。 学习lisp的另一种方言比学习C ++ 03，功能编程语言，动态类型化语言和lisp所带来的好处要少得多。 今天， J似乎很有趣 ，我可能会考虑学习。 这是我以前从未使用过的思维模型。

I’ve gotten lots of value from doing this. Each language has its own vocabulary and grammar, and vocabulary is a meta-mental model. It’s a new lens to look at how to do things.

通过这样做，我获得了很多价值。 每种语言都有自己的词汇和语法，词汇是一种元思维模型。 这是研究如何做事的新视角。

When memory management is in your control, you understand how pointers and allocators work. When Python then abstracts this away, you appreciate the complexity reduction. When maps and filters in a functional language show up, you appreciate how Python’s for loops can be improved. Indeed, that’s what list comprehensions are. And then you notice how some things are easier with object-oriented programming. There’s no one magic tool that fits everything well. And then you understand that despite this, you don’t have to switch tools. You can adapt best practices from one into another to solve your problems: like writing functional javascript. It’s the principles that matter more than their expression.

当内存管理处于您的控制范围内时，您将了解指针和分配器的工作方式。 当Python然后将其抽象化时，您会体会到复杂性的降低。 当使用功能性语言显示地图和过滤器时，您会欣赏如何改进Python的for循环。 确实，这就是列表理解。 然后您会注意到，使用面向对象的编程如何使某些事情变得更容易。 没有一种魔术工具可以很好地适应所有情况。 然后您了解到尽管如此，您也不必切换工具。 您可以将最佳实践相互适应，以解决您的问题：例如编写功能强大的javascript。 这些原则比其表达更重要。

Broadly, that’s all I did this year. What follow are insights that sprang forth thanks to zooming out.

概括地说，这就是我今年要做的。 接下来的是由于缩小而产生的见解。

保护你的松弛 (Protect Your Slack)

When I say slack, I don’t mean the company, but the adjective. One thing that gives me high output and productivity gains is to “slow down.” Want to get more doneSlow down. Caveats apply, but here’s what I mean:

当我说懈怠时，我不是指公司，而是形容词。 使我获得高产出和生产率收益的一件事是“放慢脚步”。 想要完成更多工作慢一点。 注意事项适用，但这是我的意思：

I’ve noticed people rush to solve problems. It can be something they’ve done before, or something we have a template for. It feels pretty good to smash through things. I’ve done that before, too. However, there are very specific cases where this makes sense./p>

我注意到人们急于解决问题。 可以是他们以前做过的事情，也可以是我们有模板的事情。 粉碎事物感觉很好。 我之前也做过。 但是，在非常特殊的情况下，这很有意义。

Whenever I’m working on something new, I take the time to learn things about the system I’m working on, and things closely related to it. If it’s too massive, I optimize for learning as much as I can. Every time I revisit the system, I aim to learn more.

每当我在研究新事物时，我都会花时间学习有关正在研究的系统以及与之密切相关的知识。 如果太大，我会尽可能地优化学习。 每次我重新访问该系统时，我都希望了解更多信息。

When there is slack, you get a chance to experiment, learn, and think things through. This means you get enough time to get things done. When there is no slack, deadlines are tight, and all your focus goes into getting shit done. Protecting your slack means not letting deadlines wrap tight around you. Usually, this is as simple (or hard) as communicating./p>

闲暇时 ，您就有机会进行实验，学习和思考。 这意味着您有足够的时间完成工作。 如果没有懈怠，那么最后期限会很紧，您的所有精力都将集中在完成事情上。 保护您的闲暇时间意味着不要让最后期限紧缩。 通常，这就像交流一样简单(或困难)。

Slack might have a negative connotation with “slackers,” but protecting slack is a superpower. It’s a long term investment into building yourself up at the cost of short term efficiency. When I’m quickly dishing out stories, I also have a much harder time fixing bugs. I don’t take the time to create proper mental models of the system, which means my assumptions don’t match the code, and this mismatch is where most bugs lie. I protect my slack, so I can take the time out to prioritize learning things over doing things./p>

松弛可能对“松弛者”具有负面含义，但是保护松弛是一种超级大国。 这是一项长期投资，需要以短期效率为代价来建立自己。 当我Swift讲出故事时，我也很难修复错误。 我没有花时间创建正确的系统思维模型，这意味着我的假设与代码不匹配，而这种不匹配是大多数错误的根源。 我保护自己的休闲时间，因此我可以抽出时间优先学习事物而不是做事。

One of my favorite use cases for slack is experimentation. Sometimes, I’ll find a bug that makes zero sense to me. I notice I’m confused, find an answer on Stack Overflow, and continue. However, this keeps bugging me until I understand the bug. Stack Overflow answered it, but didn’t explain what was wrong in my understanding. To build up my understanding, I need to experiment.

我最喜欢的松弛用例之一是实验。 有时，我会发现一个对我来说意义非零的错误。 我注意到我很困惑，在Stack Overflow上找到答案，然后继续。 但是，这一直困扰着我，直到我了解错误为止。 Stack Overflow回答了这个问题，但是在我的理解中没有解释什么错误。 为了建立我的理解，我需要进行实验。

If I have no slack, I have no time to experiment, which means I have to forget about the bug. When there’s slack, I can run experiments to find out exactly what was missing from my understanding. I love moments like these; when I uncover something new about the system. It makes me a lot more effective the next time around.

如果没有懈怠，就没有时间进行试验，这意味着我不得不忘记该错误。 闲暇时，我可以进行实验以找出我所了解的确切缺失。 我喜欢这样的时刻； 当我发现有关系统的新知识时。 下次我会更有效率。

问问题 (Ask Questions)

We’re generally bad at asking questions. Either we fear they’ll make us look dumb, so we don’t ask them at all, or we ask them with long preambles that’s more about how we’re not dumb, rather than learning more about the thing.

我们通常不敢问问题。 我们要么害怕他们会让我们看起来很愚蠢，所以我们根本不问他们，或者我们以长长的序言问他们，这更多地是关于我们如何不愚蠢，而不是更多地了解事情。

The thing is, you can’t judge a question as dumb until you figure out the answer. The way I get around this is to declare I’ll ask lots of questions. This frees me up to start from the bottom and patch the holes in my understanding. A positive team culture helps, too.

关键是，在弄清楚答案之前，您不能将问题判断为愚蠢的。 我解决这个问题的方法是声明我会问很多问题。 这使我从底部开始解放，并填补了我的理解上的漏洞。 积极的团队文化也有帮助。

For example, here’s my journey learning about packaging software:

例如，这是我学习打包软件的过程：

• Q: What is a package/p>

  问 ：什么是包裹

  Q: What is a packagestrong>A: It’s code wrapped together that can be installed on a system.

  问 ：什么是包裹答 ：它是包装在一起的代码，可以安装在系统上。

• Q: Why do I need packages/p>

  问 ：为什么需要包装

  Q: Why do I need packagesstrong>A: They give a consistent way of getting all the files you need in the right place. Without them, things are easy to mess up. You need to ensure every file is where it’s supposed to be, the system paths are set up, and dependent packages are available.

  问 ：为什么需要包装答 ：它们提供了一致的方式，可以在正确的位置获取所需的所有文件。 没有它们，事情很容易搞砸。 您需要确保每个文件都在预期的位置，设置了系统路径，并且相关包可用。

• Q: How do packages differ from applications I can install on my system/p>

  问 ：软件包与可以在系统上安装的应用程序有何不同

  Q: How do packages differ from applications I can install on my systemstrong>A: It’s a very similar idea. Windows installer is like a package manager that helps install applications. Similarly, and packages are like that you can install on Linux systems, with the help of and package managers, which are like the Windows installers.

  问 ：软件包与可以在系统上安装的应用程序有何不同答 ：这是一个非常相似的想法。 Windows安装程序就像一个程序包管理器，可以帮助安装应用程序。 同样， 和软件包就像一样，您可以在和软件包管理器的帮助下安装在Linux系统上，就像Windows安装程序一样。

• Q: I see. So, this in python somehow converts into a How does that work/p>

  问 ：我知道。 那么，python中的以某种方式转换为吗这是如何运作的

  Q: I see. So, this in python somehow converts into a How does that workstrong>A: We have a that runs for the conversion.

  问 ：我知道。 那么，python中的以某种方式转换为吗这是如何运作的答 ：我们有一个 ，它运行进行转换。

• Q: Oh, how very interesting! How did you figure this out/p>

  问 ：哦，多么有趣！ 您是如何知道的

  Q: Oh, how very interesting! How did you figure this outstrong>A: The file contains instructions on how to create a . I looked at it to figure this out.

  问 ：哦，多么有趣！ 您是如何知道的答 ： 文件包含有关如何创建 。 我看着它来解决这个问题。

Then I know it’s time for me to look at the documentation. I have enough pieces to make sense of the outline. Turns out, this wasn’t as simple as I thought, and it wasn’t a dumb question to ask.

然后，我知道该该看看文档了。 我有足够的作品来理解轮廓。 事实证明，这并不像我想的那么简单，也不是一个愚蠢的问题。

This is a habit of mind I’ve cultivated, and there are some good questions you can always ask. Most of them are context-dependent, but I do have one favourite general question. It’s called playing the meta: How did you find out X/p>

这是我养成的一种心智习惯，您总是可以问一些好的问题。 它们中的大多数是上下文相关的，但是我确实有一个最喜欢的一般性问题。 称为播放元数据：您是如何找到X的

When I ask someone something, and they answer it, the next thing I ask is how did they figure it outThat helps me do it myself the next time around. I did this above, which taught me about the file and how it works.

当我问某人某事并且他们回答时，我接下来要问的是他们是如何发现的这可以帮助我下次自己做。 我是在上面做的，这使我了解了文件及其工作方式。

Another good question is to ask about what confuses you./p>

另一个好问题是问什么使您感到困惑。

注意混乱 (Noticing Confusion)

One fine day, I was working with date-times in Python. These were dates our search engine would index, and we wanted them in UTC. So, I modified our pipeline to convert dates to UTC before ingestion. This required making these dates timezone-aware.

有一天，我在Python中处理日期时间。 这些是我们的搜索引擎可以索引的日期，我们希望在UTC中使用它们。 因此，我修改了管道，以在提取之前将日期转换为UTC。 这要求使这些日期成为时区感知的。

I created a like this:

我创建了这样的 ：

In my tests, this conversion was off by 23 minutes. I didn’t notice it at the time, but seeing this confused me. So, I modified the test offset to -23 minutes, so the tests would pass. It’s a pretty shitty way of thinking. Once I noticed this, I couldn’t un-see it. It sometimes still haunts me that I let this pass. Of course, someone commented on the PR with “this looks wrong,” which jerked me out of my default thinking, to actually figure out what went wrong here.

在我的测试中，此转换截止到23分钟。 当时我没有注意到，但是看到这让我感到困惑。 因此，我将测试偏移量修改为-23分钟，以便测试通过。 这是一种很卑鄙的思维方式。 一旦注意到这一点，便无法取消看到它。 有时候，让我过去的仍然困扰着我。 当然，有人在PR上用“这看起来不对劲”发表评论，这使我脱离了我的默认思维，从而弄清楚了这里出了什么问题。

It’s a pretty epic bug. Pytz has had timezone information throughout the ages. Before 1942, the timezone for Asia/Calcutta was +5:53:20. (Yes, even the city name was different). When pytz timezones are passed into a new date, there’s no reference date to match the timezone to the year. So, it defaults to the first available timezone, which is wrong. The docs mention this, too. The right way is to use , which matches the date to the appropriate timezone, since it’s pytz which is now doing the conversion.

这是一个非常史诗般的错误。 多年来，Pytz拥有时区信息。 1942年之前，亚洲/加图塔的时区为+5：53：20。 (是的，甚至城市名称也不同)。 当pytz时区传递到新日期时，没有参考日期将时区与年份匹配。 因此，它默认为第一个可用时区，这是错误的。 文档也提到了这一点。 正确的方法是使用 ，它将日期与适当的时区匹配，因为现在是pytz正在进行转换。

I wouldn’t have found out about this if that PR review didn’t trigger me. It exposed this scary mode of thinking where I push confusion under the rug. I’ve been wary ever since.

如果PR审查没有触发我，我就不会发现这一点。 它暴露了这种令人恐惧的思维方式，使我在混乱中产生困惑。 从那以后我一直很警惕。

To stop this from happening again, I’ve started training my “noticing muscles.” This is called noticing confusion. Not just when writing code, but with everything, there’s a tendency to explain away confusion, pushing it under the rug. Every time you hear something that sounds weird, and you rush to explain why it must be true, you’re pushing confusion under the rug.

为了阻止这种情况再次发生，我已经开始训练“注意肌肉”。 这称为注意混乱。 不仅在编写代码时，而且在编写所有代码时，都有一种趋势来解释混乱，将混乱推到底层。 每次您听到听起来很怪异的东西，然后急于解释为什么它必须是真实的时，您就会在混乱中推波助澜。

Once you start noticing confusion, you can ask questions about what confuses you. That might have sounded trite in the previous section, but I hope this context helps. The tricky bit is noticing what confused you.

一旦开始注意到混乱，您可以提出有关使您感到困惑的问题。 在上一节中，这听起来有些陈词滥调，但是我希望这种情况有所帮助。 棘手的一点是注意到什么让您感到困惑。

力乘数 (Force Multipliers)

One fine sprint, I accidentally felt the power of the Force.

一次短距离冲刺，我无意中感受到了力量的力量。

“The Force is what gives a Jedi his power. It’s an energy field created by all living things. It surrounds us and penetrates us; it binds the galaxy together.”―Obi-Wan Kenobi, Star Wars

“力量是赋予绝地武士力量的力量。 这是所有生物创造的能量场。 它包围着我们并渗透我们； 它将银河系在一起。”-《星球大战》中的欧比旺·基诺比

I think Obi-Wan Kenobi was onto something, albeit in the wrong domain. It’s something I can leverage in software engineering: becoming a force multiplier.

我认为Obi-Wan Kenobi涉足某些领域，尽管领域不正确。 我可以在软件工程中利用这一点：成为力量倍增器。

That sprint I didn’t get much done myself. I wrote very limited code. Instead, I co-ordinated which changes should go out when (it was a complicated sprint), tested they worked well, did lots of code reviews, made alternate design suggestions, and pair-programmed wherever I could to get things un-stuck. We got everything done, and in this case, zooming out helped make decisions for PRs easier. It was one of our highest velocity sprints.

我自己没有做太多的冲刺。 我写了非常有限的代码。 相反，我协调了哪些更改应该在什么时候出现(这是一个复杂的冲刺)，测试它们是否工作正常，进行大量代码审查，提出替代设计建议以及在可能的情况下进行配对编程，以解决问题。 我们已完成所有工作，在这种情况下，缩小有助于简化PR的决策。 这是我们最高速度的冲刺之一。

“The Force is what gives an engineer his power. It’s an energy field created by all things. It surrounds us and penetrates us; it binds the code together.” — Neil Kakkar

“力量是赋予工程师力量的力量。 这是万物创造的能量场。 它包围着我们并渗透我们； 它将代码绑定在一起。” —尼尔·卡卡(Neil Kakkar)

Alright, I won’t stretch this analogy any further.

好吧，我不再赘述。

Figuring out how to become a force multiplier sounds more valuable to me than 10 developers. In practice, a good force multiplier (or divider) is the team culture. Just as I can create habits of mind to multiply my output, so can the entire team. This happens with the team culture. Retrospectives, reviews, and experiments are everything a team does to mould their culture. The culture is always in flux, as team members come and go, adding their personal touches.

与10个开发人员相比，弄清楚如何成为力量倍增器对我来说更有价值。 在实践中，良好的力量乘数(或除数)是团队文化。 正如我可以养成精神习惯来增加我的产出一样，整个团队也可以。 这与团队文化有关。 回顾，评论和实验是团队塑造其文化的一切。 随着团队成员的来来往往，文化不断变化，增加了他们的个人风格。

A culture that empowers is a force multiplier. I was able to do what I did above because our culture allowed it. Our team culture looks at the team’s output for the sprint, not the individual outputs. This allowed me to optimise for the team getting lots done, instead of focusing on myself. The team shapes the culture, and the culture shapes the team. This idea even extends to cities and nations:

赋予权力的文化是力量的乘数。 因为我们的文化允许，我能够做到以上所做的事情。 我们的团队文化着眼于团队的冲刺输出，而不是个人输出。 这使我可以优化团队的工作效率，而不必专注于自己。 团队塑造文化，而文化塑造团队。 这个想法甚至扩展到城市和国家：

“A society that is under constant military threat will have a culture that celebrates martial virtues, a society that features a cooperative economy will strongly stigmatize laziness, an egalitarian society will treat bossiness as a major personality flaw, an industrial society with highly regimented work schedules will prize punctuality, and so on.” — Why the Culture Wins

“一个经常受到军事威胁的 会将拥有一种庆祝军事美德的文化，一个以合作经济为特色的 会将严重污蔑懒惰，一个平等 会将把领导能力视为主要的人格缺陷，将工作日程安排得井井有条的工业 会会守时，等等。” – 为什么文化获胜