The abbreviation MVP usually stands for Minimal Viable Product, at least if you’re working in the field of software engineering. But today I want to talk about a different kind of MVP: The Most Valuable Programmer.
缩写 MVP 通常代表最小可行产品，至少如果你在软件工程领域工作的话。但今天我想谈谈另一种 MVP：最有价值的程序员。

Just like the Minimal Viable Product, the Most Valuable Programmer isn’t a concrete concept. Rather, it’s a goal that you strive towards. Also, it’s not about being the most valuable among your peers. Instead, it’s about becoming the best version of yourself. Let me elaborate…
就像最小可行产品（MVP）一样，最有价值的程序员并不是一个具体的概念。相反，它是一个你努力追求的目标。此外，这并不是指在同行中成为最有价值的。相反，它是关于成为最好的自己。让我详细说明……

A Younger Me 一个年轻的我

The other day I was reminded of a conversation I had with a senior developer probably close to 15 years ago. I don’t remember exactly what had gotten into my head, but I had taken it upon myself to micro-optimize a few large PHP files. And this was in the days before we used op-caching, so files were parsed over and over for every request. In order to optimize this I changed all the double-quoted strings to be single-quoted instead, because I had read somewhere that parsing those was 11% faster (or something to that effect) due to the lack of escape sequences.
前几天我想起了大约 15 年前与一位高级开发人员的谈话。我不记得当时是什么让我产生这个想法，但我决定对几个大的 PHP 文件进行微优化。而那时候我们还没有使用 op-cache，所以每个请求都会反复解析文件。为了优化这个，我把所有的双引号字符串都改成了单引号，因为我在某个地方读到解析单引号字符串的速度快 11%（或者类似的说法），因为没有转义序列。

All of this had resulted in a diff that was rather huge and chock-full of tedious changes. And it was this senior developer who had been given the pleasure of reviewing those. He gave me a bit of a scolding for creating such a large diff without prior discussion, which had caused him quite the headache, but he was surprisingly polite about it. It might have been my saving grace that he assumed that I had used an automated formatter on the code, because as he mentioned, nobody in their right mind would spend the time to do such a thing by hand. I agreed.
所有这些导致了一个相当庞大的差异，充满了繁琐的修改。而正是这位高级开发者被赋予了审查这些修改的任务。他对我进行了一些批评，因为我在没有事先讨论的情况下创建了如此庞大的差异，这让他头疼不已，但他对此表现得意外地礼貌。他假设我是使用自动格式化工具处理代码的，这可能是我幸存的恩典，因为正如他所提到的，理智的人是不会花时间手动完成这种事情的。我同意。

But this was also before the days that automated formatters were really commonplace and I had in fact done everything by hand. Oh silly me. I knew very well that it was not in my best interest to admit it at the time, but I had absolutely been stupid enough to have wasted several hours replacing string quotes and making other tedious changes, and in turn had wasted my senior’s time reviewing all of that.
但这也是在自动格式化工具真正普及之前，那时我实际上都是手动完成所有工作。哦，真是傻我。我很清楚当时承认这一点并不符合我的最佳利益，但我绝对愚蠢到浪费了几个小时替换字符串引号和做其他繁琐的更改，反过来又浪费了我上司的时间去审核这些内容。

There might even be some interesting pedagogical aspect to how this lesson was taught. Had he really assumed I was using an auto-formatter, or was he just giving me the benefit of the doubt? Had the lesson stuck precisely because his polite snark had brought shame upon myself? Regardless, the lesson was learned and it helped me take one of those many steps towards becoming a better programmer. A more valuable programmer, if you will.
这节课的教学方式可能还有一些有趣的教育意义。他真的以为我在使用自动格式化工具，还是只是给了我一个怀疑的好处？这节课是否恰恰因为他的礼貌讽刺让我感到羞愧而深刻印象？无论如何，这节课让我学到了东西，帮助我朝着成为更好的程序员迈出了许多步。如果你愿意的话，成为一个更有价值的程序员。

