今天看了一篇文章《What I’ve Learned in 45 Years in the Software Industry》，作者作为一个在软件从业 45 年经验总提炼出 6 点：

以下就对原文复制过来，对内容进行简单的翻译提升英语阅读能力。

原文翻译

1. 知识的诅咒

1. Beware of the Curse of Konwledge

When you know something it is almost impossible to imagine what it is like not to know that thing. This is the curse of knowledge, and it is the root of countless misunderstandings and inefficiencies. Smart people who are comfortable with complexity can be especially prone to it!

If you don’t guard against the curse of knowledge it has the potential to obfuscate all forms of communication, including code. The more specialized your work, the greater the risk that you will communicate in ways that are incomprehensible to the uninitiated. Fight the curse of knowledge. Work to understand your audience. Try to imagine what it would be like to learn what you are communicating for the first time.

当你知道某件事情，几乎无法想象不知道这件事情是什么感觉。这是知识的诅咒，也是无数误解和效率低下的根源。精于复杂性的聪明人尤其容易受此困扰！

如果你不防备知识的诅咒，则有可能混淆所有形式的交流，包括代码。你的工作月专业，以新手无法理解的方式进行交流的风险就越大。对抗知识的诅咒。努力了解你的听众。尝试现象一下你第一次学习交流的感觉。

2. 专注与基础知识

2. Focus on the Fundamentals

Technology constantly changes, but some fundamental approaches to software development transcend these trends. Here are six fundamentals that will continue to be relevant for a long time.

  • Teamwork — Great teams build great software. Don’t take teamwork for granted.
  • Trust — Teams move at the speed of trust. Be the kind of dependable person you would want to work with.
  • Communication — Communicate honestly and proactively. Avoid the curse of knowledge.
  • Seek Consensus — Take the time to bring your whole team along. Let discussion and disagreement bring you to the best solution.
  • Automated Testing — Well-tested code allows your team to move fast with confidence.
  • Clean, understandable, and navigable code and design — Think of the next engineer that will take over your code as your customer. Build code that your successor won’t have any trouble reading, maintaining, and updating.

技术不断变化，但是一些软件开发的基本方法超越了这些趋势。一下是 6 个基本原理，在很长一段时间仍将持续存在。

  • 团队合作 — 伟大的团队构建伟大的软件。不要把团队合作当作理所当然。
  • 信任 — 团队以信任的速度前行。成为哪些你想要合作的可靠的人。
  • 沟通 — 诚实主动地沟通。避免知识的诅咒。
  • 寻求共识 — 花时间使你的整个团队团结起来。让讨论和分歧为你带来最佳的解决方案。
  • 自动化测试 — 经过良好测试的代码使你的团队充满信心地快速前进。
  • 干净，可理解且可导航的代码和设计 — 考虑下一位工程师将以你的客户身份来接管你的代码。构建代码，使你的后继者在阅读，维护和更新时不会遇到任何麻烦。

3. 简单

3. Simplicity

Fighting complexity is a never-ending cause. Solutions should be as simple as possible. Assume the next person to maintain your code won’t be as smart as you. When you can use fewer technologies, do so.

“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” Antoine de Saint-Exupery

对抗复杂性是永无止境的。解决方案尽可能简单。假设下一个维护你代码的人不会像你那么聪明。当你可以使用更少的技术时，请这样做。

“设计师知道已经完美实现了，不仅没有什么可添加的，而且还没有什么可减少的。” — 安托万.德.圣艾修伯里

4. 首先去理解别人

4. Seek First to Understand

One of Stephen Covey’s seven habits is, “Seek First To Understand, Then To Be Understood.” This maxim has helped me more than any other advice to become a good listener and teammate. If you want to influence and work effectively with others, you first need to understand them. Actively listen to understand their feelings, ideas, and point of view before you begin trying to make your own thoughts known.

斯蒂芬·科维（Stephen Covey）的七个习惯之一是：“首先去理解别人，然后被理解”。这个格言比起其他任何建议，对我的帮助更重要，成为一个很好的听众和队友。如果你想影响他人并与他人有效合作，则首先要了解他们。在开始表达自己的想法之前，请积极倾听以了解他们的感受，想法和观点。

