您即将阅读一篇包含大量建议的博客文章。向前人学习有助于成功，但我们经常忘记一个重要的警告。几乎所有的建议都是上下文相关的，但很少提供任何上下文。

说明：本文摘自《20 Things I’ve Learned in my 20 Years as a Software Engineer》 @JustinEtheredge

建议清单：

I still don’t know very much 我还不太了解xxx

“How can you not know what BGP is?” “You’ve never heard of Rust?” Most of us have heard these kinds of statements, probably too often. The reason many of us love software is because we are lifelong learners, and in software no matter which direction you look, there are wide vistas of knowledge going off in every direction and expanding by the day. This means that you can spend decades in your career, and still have a huge knowledge gap compared to someone who has also spent decades in a seemingly similar role. The sooner you realize this, the sooner you can start to shed your imposter syndrome and instead delight in learning from and teaching others.

“你怎么会不知道BGP是什么？” “你从来没有听说过 Rust？”我们大多数人都听过这类言论，而且可能听得太频繁了。我们中的许多人热爱软件的原因是因为我们是终身学习者，在软件中，无论你朝哪个方向看，知识的广阔视野都在向各个方向延伸，并与日俱增。这意味着你可以在自己的职业生涯中度过数十年，但与在看似相似的职位上度过数十年的人相比，仍然存在巨大的知识差距。你越早意识到这一点，你就能越早开始摆脱冒名顶替综合症，转而乐于向他人学习和教导他人。

The hardest part of software is building the right thing 软件最难的部分是构建正确的东西

I know this is cliche at this point, but the reason most software engineers don’t believe it is because they think it devalues their work. Personally I think that is nonsense. Instead it highlights the complexity and irrationality of the environments in which we have to work, which compounds our challenges. You can design the most technically impressive thing in the world, and then have nobody want to use it. Happens all the time. Designing software is mostly a listening activity, and we often have to be part software engineer, part psychic, and part anthropologist. Investing in this design process, whether through dedicated UX team members or by simply educating yourself, will deliver enormous dividends. Because how do you really calculate the cost of building the wrong software? It amounts to a lot more than just lost engineering time.

我知道这在这一点上是陈词滥调，但大多数软件工程师不相信这一点的原因是他们认为这贬低了他们的工作价值。我个人认为这是无稽之谈。相反，它凸显了我们工作环境的复杂性和非理性，这加剧了我们的挑战。你可以设计出世界上技术上最令人印象深刻的东西，然后却没有人愿意使用它。一直在发生。设计软件主要是一种倾听活动，我们通常必须既是软件工程师，又是通灵者，又是人类学家。投资这个设计过程，无论是通过专门的用户体验团队成员还是仅仅通过自我教育，都将带来巨大的回报。因为如何真正计算构建错误软件的成本？这不仅仅是损失了工程时间。

The best software engineers think like designers 最好的软件工程师像设计师一样思考

Great software engineers think deeply about the user experience of their code. They might not think about it in those terms, but whether it is an external API, programmatic API, user interface, protocol, or any other interface; great engineers consider who will be using it, why it will be used, how it will be used, and what is important to those users. Keeping the user’s needs in mind is really the heart of good user experience.

优秀的软件工程师会深入思考其代码的用户体验。他们可能不会用这些术语来思考它，而是考虑它是否是外部 API、编程 API、用户界面、协议或任何其他接口；伟大的工程师会考虑谁将使用它、为什么使用它、如何使用它以及对这些用户来说重要的是什么。牢记用户的需求确实是良好用户体验的核心。

The best code is no code, or code you don’t have to maintain 最好的代码是没有代码，或者不需要维护的代码

All I have to say is “coders gonna code.” You ask someone in any profession how to solve a problem, and they are going to err on the side of what they are good at. It is just human nature. Most software engineers are always going to err on the side of writing code, especially when a non-technical solution isn’t obvious. The same goes for code you don’t have to maintain. Engineering teams are apt to want to reinvent the wheel, when lots of wheels already exist. This is a balancing act, there are lots of reasons to grow your own, but beware of toxic “Not Invented Here” syndrome.

我想说的就是“程序员会编码”。你问任何职业的人如何解决问题，他们都会在他们擅长的方面犯错误。这只是人性。大多数软件工程师在编写代码时总是会犯错误，尤其是当非技术解决方案不明显时。对于不需要维护的代码也是如此。当很多轮子已经存在时，工程团队很容易想要重新发明轮子。这是一个平衡的行为，有很多理由来发展你自己的，但要小心有毒的“不是这里发明的”综合症。