Code versus Value 代码与价值

I have been coding for about 28 years now and I used to take great pride in my code. I would love to draw diagrams of architecture, I had a rigid coding style, followed meticulous interface guidelines, and always had performance on the top of my mind. It’s really no wonder I was proud of my code, because it truly was a thing of beauty. Or so I thought.
我已经编程大约 28 年了，我曾经非常自豪我的代码。我喜欢画架构图，我有一种严格的编码风格，遵循细致的接口指南，并且始终将性能放在首位。我自豪我的代码也就不足为奇，因为它确实是一件美丽的作品。或者我曾这样认为。

I suppose it might have been a luxury that was afforded to me because I started programming even before high school. It allowed me to perfect my art without any pressure from employment, and frankly without any consideration for what really matters. I learned immensely from those early years of programming, but I think my appreciation of the code itself might have been something that held me back for many years after.
我想，这可能是我在上高中之前就开始编程所获得的一种奢侈。它让我得以在没有工作的压力下完善我的艺术，说实话，也没有考虑真正重要的事情。我从早期的编程中学到了很多，但我认为对代码本身的欣赏可能在很多年后让我停滞不前。

If you ever want to become a better programmer, please take this advice: Don’t even try to become the best programmer. Nobody will agree what it means to be the best programmer anyway, so it’s a futile goal. Chasing of wind. Instead, try to become the most valuable programmer. Value is still a rather abstract concept, but at least it can be tied to more concrete goals, such as business value.
如果你想成为一个更好的程序员，请听从这个建议：不要甚至 尝试 成为最好的程序员。 毕竟没有人会同意什么才算是最好的程序员，因此这是一种徒劳的目标。追逐风。相反，试着成为最 有价值 的程序员。价值仍然是一个相当抽象的概念，但至少它可以与更具体的目标相结合，比如商业价值。

I think one of my biggest mistakes was an abstract idea that I believed in for many years: The idea that code is valuable. It’s not. Code is a liability. Once code is written it needs to be reviewed, it needs to be maintained, it may need to be debugged, or rewritten, or even thrown away. But once it’s there, it becomes a time sink. There is no value in code. There is only value in value. That may be a tautology, but it’s so fundamental that it bears repeating: You gain value from solving the problems that your code solves, not from the code itself. The less code you need to solve your problem, the better.
我认为我最大的错误之一是我多年来信奉的一个抽象观念：代码是有价值的。这并不是真的。代码是一种负担。 一旦代码被写出来，就需要进行审查，需要维护，可能还需要调试、重写，甚至被丢弃。但一旦存在，它就成了一个时间黑洞。代码本身没有价值。只有价值才有价值。这可能是一种同义反复，但这是如此基本，以至于值得重申：你从解决代码所解决的问题中获得价值，而不是从代码本身获得。解决问题所需的代码越少，效果就越好。

Consider this: If you’re an engineer you get hired to solve problems. Code may be your weapon of choice, but you don’t get paid to deliver code. You get paid to solve problems. The more problems you solve, the more value you deliver. The more code you deliver, the more of a burden you become…
考虑这一点：如果你是一名工程师，你被雇用来解决问题。代码可能是你首选的工具，但你不是为了交付代码而获得报酬。你是为了解决问题而获得报酬。解决的问题越多，你带来的价值就越大。交付的代码越多，你就越成为负担……

So how do you avoid becoming a burden, and how do you become a valuable programmer that solves many problems? Prioritize. And a good trick to teach yourself to prioritize is a change of mindset: You’re not trying to become a valuable programmer. You are a valuable programmer. You are your own most valuable asset. And what are your scarcest resources? Time and energy. There’s only so many hours in a day, and there’s only so much energy you can muster. Don’t waste it on code formatting, but help out solving the problems the business or your project needs solving most.
所以你如何避免成为负担，并且如何成为一个能解决许多问题的有价值程序员？ 优先考虑。 一个让自己学会优先考虑的好技巧是改变心态：你不是在努力成为一个有价值的程序员。你就是一个有价值的程序员。你自己是最有价值的资产。你最稀缺的资源是什么？时间和精力。一天只有那么多小时，你能集中精力的也只有那么多。不要浪费时间在代码格式化上，而是帮助解决业务或项目中最需要解决的问题。

