软件工程师设计学院的经验教训

当我2014年大学毕业时，我获得了两个学士学位，一个是计算机科学，另一个是设计。我之所以选择设计，是因为我想学习必要的设计技能，以提高个人项目的可用性和外观。虽然我最初加入该计划获得这些硬盘，内省能力，它是软的，人际被证明是在我的职业生涯更有价值的技能和知识。我在这里分享一些有关这些技能的信息，以便其他工程师可以向他们学习。

第1课：您不是您的听众

在视觉传达设计中，您应该牢记受众。在设计时要记住这些人，这需要额外的思考和细微差别。您并不是在为自己设计东西，而是要与听众交流。他们将如何解释它？

给软件工程师的教训

同样对于工程师来说，当您构建产品时，该短语会转换为“您不是您的用户”。即使您的用户可能与您相似，他们也永远不会像您一样。当您在具有全球影响力的公司（例如Google）工作时，这变得更加明显，因为您必须为发展中国家和发达国家的用户设计产品。永远不要以为最终用户会想到与您相同的想法。

第2课：建设性的客观反馈总是比还原性的主观反馈好

我的视觉传达设计教授罗伯特·塞德拉克（我也恰好是我的顾问，也是决定加入设计计划的主要动力）在他的课堂批评中禁止使用两个词：“我喜欢”和“我不喜欢”喜欢。” 相反，他鼓励我们使用更强的措辞和较少的主观语言来提供更彻底和实质性的反馈。以下是一些示例短语：

• “我认为这是成功的，因为……”

• “我不认为成功是因为……”

• “您做X的方式加强了这项工作，因为……”

• “我认为X的方向更强是因为……”

其背后的理由是因为任何人都可以说“我喜欢这个”或“我不喜欢这个”，并在第一句话中说出与他们交谈的第一件事。通过改写反馈/评论的方式，我们被迫对设计进行更深入的分析，并清楚地阐明我们对评论的支持。当我们解释我们为作品准备的方向时，也期望有同样的交流，这迫使我们深入分析自己的工作并认真思考。

给软件工程师的教训

建设性和客观的反馈以及语言对软件工程师进行代码审查很有帮助。虽然我相信使用禁止的短语“我喜欢您如何构造这段特定代码或解决此问题”没有错，但我确实认为您不应该使用“我不喜欢如何……”一词，而是，将您的语言转换为代码审查中的建设性和客观反馈。例如，让我们看一下两种形式的反馈。

• “我不喜欢这段代码的结构方式。使用哈希映射而不是数组。”

• “您是否考虑过将其存储在哈希映射而不是数组中？我认为这可能会有更好的表现。”

两者都有相同的基本信息，但是第二个具有实质性意义，因为它包含了一个原因，而第一个则没有。

此外，在考虑捍卫代码中的实现决策时，请使用此方法。如果您因为喜欢以某种方式而不是另一种方式来执行代码而忽略了反馈或建议的代码更改，那么您的情绪可能会变得最好。退后一步问自己：“在满足要求的情况下，这真的是最好的方法吗？还是此反馈会帮助改善我的代码？”

第3课：您不是您的设计/工作

Sedlack会不断重申的另一个瑰宝是“您不是您的设计”。意味着在工作中，您不应有任何自我意识或个人依恋感。通过学习这一点，我意识到，为自己的工作感到自豪是件很棒的事，但您不应该将自己的自我意识带入工作中。这通常是因为一旦您对工作有了自我或个人的依恋感，就很难接受对工作的批评并努力对其进行迭代或改进。我发现，通过消除对设计作品的自我和个人依恋感，我可以更轻松地回头遍历我的作品，看看我是否可以从评论的反馈中将其推向更强的方向。

给软件工程师的教训

我认为这是软件工程师最有价值的课程之一。在专业和开放源代码库中，人们常常会在编写的代码中带有自我意识。一旦涉及到某人的自我，这将使协作变得更加困难，尤其是如果您认为编写的代码没有改进的余地。您是否遇到过一个始终反对在请求请求中探索建议的代码更改的人？如果其他人进入并重构了过去工作过的代码，也许他们会感到沮丧吗？或者，也许他们对自己的代码的建设性反馈感到防御。我个人认为，所有这些都是由于过于依赖您的代码而引起的，所以放手吧。通过放手，

第4课：迭代是改进的关键

在设计时，很少有人会为您的项目选择第一个方向来成为最好的方向。相反，通过迭代和探索不同的方向并在评论过程中展示它们，您可以使用评论来帮助您找到最强的方向。即使您不提出批评意见，将多件作品进行比较也可以帮助您发现优点和缺点，一旦您将多件作品进行比较。一旦确定了设计的坚实方向，就可以继续迭代该设计并对其进行批判，直到您确定它处于最佳状态为止。

给软件工程师的教训

与编码类似，解决问题的第一个方向可能不是最佳方法。很多时候，我已经编写了一些东西，但是后来意识到有一种解决问题的更优化和/或更简单的方法。在请求请求期间，同事可能会提出一个您认为没有想到的更简单或更快速的替代解决方案。最后，这些迭代将最终帮助您成长，因为您在此过程中将学到新知识。

第五课：总是批评你的工作

在所有这些先前的课程中，一个共同的要素是批评。对我的设计工作提出的最有价值的反馈或想法，总是在批评期间出现，无论是一个人还是与同学一起。在课堂上进行批判时，您将作业放在班级前面的黑板上，解释作品的使用方向和背后的原因，然后打开地板进行反馈。通常，我的同学会发现我所忽略的事物，或者帮助我找出哪个方向最强。

即使在教室外面，它也帮助我摆脱了设计的束缚，并独自进行了评论。问自己一些问题，例如：“此设计哪些地方做得好，哪些地方做得不好？它传达什么？这是我要传达的信息吗？” 退后一步，批判我自己的作品，促使我创作出最好的作品。

给软件工程师的教训

作为软件工程师，我从中学到的教训是，您应该始终进行代码审查。即使在辅助项目中，除非是一个小而快速的解决方法，否则我很少会推送到master分支。对于大多数功能，即使我是唯一从事该项目的人，我也会在一个单独的分支中进行工作并打开拉取请求。在这些请求请求期间，我会亲自检查代码，以确保没有任何错误或没有错过任何内容。我什至在我的副项目存储库中添加了朋友，并要求他们对更复杂的功能进行代码审查，以确保我不会错过任何内容。

在工作中，虽然您可能需要让团队成员在合并之前对其进行审核，但您应该自己进行一两次代码传递。您还可以使用这些请求请求来告诉审阅者，“这是我的方向，但是我也考虑过这样做，对吗？” 这与在批判期间可能会在两个方向上获得反馈一样，并且获得反馈可以引导您走上正确的道路。

总体而言，这些是设计学院的主要内容，这些对我作为软件工程师的职业来说是无价的，为此我要感谢设计学院。我希望这些课程为您提供相同的价值。