Software is a means to an end 软件是达到目的的手段

The primary job of any software engineer is delivering value. Very few software developers understand this, even fewer internalize it. Truly internalizing this leads to a different way of solving problems, and a different way of viewing your tools. If you really believe that software is subservient to the outcome, you’ll be ready to really find “the right tool for the job” which might not be software at all.

任何软件工程师的首要工作就是交付价值。很少有软件开发人员理解这一点，更不用说将其内化。真正内化这一点会导致解决问题的不同方式，以及查看工具的不同方式。如果你真的相信软件服从于结果，你就准备好真正找到“适合工作的工具”，而这可能根本不是软件。

Sometimes you have to stop sharpening the saw, and just start cutting shit 有时你必须停止磨锯子，并着手解决问题

Some people tend to jump into problems and just start writing code. Other people tend to want to research and research and get caught in analysis paralysis. In those cases, set a deadline for yourself and just start exploring solutions. You’ll quickly learn more as you start solving the problem, and that will lead you to iterate into a better solution.

有些人倾向于直接陷入问题并开始编写代码。其他人往往想要研究又研究，但却陷入分析瘫痪。在这种情况下，请为自己设定一个截止日期，然后开始探索解决方案。当你开始解决问题时，你会很快学到更多东西，这将引导你迭代出更好的解决方案。

If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system 如果你不能很好地把握软件生态的可能性，你就无法设计出一个好的系统

This is something I struggle with a lot as my responsibilities take me further and further from the day to day of software engineering. Keeping up with the developer ecosystem is a huge amount of work, but it is critical to understand what is possible. If you don’t understand what is possible and what is available in a given ecosystem then you’ll find it impossible to design a reasonable solution to all but the most simple of problems. To summarize, be wary of people designing systems who haven’t written any code in a long time.

这是我经常遇到的问题，因为我的责任让我在软件工程的日常工作中越来越远。跟上开发者生态系统的步伐是一项艰巨的工作，但了解什么是可能的至关重要。如果您不了解给定生态系统中什么是可能的以及什么是可用的，那么您将发现不可能为除了最简单的问题之外的所有问题设计合理的解决方案。总而言之，要警惕那些很长时间没有编写任何代码的系统设计者。

Every system eventually sucks, get over it 每个系统最终都会很糟糕，克服它

Bjarne Stroustrup has a quote that goes “There are only two kinds of languages: the ones people complain about and the ones nobody uses”. This can be extended to large systems as well. There is no “right” architecture, you’ll never pay down all of your technical debt, you’ll never design the perfect interface, your tests will always be too slow. This isn’t an excuse to never make things better, but instead a way to give you perspective. Worry less about elegance and perfection; instead strive for continuous improvement and creating a livable system that your team enjoys working in and sustainably delivers value.

Bjarne Stroustrup 有句话说：“只有两种语言：人们抱怨的语言和没人使用的语言”。这也可以扩展到大型系统。没有“正确”的架构，你永远无法偿还所有的技术债务，你永远无法设计出完美的界面，你的测试总是太慢。这并不是永远让事情变得更好的借口，而是一种为你提供视角的方法。少担心优雅和完美；相反，努力持续改进并创建一个让您的团队喜欢工作并可持续地创造价值的宜居系统。

Nobody asks “why” enough 没有人一直追问“为什么”

Take any opportunity to question assumptions and approaches that are “the way things have always been done”. Have a new team member coming on board? Pay attention to where they get confused and what questions they ask. Have a new feature request that doesn’t make sense? Make sure you understand the goal and what is driving the desire for this functionality. If you don’t get a clear answer, keep asking why until you understand.

抓住一切机会质疑“一直以来做事的方式”的假设和方法。有新的团队成员加入吗？注意他们困惑的地方以及他们提出的问题。有一个没有意义的新功能请求吗？确保您了解目标以及推动此功能需求的因素。如果你没有得到明确的答案，请继续问为什么，直到你明白为止。

We should be far more focused on avoiding 0.1x programmers than finding 10x programmers 我们应该更关注避免 0.1x 程序员而不是寻找 10x 程序员

