Software Industry

• 开发者学习路线图

• 这篇博文的建议也不错：https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/

• https://www.bti360.com/what-ive-learned-in-45-years-in-the-software-industry/
• 翻译 — Oakfire 2021/01/20 12:33

BTI360 teammate Joel Goldberg recently retired after working in the software industry for over four decades. When he left he shared with our team some of the lessons he learned over his career. With his permission, we reshare his wisdom here.

BTI360 的队友 Joel Goldberg 最近退休了，他在软件业工作了超过四十年。他离开时给我们团队分享了一些课程，是他职业生涯中所学到的。在他的同意下，我们在这里转发分享他的智慧。

Looking back on four decades in the software industry, I’m struck by how much has changed. I started my career with punch cards and I am ending in the era of cloud computing. Despite all this change, many principles that have helped me throughout my career haven’t changed and continue to be relevant. As I step away from the keyboard, I want to share six ideas I’ve learned from my career as a software engineer.

回顾在软件业的四十年，我震惊于它的改变。我的职业生涯开始于打孔卡，并结束于云计算时代。尽管有这些变化，但贯穿我职业生涯对我有帮助的很多原则没有改变，并且会持续生效。由于我要告别键盘了，我想分享作为软件工程师在职业生涯中学到的六个建议。

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.

如果你不防备知识的诅咒，它就有潜在能力去混淆所有的交流，包括代码。你的工作越专业，就越有风险以初学者不理解的方式来沟通。对抗知识的诅咒，努力了解你的听众。尝试想象一下第一次学习交流时的感觉。

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.
• 干净，可理解且可导航的代码和设计 -要考虑之后的工程师会接管你的代码。构建后继者在阅读，维护和更新时不会遇到任何麻烦的代码。

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.

对抗复杂性是永无止境的。解决方案应尽可能简单。假设维护你代码的人不会如你般聪明。当你可以使用更精简的技术时，用它。

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 的七个习惯之一是：“先寻求了解，后被理解。” 这个格言比起其他任何建议的帮助更大，让我成为了一个好听众和好队友。如果你想影响他人并有效地合作，则首先需要了解他们。在开始尝试表达自己的想法之前，积极倾听以了解他们的感受，想法和观点。

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。它们声称如果接受它们的整体发展理念，会在成本和时间上都有惊人的减少。而巨大的前期成本或可能要承担的约束，并不总是那么明显。技术封闭过去主要发生在提供商中，但现在也可以发生在框架中。无论哪种方式，封闭都意味着巨大的变更成本。做出明智的选择。新的并不总是更好！

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.

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

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.

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

Even before I joined BTI360 I knew enough about the culture to know that it was a place that valued the kinds of principles I’ve described above. I hope each of you will take ownership of maintaining a strong engineering culture that will continue to make BTI360 a great place to build software.

甚至在我加入 BTI360 之前，我就对其企业文化有足够的了解，知道这是一个重视我上面所描述的原则的地方。我希望你们每个人都有维护强大的工程文化的责任，这将继续使 BTI360 成为构建软件的好地方。