5. 担心锁定

5. Beware of Lock-In

There will always be the next hot productivity product that will promise to revolutionize how software is built. Computer Assisted Software Engineering (CASE) tools, COTS, Enterprise Resource Planning products like Peoplesoft and SAP and, yes, even Ruby. They claim amazing reductions in cost and time if you buy into their holistic development philosophy. What is not always as obvious is the significant up-front costs or the constraints you may be committing yourself to. Lock-in used to primarily happen with vendors, but now it can happen with frameworks too. Either way, lock-in means significant cost to change. Choose wisely. New is not always better!

始终会有下一个热门生产力产品，该产品将有望彻底改变软件的构建方式。 计算机辅助软件工程（CASE）工具，COTS，企业资源计划产品（例如 Peoplesoft 和 SAP），甚至是 Ruby。 如果您接受他们的整体发展理念，他们就会声称在成本和时间上都有惊人的减少。 并不总是那么明显的是巨大的前期成本或您可能要承担的约束。 锁定过去主要发生在供应商中，但现在也可以发生在框架中。 无论哪种方式，锁定都意味着巨大的变更成本。 做出明智的选择。 新的并不总是更好！

6. 当你不适合这个角色时要诚实和承认

6. Be Honest and Acknowledge When You Don’t Fit the Role

At some point in your career you may find yourself in a role that isn’t a good fit. A bad fit isn’t a character flaw, but it’s a problem you shouldn’t ignore. There may be more than one solution to such a dilemma: you can evolve or the role can evolve. The key is to have the self-knowledge to recognize what is happening and get yourself out of an unhealthy spot. Being unhappy is in no-one’s best interests, and BTI360 recognizes this.

When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path (see the Peter Principle). At EDS, the culture wasn’t like this. People moved in and out of management roles. There was no stigma associated with moving from roles with greater scope, like strategic planner, to roles with more narrow scope, like PM or project-level developer. I was one of the people who took advantage of this flexibility, moving from a role at the top of the technical pyramid back to being a project-level developer. I never looked back.

在职业生涯中的某个时刻，你可能会发现自己职位不合适。不合适不是角色缺陷，但是你不容忽视的问题。解决问题的方法可能不止一种：你可以发展自己，职位也可以演变。关键是要具有自我认识的能力，以是识别正在发生的事情并使自己远离不健康的地方。不开心不符合任何人的最大利益，BTI360 意识到这一点。

当我在通用汽车公司任职时，如果下一步行动不对，你就会失败，那就是管理更多的人或进行更大，更复杂的项目。对于许多人来说这是一条痛苦的职业道路（请参 阅彼得原理）。在EDS，文化不是这样的。人们迁入和移出管理职位。从具有更大范围的角色（如战略计划者）转到具有更窄范围的角色（如PM或项目级开发人员）没有污名化。我是利用这种灵活性的人之一，从技术金字塔顶端的角色转变为项目级开发人员。我从不回头。

自我总结

就对自己最感兴趣的点，总结一下。抓住重点，学习与实践都要学会简化，

知识的诅咒

我个人花了较多的时间去理解，知识的诅咒。

代入更具体的场景来思考知识的诅咒：我在分享知识时，是如何与参与者沟通的。我发现自己只是单纯的表达想法，基本已经忘记了自己不知道这些知识时的感觉，同时还没有意识到这种感觉的重要性。

我自己秉承的思想是分享自己觉得有用的知识，而没有花时间去思考，别人是怎么从你这里获取知识的，是否能很顺畅的获取知识。

改变建议：与别人沟通交流时，时刻记住知识的诅咒，时刻记住自己不知道某个知识时的感觉，沟通时要考虑感觉，发挥人的特性，应为人不是机器。

专注与基础知识

一个行业基础的知识要核心，需要一直不断深入与演变。

  1. 不要把团队合作当作理所当然，就算是再厉害的人都需要学习如何团队合作。
  2. 把自动化测试变成习惯，他是帮助你设计与思考的工具，也是帮你专注与聚焦目标的提醒。
  3. 干净，可理解且可导航的代码和设计是写代码前必须要思考的，把写代码前的设计与思考，变成一种本能，前期刻意刻意的练习。