The 10x programmer is a silly myth. The idea that someone can produce in 1 day what another competent, hard working, similarly experienced programmer can produce in 2 weeks is silly. I’ve seen programmers that sling 10x the amount of code, and then you have to fix it 10x the amount of times. The only way someone can be a 10x programmer is if you compare them to 0.1x programmers. Someone who wastes time, doesn’t ask for feedback, doesn’t test their code, doesn’t consider edge cases, etc… We should be far more concerned with keeping 0.1x programmers off our teams than finding the mythical 10x programmer.

10 倍程序员是一个愚蠢的神话。认为某人可以在一天内完成另一位有能力、勤奋、经验相似的程序员在两周内可以完成的工作的想法是愚蠢的。我见过程序员编写了 10 倍的代码，然后你必须修复它 10 倍的次数。某人成为 10 倍程序员的唯一方法就是将他们与 0.1 倍程序员进行比较。有人浪费时间、不寻求反馈、不测试代码、不考虑边缘情况等等……我们应该更关心如何让 0.1 倍程序员离开我们的团队，而不是寻找神话般的 10 倍程序员。

One of the biggest differences between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be 高级工程师和初级工程师之间最大的区别之一是他们对事情应该如何发展形成了自己的看法

Nothing worries me more than a senior engineer that has no opinion of their tools or how to approach building software. I’d rather someone give me opinions that I violently disagree with than for them to have no opinions at all. If you are using your tools, and you don’t love or hate them in a myriad of ways, you need to experience more. You need to explore other languages, libraries, and paradigms. There are few ways of leveling up your skills faster than actively seeking out how others accomplish tasks with different tools and techniques than you do.

没有什么比高级工程师对他们的工具或如何构建软件没有意见更让我担心的了。我宁愿有人给我我强烈不同意的意见，也不愿他们完全没有意见。如果你正在使用你的工具，并且你在很多方面不喜欢或讨厌它们，那么你需要体验更多。您需要探索其他语言、库和范例。积极探索其他人如何使用与您不同的工具和技术来完成任务，没有什么比这更快地提高您的技能了。

People don’t really want innovation 人们并不真正想要创新

People talk about innovation a whole lot, but what they are usually looking for is cheap wins and novelty. If you truly innovate, and change the way that people have to do things, expect mostly negative feedback. If you believe in what you’re doing, and know it will really improve things, then brace yourself for a long battle.

人们经常谈论创新，但他们通常寻找的是廉价的胜利和新奇的事物。如果你真正进行创新，并改变人们做事的方式，预计大多数都是负面反馈。如果你相信自己正在做的事情，并且知道它确实会改善事情，那么就做好长期战斗的准备。

Your data is the most important part of your system 数据是系统中最重要的部分

I’ve seen a lot of systems where hope was the primary mechanism of data integrity. In systems like this, anything that happens off the golden path creates partial or dirty data. Dealing with this data in the future can become a nightmare. Just remember, your data will likely long outlive your codebase. Spend energy keeping it orderly and clean, it’ll pay off well in the long run.

我见过很多系统，希望是数据完整性的主要机制。在这样的系统中，黄金路径之外发生的任何事情都会产生部分数据或脏数据。将来处理这些数据可能会成为一场噩梦。请记住，您的数据可能会比您的代码库更长久。花费精力保持秩序和清洁，从长远来看会有很好的回报。

Look for technological sharks 寻找技术鲨鱼

Old technologies that have stuck around are sharks, not dinosaurs. They solve problems so well that they have survived the rapid changes that occur constantly in the technology world. Don’t bet against these technologies, and replace them only if you have a very good reason. These tools won’t be flashy, and they won’t be exciting, but they will get the job done without a lot of sleepless nights.

一直存在的旧技术是鲨鱼，而不是恐龙。他们能够很好地解决问题，从而在技术世界不断发生的快速变化中幸存下来。不要对这些技术下注，只有在有充分理由的情况下才更换它们。这些工具不会很华丽，也不会令人兴奋，但它们会完成工作，而无需很多不眠之夜。

Don’t mistake humility for ignorance 不要把谦逊误认为是无知

There are a lot of software engineers out there who won’t express opinions unless asked. Never assume that just because someone isn’t throwing their opinions in your face that they don’t have anything to add. Sometimes the noisiest people are the ones we want to listen to the least. Talk to the people around you, seek their feedback and advice. You’ll be glad you did.

有很多软件工程师除非被要求，否则不会表达意见。永远不要仅仅因为某人没有当着你的面提出自己的观点，就认为他们没有什么可补充的。有时候，最吵闹的人是我们最不想听的人。与周围的人交谈，寻求他们的反馈和建议。你会很高兴你这么做了。