Code Style 编码风格

I suppose I could have stopped there, but I had all these topics in mind and I’m not going to waste them. And since they’re all topics that most programmers should answer for themselves at some point, we might as well get on with it. We already touched on the subject of code style, so it’s a natural place to start. It’s also a good one to highlight a fundamental contradiction in all of this: Many things are simultaneously important, and they all deserve our attention. Prioritization isn’t merely picking up what’s most important and dropping everything else. It’s about finding a balance that ensures your basic needs are met so that you can spend most of your time focusing on the things that matter most.
我想我本可以就此停止，但我心中有这么多话题，我不打算浪费它们。由于这些话题都是大多数程序员在某个时刻都应该自己回答的，我们不妨继续进行。我们已经谈到了代码风格，因此这是一个很自然的起点。这也是一个很好的机会来强调这一切中的一个基本矛盾：许多事情同时都是重要的，所有这些都值得我们的关注。优先排序不仅仅是选择最重要的事情并放弃其他所有。它关系到找到一种平衡，以确保满足你的基本需求，这样你就可以花大部分时间专注于最重要的事情。

Code style is important for many reasons. We want our code to be readable so our peers can review it and so that we ourselves can still understand it if we have to dive back in later. If everyone in a team follows their own style it tends to distract from what the code is trying to achieve. Code written in a different style from what you’re used to is harder to read because it goes against your expectations. Compare it two people speaking in different dialects: They might both be speaking English, but it becomes harder to focus on the message.
代码风格对许多原因都很重要。我们希望我们的代码可读，这样我们的同事可以审核它，并且如果我们需要稍后再深入了解，我们自己也能理解它。如果团队中的每个人都遵循自己的风格，往往会分散注意力，使人偏离代码试图实现的目标。与你习惯的风格不同的代码更难阅读，因为它违背了你的预期。可以将其与两个人使用不同方言说话进行比较：他们可能都在说英语，但专注于信息变得更困难。

But ultimately, it doesn’t matter so much which dialect you speak, so long as everyone speaks the same. For software, that means agreeing on a code style and staying consistent. There are countless debates to be found on all the minutiae so I’m not going to repeat them here. Make a choice that makes you happy as a team and stick with it.
但最终，您说哪种方言并不那么重要，只要大家说的是同一种。对于软件而言，这意味着要就代码风格达成一致并保持一致。关于所有细节有无数争论，所以我在这里不再重复。做出一个让团队满意的选择并坚持下去。

And make sure you use automation to verify your style. No better way to avoid wasting other people’s time on nitpicking than to let the machines do it.
确保您使用自动化来验证您的风格。没有比让机器去做更好的方法来避免浪费其他人的时间去挑毛病。

Correctness 正确性

Oh, the joys of correctness. Both of utmost importance, for obvious reasons, and a potentially endless timesink, for much more subtle ones. Making sure your code is correct is one of the primary responsibilities of a programmer. Bugs may bite your users, and that’s not good for business. Not to mention that haunting them down is also a nasty time-consuming job that nobody likes to do. Better to avoid them in the first place.
哦，正确性的乐趣。显而易见的原因使其极为重要，而更微妙的原因则可能是无尽的时间浪费。确保你的代码是正确的，是程序员的主要职责之一。错误可能会影响到你的用户，这对商业没有好处。更不用说，追踪这些错误也是一项令人厌烦且耗时的工作，没有人喜欢去做。最好还是在一开始就避免它们。

So our code should always be correct, right? Well, it depends.
所以我们的代码应该始终是正确的，对吗？嗯，这要看情况。

