近日，HackNews 上的一则帖子引发了众多网友的热议和共鸣。人们讨论的焦点，BTI360 公司的软件工程师 Joel Goldberg 在去年 12 月临退休之际，向自己的团队成员分享了他 45 年软件编写生涯中的种种收获和教训经验。
具体地，他分享了关于知识学习、编写代码、团队相处准则、职业规划等诸多方面的心得，相信会为广大软件行业从业者带来一些启发。
以下是 Joel Goldberg 的分享内容：
回首过往在软件行业的四十多年时间，变化之大令我震惊。我的职业生涯开始时还在使用穿孔卡片，如今退休却已身处云计算时代。虽然经历了种种变化，但帮助我度过整个职业生涯的很多原则却始终没有变过，它们依然具有意义。在临退休之际，我想与大家分享自己作为软件工程师所领会到的一些感悟。
警惕知识「诅咒」
当你知道某些事情的时候，则几乎想象不到自己不清楚这些事情会是什么样子。这就是知识「诅咒」，同时它也是无尽误区和低效率的根源。那些能够适应复杂境况的聪明人更容易陷入这种「诅咒」。
如果你对知识「诅咒」不加防范，则有可能在所有形式的交流中持错误立场，包括写代码。你所从事工作的专业性越强，则越有可能以外行无法理解的方式进行交流。所以，要与知识「诅咒」作抗争。努力理解你的受众，尝试着想象一下第一次学习正在交流的事情是什么感觉。
六项基础准则
技术总是在变，但软件开发的一些基础方法却始终未变。以下是我认为未来很长一段时间都将保持不变的六项基础准则：
- 团队协作：好的团队构建好的软件，但不要认为团队协作理所当然，每个人都应参与其中；
- 信任：团队间的信任能够促进发展，努力成为一个值得自己和他人信赖的人；
- 交流：真诚主动地交流，避免陷入知识「诅咒」；
- 寻求共识：花费时间带领整个团队走上同一条「跑道」，有不同意见充分讨论以找到最佳解决方案；
- 自动化测试：经过良好测试的代码使得团队满怀信心快速开展下一步行动；
- 干净、易于理解和可导航的代码和设计：要将接管自己代码的继任工程师当成自己的客户，确保他们在阅读、维护和更新代码时不会遇到任何麻烦。
简单法则
对抗复杂情况是一件永远不会结束的事情，所以解决方案要尽可能地简单。我们可以「不怀好意」地假设维护自己代码的继任者没有你聪明。
当没有什么东西可以删除，而不是没有什么东西可以添加的时候，设计师才意识到自己达到了完美。-Antoine de Saint-Exupery
寻求理解为先
美国著名管理学大师 Stephen Covey 的 7 个习惯之一是：首先寻求理解，然后再被理解。这项准则比任何其他建议更帮助了我成为好的聆听者和工作伙伴。如果你想要影响他人并与其高效地合作，则首先需要理解他们。在试图让他人明白自己的想法之前要积极主动地聆听并理解他们的感受、想法和观点。
小心被套牢
行业中总是会出现可能会变革软件构建方式的下一代高效产品，如计算机辅助软件工程（CASE）工具、COTS、Peoplesoft 和 SAP 等企业资源规划产品甚至是 Ruby 等。这些产品都声称，如果人们接受了它们的整体开发理念，则会大幅度降低成本和时间。然而事实并不总是如人们预料那般顺利，前期成本可能会很大，你受到的限制也依然很多。「被套牢」过去常常出现在供应商层面，但现在框架层面也出现了这种情况。无论哪个层面，高昂的沉没成本都意味着改变的压力很大，新事物也并不总是更好的。
当不适合某个角色时要勇于承认并改变
在职业生涯的某些阶段，你可能会发现自己并不适合某些角色。这种不适合并不是性格上的缺陷，而是一个你不应忽视的问题。解决这种困境的方法不止一种：你可以继续提升自己或者改变角色。关键要有自知之明，要意识到自身处境并让自己脱离这个不利于发展的角色。工作中不快乐对任何人都没有好处。
当我在通用汽车工作时，企业文化是这样的：如果你不想着管理更多人或者负责更大更复杂的项目，那么你就是失败者。对于多数人来说，这是一条苦不堪言的职业发展道路。
在 EDS 时，企业文化不是这样，管理岗位人员是流动的。从策略规划师等权限更大的岗位上下来从事项目管理或项目开发人员等权限更小的岗位并不是一件丢人的事。我就利用了这种人员的流动性，从技术金字头顶端的角色回归到了普通的项目开发人员。对此，我从不后悔。