Software engineers should write regularly 软件工程师应该定期写作

Software engineers should regularly blog, journal, write documentation and in general do anything that requires them to keep their written communication skills sharp. Writing helps you think about your problems, and helps you communicate those more effectively with your team and your future self. Good written communication is one of the most important skills for any software engineer to master.

软件工程师应该定期写博客、写日记、写文档，以及做任何需要他们保持敏锐的书面沟通技巧的事情。写作可以帮助您思考问题，并帮助您与团队和未来的自己更有效地沟通这些问题。良好的书面沟通是任何软件工程师需要掌握的最重要的技能之一。

Keep your processes as lean as possible 尽可能保持流程精简

Everyone wants to be agile these days, but being “agile” is about building things in small chunks, learning, and then iterating. If someone is trying to shoehorn much more into it than that, then they’re probably selling something. It isn’t to say that people don’t need accountability or help to work this way, but how many times have you heard someone from your favorite tech company or large open source project brag about how great their Scrum process is? Stay lean on process until you know you need more. Trust your team and they will deliver.

如今每个人都希望变得敏捷，但“敏捷”就是小块地构建事物、学习，然后迭代。如果有人试图强行塞入更多东西，那么他们可能正在出售一些东西。这并不是说人们不需要问责制或帮助来以这种方式工作，但是您有多少次听到来自您最喜欢的科技公司或大型开源项目的人吹嘘他们的 Scrum 流程有多么出色？保持精益流程，直到您知道您需要更多。相信您的团队，他们会交付。

Software engineers, like all humans, need to feel ownership 软件工程师和所有人一样，需要有主人翁感

If you divorce someone from the output of their work, they will care less about their work. I see this almost as a tautology. This is the primary reason why cross-functional teams work so well, and why DevOps has become so popular. It isn’t all about handoffs and inefficiencies, it is about owning the whole process from start to finish, and being directly responsible for delivering value. Give a group of passionate people complete ownership over designing, building, and delivering a piece of software (or anything really) and amazing things will happen.

如果你将某人与他们的工作成果分开，他们就会不太关心他们的工作。我认为这几乎是同义反复。这是跨职能团队运作良好以及 DevOps 如此受欢迎的主要原因。这并不全是交接和低效率，而是掌控从开始到结束的整个流程，并直接负责交付价值。让一群充满热情的人完全掌控设计、构建和交付一个软件（或任何真正的东西），神奇的事情就会发生。

Interviews are almost worthless for telling how good of a team member someone will be 面试对于判断一个人的团队成员有多优秀几乎毫无价值

Interviews are far better spent trying to understand who someone is, and how interested they are in a given field of expertise. Trying to suss out how good of a team member they will be is a fruitless endeavor. And believe me, how smart or knowledgable someone is is also not a good indicator that they will be a great team member. No one is going to tell you in an interview that they are going to be unreliable, abusive, pompous, or never show up to meetings on time. People might claim they have “signals” for these things… “if they ask about time off in the first interview then they are never going to be there!” But these are all bullshit. If you’re using signals like these you’re just guessing and turning away good candidates.

最好通过面试来了解某人是谁，以及他们对特定专业领域的兴趣程度。试图弄清楚他们将成为多么优秀的团队成员是徒劳的。相信我，一个人有多聪明或知识渊博也并不能很好地表明他们会成为一名优秀的团队成员。没有人会在面试中告诉你他们会变得不可靠、辱骂、浮夸或从不准时出席会议。人们可能会声称他们对这些事情有“信号”……“如果他们在第一次面试中询问请假，那么他们永远不会去那里！”但这些都是废话。如果你使用这样的信号，你只是在猜测并拒绝优秀的候选人。

Always strive to build a smaller system 始终努力构建更小的系统

There are a lot of forces that will push you to build the bigger system up-front. Budget allocation, the inability to decide which features should be cut, the desire to deliver the “best version” of a system. All of these things push us very forcefully towards building too much. You should fight this. You learn so much as you’re building a system that you will end up iterating into a much better system than you ever could have designed in the first place. This is surprisingly a hard sell to most people.

有很多力量会推动您预先构建更大的系统。预算分配、无法决定应该削减哪些功能、渴望提供系统的“最佳版本”。所有这些事情都非常有力地推动我们建造过多的东西。你应该对抗这个。当你构建一个系统时，你会学到很多东西，最终你会迭代出一个比你最初设计的更好的系统。令人惊讶的是，这对大多数人来说是很难推销的。