For example, let’s assume you’re writing a script to handle some automation within a repository. Maybe the script wouldn’t be able to handle file names that are not valid UTF8. That’s a bummer, and you can argue that’s not very correct. But if none of the files in your repository would cause it any trouble, it’s certainly correct enough.
例如，假设您正在编写一个脚本来处理存储库中的一些自动化。也许该脚本无法处理不是有效 UTF8 的文件名。这有点让人失望，您可以说这并不完全正确。但如果存储库中的文件都不会给它带来麻烦，这当然是正确的 足够。

That’s a very different story from when you’re building a client application that you distribute to end users and which needs to be able to handle arbitrary paths on their machines. People may use all kinds of locales, and sooner or later you might run into someone with file names that aren’t valid UTF8. The threshold for correctness may differ very much per situation.
这与您构建一个分发给最终用户的客户端应用程序时的情况大相径庭，这个应用程序需要能够处理用户机器上的任意路径。人们可能使用各种语言环境，迟早您可能会遇到文件名不是有效的 UTF8 的情况。每种情况的正确性标准可能会有很大不同。

In general, I think it makes sense to say that the programs we write should produce correct results for all the inputs that may be reasonably expected. Maybe you work in an industry where bugs can create life-threatening situations, in which case you probably have a very strict interpretation of what may be “reasonably expected”. But going beyond the requirements for your problem domain is often a recipe for writing lots of code with little value. Small chance anyone will thank you for it.
一般来说，我认为我们编写的程序应该对所有合理预期的输入产生正确的结果。也许你在一个错误可能导致生命危险的行业工作，在这种情况下，你可能对“合理预期”的定义非常严格。但超出你问题领域的要求往往会导致编写大量价值不高的代码。几乎没有人会感谢你为此所做的努力。

Dryness 干燥

DRY stands for Don’t Repeat Yourself. Rather than copy-pasting code and modifying tiny bits to fit different use cases, it’s usually better to write code that’s a bit more reusable and can be used for both use cases. But this by itself presents another trap that junior programmers may fall into.
DRY 代表“不要重复自己”。与其复制粘贴代码并稍作修改以适应不同的用例，通常更好的做法是编写一些更具可重用性的代码，以便可以同时用于这两种用例。但这本身也会给初级程序员带来另一个陷阱。

Mantras, when taken to any extreme, usually lead to them being applied to situations where they backfire. DRY was invented to ease maintainability. After all, if you later need to update the code, you likely only need to update it in one place instead of hunting down all the places it was copied to and possibly missing some. That’s great and all, but if you keep on extending a single function with various options and branches to make it cover an increasing amount of use cases, that function itself will become a hazard to maintainability.
咒语一旦被推向极端，通常会导致它们在应用于某些情况时适得其反。DRY 的发明是为了提高可维护性。毕竟，如果你之后需要更新代码，你很可能只需在一个地方进行更新，而不必到处寻找其复制的位置，可能还会遗漏一些。这听起来不错，但如果你不断地通过各种选项和分支来扩展一个函数，使其覆盖越来越多的用例，那么这个函数本身将成为可维护性的隐患。

In this specific case, it would probably be better to split a large function into smaller ones. Then you can compose them back into larger, use-case-specific ones, even if that introduces a bit of boilerplate. But in the more general sense, always try to question what the purpose is for a given guideline. Following guidelines isn’t bad, but learn to recognize when it’s a good time to step away from them.
在这个具体情况下，将一个大型函数拆分成多个小函数可能更好。然后，您可以将它们组合回更大的、特定用例的函数，即使这样会引入一些样板代码。但从更一般的意义上讲，总是要质疑给定指南的目的。遵循指南并不坏，但要学会识别何时是脱离它们的好时机。

Performance 表现

Many a programmer’s darling. If nobody appreciates the beauty of your code, at least you can revel in how many allocations you saved. I know — I once replaced hundreds of quotes because supposedly that made parsing them 11% faster on code that was never a bottleneck in the first place.
许多程序员的心头好。如果没有人欣赏你代码的美丽，至少你可以陶醉于你节省了多少分配。我知道——我曾经替换过数百个引号，因为据说那样可以使解析速度提高 11%，而这些代码本来就从未成为瓶颈。

Just realize, that unless you work on the Linux kernel or some special embedded domain, obsessing about performance is wasting your own energy and not delivering any real kind of value.
只需意识到，除非你在 Linux 内核或某些特殊嵌入式领域工作，否则对性能的过度关注就是在浪费自己的精力，并没有带来任何真正的价值。

That’s not to say that performance isn’t important (all of these topics are), but delivering good performance is again very much about picking your battles. Optimize your critical path, if you have any. Batch requests instead of bombarding your API or database with dozens or hundreds of requests. But you don’t add any value trying to optimize things that are fast enough anyway.
这并不是说性能不重要（所有这些主题都是），但提供良好的性能再次很大程度上是关于选择你的战斗。优化你的关键路径，如果你有的话。将请求批量处理，而不是对你的 API 或数据库发起几十或上百个请求的轰炸。但你不会通过尝试优化那些反正已经足够快的东西来增加任何价值。

Adding Value 增加价值

We’ve covered plenty of examples to show that restraint is good. Don’t go overboard and you’re halfway there on your path to becoming a valuable programmer. But where should you focus your energy? How do you add value?
我们已经提供了很多例子来证明克制是好的。不要过火，这样你就迈出了成为一名有价值的程序员的第一步。但是你应该将精力集中在哪里？你如何增加价值？

Here is a random list of ideas that’s by no means authorative…
这里有一个随机的想法列表，这绝不是权威的……

• Try to understand the business’ motivation for functional requirements. Once you understand the problem domain well, you may be able to offer simpler alternatives that take less effort to implement.
  尽量理解企业对功能需求的动机。一旦你充分理解了问题领域，你可能能够提供更简单的替代方案，这些方案实施所需的努力更少。
• Identify unaddressed problem areas. These can be technical such as common causes for bugs, but may as well be process-related or organizational, such as causes for reduced velocity or team morale. Do your research, then propose solutions. Offer yourself as willing to address them. Many times you’ll find you’re not the first to notice them, but it may just take someone willing to put in the effort.
  识别未解决的问题领域。这些问题可以是技术性的，例如导致错误的常见原因，也可以是与流程或组织相关的，例如导致速度下降或团队士气低落的原因。进行研究，然后提出解决方案。表明你愿意解决这些问题。很多时候，你会发现你并不是第一个注意到这些问题的人，但可能只是需要有人愿意付出努力。
• Take your time reviewing your co-worker’s code. When looking at a pull request try to understand what problem they are trying to solve, and whether their solution makes sense in that context. Can you think of anything they might have missed? This is also a great opportunity for knowledge sharing. Don’t just point out what they missed, but if it’s a system you’re familiar with, you may also be able to offer some background as to why things are the way they are. You might even think of ways to improve the maintainability so the next person won’t miss the same thing.
  慢慢审查你同事的代码。在查看拉取请求时，尝试理解他们想要解决的问题，以及他们的解决方案在这个背景下是否合理。你能想到他们可能遗漏的内容吗？这也是一个很好的知识分享机会。不要只是指出他们遗漏的部分，如果这是一个你熟悉的系统，你也可以提供一些背景信息，解释事物为何如此。你甚至可以想到改善可维护性的方法，以便下一个人不会错过同样的事情。
• Communicate. Make sure others know what you’re working on, and have some sense of what others are doing. If others are unaware of your work, they also cannot offer advise. You might think you have a good idea and want to surprise your peers with a working solution. But in an organization, surprises are rarely good, and you don’t want your good idea to interfere with someone else’s.
  沟通。确保他人知道你正在做什么，也了解他人在做什么。如果别人对你的工作不了解，他们也无法提供建议。你可能认为自己有一个好主意，想用一个有效的解决方案给同事一个惊喜。但在组织中，惊喜很少是好的，你不希望自己的好主意干扰到别人。

Don’t Forget Yourself 不要忘记自己

Thanks for making it this far. Hopefully I can offer you one last gem, as for some this might be the most important advice of this piece: Don’t forget yourself.
谢谢你走到这里。希望我能给你最后一个珍贵的建议，因为对一些人来说，这可能是本文中最重要的建议：不要忘记自己。

I mentioned before that time and energy are your scarcest resources. I also mentioned that prioritization is about finding a balance that ensures your basic needs are met. If you run out of time, you might miss a deadline and that’s not good for business. If you run out of energy, you may risk a burnout and that’s not good for anyone, least of all you.
我之前提到过时间和精力是你最稀缺的资源。我还提到过优先顺序是找到一种平衡，以确保满足你的基本需求。如果你的时间用完了，你可能会错过最后期限，这对商业没有好处。如果你的精力用完了，你可能会面临精疲力竭的风险，这对任何人都没有好处，尤其是对你自己。

But before you run out of either, you usually enter a negative spiral that can be recognized. If you have little time, it causes stress that can cause you to burn energy faster. If you’re low on energy, you start to lack motivation and you start taking more time to complete basic tasks. If you notice these signs, it’s a very clear indication your basic needs are not met and you need to speak up. If your manager has to ask why a deadline was missed it’s too late. And if you have to take sick leave to recover from burnout it is definitely too late.
但在你用完任何东西之前，你通常会进入一个可以被识别的负面螺旋。如果你的时间很少，这会造成压力，使你更快地消耗能量。如果你的能量不足，你会开始缺乏动力，并且花更多的时间来完成基本任务。如果你注意到这些迹象，这很明确表示你的基本需求没有得到满足，你需要说出来。如果你的经理不得不询问为什么错过了最后期限，那就太晚了。如果你不得不请病假来恢复精疲力竭，那绝对是太晚了。

There are many ways to prevent this negative spiral or to step out of it once you notice the early signs. First of all, don’t over-promise as it’s a surefire way of taking on more work than you can handle. But also if you notice a particular task is draining your motivation, ask your peers for help, or put it on the backburner instead of forcing yourself to finish it at once. And if you feel a deadline is unreasonable, tell your manager well in advance. Don’t beat yourself up if you cannot make it.
有很多方法可以防止这种负面循环，或者在你注意到早期迹象后走出它。首先，不要过度承诺，因为这无疑会让你承担超出能力范围的工作。但如果你发现某个任务让你失去动力，可以向同事寻求帮助，或者将其暂时搁置，而不是强迫自己一次性完成。如果你觉得截止日期不合理，请提前告诉你的经理。如果你无法完成，不要自责。

Make sure you take time for yourself, your family and/or your hobbies. For me personally, reading up on and experimenting with technology used to be very much of a pastime, though nowadays I often find myself writing fiction^[1] instead. I love spending time with my wife and my son, and I can be perfectly content not thinking about work or programming at all.
确保您花时间照顾自己、家人和/或爱好。对我而言，研究和实验技术曾经是一种消遣，而如今我常常发现自己在写小说^[1]。我喜欢和我的妻子及儿子共度时光，而且我可以完全不去想工作或编程，感到非常满足。

None of that compromises the idea of being a valuable programmer. You need to relax and stay healthy to be happy. Only then can you keep up the energy to keep improving yourself. Happy programmers tend to be more productive^[2].
没有这些并不妨碍成为一名有价值的程序员的理念。你需要放松并保持健康才能快乐。只有这样，你才能保持能量，不断提升自己。快乐的程序员往往更有生产力^[2]。

And after all, you are your own most valuable programmer, so take care of yourself.
毕竟，你是最有价值的程序员，所以好好照顾自己。

Love, Arend. 爱，阿伦德。

[1] Aron Silver — an author of little renown
[1]阿隆·西尔弗 — 一位名声不大的作者

[2] Happiness and the Productivity of Software Engineers
[2]软件工程师的幸福感与生产力