设计缺陷并从中处理屈辱[关闭]

您在所建议的软件设计中始终从根本上正确吗？当您给出一些根本上是错误的设计时，您往往会失去团队成员的尊重。无论您做什么，之后都会对您在事件发生后提出的所有建议进行交叉检查。当您刚加入团队并且他们不知道您的过去并取得了一些成功的故事时，情况尤其糟糕。

也许您设计不好的原因是由于在该领域缺乏经验或知识或两者都不是。面对这种情况的您如何处理？这就像是您职业生涯中的一回事吗？是将其抛在后面还是在这种情况下需要寻找新的工作方式？请提供一些诚实的反馈...

谢谢。

一次，一家财富500强企业的副总裁，该公司因一项糟糕的商业决策而损失了100万美元。当他向首席执行官辞职时，得到的答复是：“我刚刚在您的教育上投入了100万美元，现在您正试图离开？我不接受。”

我厌倦了经理和其他工人，他们很快就将错误归咎于某人是菜鸟或假设他们没有能力。成为好的设计师只有一种方法，那就是提高几百美元。我不在乎我的员工是否犯错，我不在乎他们是否多次犯同样的错误。问题是，你有多谦虚，又有多受教育？当有人向您提出错误时，您是先为自己辩护还是听到他们的声音？如果您是少数能够吞并他的骄傲并从中学习的人，那么您值得一试。您因一次失误而失去尊重的任何人，都不应该得到您的尊重。

我个人必须至少重写两次设计的前两个项目，但是您知道吗？我学到了很多东西，尽管当时我的老板很烦，但是很快就被我愿意从错误中学习的效率所抵消。

关于羞辱方面以及如何恢复，我有两个建议。首先，人们会随着时间而忘记。同样，当其他人成为他们的焦点时，他们也会搞砸。然后所有人将再次平等。其次，当别人犯诚实，学习和错误时，不要对他们混蛋。实际上，除非他们确实需要坚决反对，否则您应该鼓励他们。随着时间的流逝，您可以记住自己犯了一个诚实的错误时的感受，从而帮助改变团队的文化。您最终将激发人们成为更好的程序员，设计师和人类。

我已经进行了很长时间（超过15年），但第一次还是做得不好。最好的设计来自迭代的协作过程。当您从事一段时间的设计时，很容易陷入思考这是唯一可以完成设计的想法。全新的视角有助于查看您错过的事物。

为了使它起作用，团队需要彼此信任。您不必害怕向人们展示一个可能存在缺陷的设计，并且需要能够接受对该设计的批评。反过来，团队的其他成员需要了解设计中的缺陷并不是对设计师的反映。这是设计的预期部分。这也是团队成员学习和变得更好的方式：从他们自己的错误和其他人的错误中学习。

如果您的团队无法正常运作，则有两种选择：

1. 尝试修复团队
2. 寻找一个新团队（在内部或在新员工那里）。

据我所知，我从根本上是可以辩护的。这是不太一样的东西为从根本上正确。在事后看来，情况常常会在您必须做出决策“ x”的时间与清楚地知道“ x”是错误的决策的时间之间发生变化。

这有点像准备您的美国所得税。许多人认为应该有一个答案。没有。您有自己的见解；您的税务会计师有她的意见；国税局有他们的意见。

当我犯错时，我不会失去任何人的尊重。（据我所知。）我认为这是因为，在某种程度上，我总是承认自己的错误。（实际上，我经常会发现自己的错误。）而且，几乎所有重要的设计决策都需要一个以上的人来签名。这些决策中的任何错误均归小组所有，而不是完全由一个人负责。

至于承认错误，我认为随着您获得能力和经验，这会变得更加容易。根据我的经验，您设计和开发的新事物越少，您犯错误的可能性就越小。

它断断续续地发生，并且不应该破坏您的职业生涯。承担重大责任的人都不会始终做出正确的决定。实际上，没有任何重要职责的人总是做出合理的决定。

但是大多数时候，您应该能够基于不完整的信息做出合理的决定。就像我女儿会说的那样，“那只是人。”

有时每个人都会出错。错误是不可避免的。当您错了时，自由地承认自己，从错误中学习，并表现出谦卑，特别是如果您最初不确信自己确实错了。

“屈辱”永远不会发生。它根本不可能改善一个人的表现。

在我的公司，我们已经建立了一种尊重他人的文化，这些人仍然愿意坚持艰难的决定，但可以承认自己犯错并在需要时调整自己的行为。

您在所建议的软件设计中始终从根本上正确吗？

是的，我是超人！好吧，当然不会。

当您给出一些根本上是错误的设计时，您往往会失去团队成员的尊重。

没有！如果发生这种情况，则团队精神存在问题。

每个人都会犯错。有些解决方案是好的，有些是坏的，大多数介于两者之间。成功与失败都应作为您和团队其他成员的课程。

最初的错误可能会让人感到难过，但是在犯了数百个错误之后，这就像工作的一部分一样。

它发生在每个人身上。最主要的是要学会从自己的错误，并尽量不要让历史重演。另外，请务必承认这是您的错误。例如，我曾经犯过使用下级数据访问层（SubSonic3）的错误。在我做出决定时，我只是想摆脱手工制作的SQL查询。因此，我选择了当时最容易上手的工具之一。我对DAL也不太了解。好吧，解决了一些问题之后，我想知道为什么有些查询花了太长时间，却发现SubSonic没有充分的理由撤下整个表。

因此，我告诉老板，解释我犯了一个错误，并给了我解决问题的计划。当然，我的老板并不热衷于我犯了一个相当大的错误，需要几天的纯粹迁移。但是，他还确保我不会再犯同样的错误。他让我为我打算迁移到的下一个数据访问层创建了一个概念验证项目，我们确保它可以满足我们的要求，并且不会拖延整个表。总而言之，这对我来说是一次很好的学习经历，现在，我将确保确保项目的关键部分能够满足要求，并且不会出现大问题。

因此，基本上，您要做的是：

1. 承认你做错了
2. 制定解决方案
3. 确保您的计划切实可行
4. 再次确认。
5. 修理它！

如果不确定如何修复，请不要害怕让其他团队成员参与。

最后一件事，放松！每个人都会犯错。很少有人第一次就能做到完美

这是令人讨厌的撒尿比赛的东西，不是一个好情况。没有人永远是对的，如果有人想出了一种更好的方法来解决问题，或者发现问题出在这里，也不会感到羞耻。你做到的方式。

你需要从感情上放弃自己的解决方案，并且花时间试图找到最佳的解决方案，那么你可以很高兴，当问题得以解决，即使它是由别人来解决。

您在问题中没有说很多。我无法告诉您“设置外观”的设置。是与同行就您计划的方法进行初步讨论，还是交付您希望的最终代码？

如果是前者，那么没有理由感到难过，也没有理由让您的同伴将来怀疑您。

如果您要等到最后交付时与他人讨论您的设计，那么我不会怪他们对您的其他工作感到怀疑。

每个人都需要与他人讨论他们的设计。根据复杂性或重要性，您可能需要多次与多人讨论。 每个人都可能犯错，误解要求或错过特殊情况。

尽早发现错误，更容易解决，而且成本更低。除非您一遍又一遍地重复同样的错误，否则它们应该是可以原谅的。同行评审使更容易及早发现错误。

如果您想在团队环境中成为一名孤独的编码员，那么您就会犯（几乎无法原谅）的罪过，认为自己足够完美，不需要其他人的帮助。这是一个团队环境，这一事实证明问题足够严重，以至没有人会完全了解它。人们必须互相交谈，否则错误会使他们的丑陋的脑袋抬得太近而无法释放（或释放后）。

一方面，我总是在好决定与坏决定之间做出区分。以及其他正确和不正确的决定。一个好的决定是，在相同的情况下，使用相同的信息，您将以相同的方式做出决定。一个错误的决定是您将做出不同的决定。一项正确的决定是，经过事后的了解和其他信息，证明是正确的；相反，错误的决定。

人们常说，没有做出错误决定的人从不做任何事情。错误的决定是人们学习的方式。错误的决定往往会加剧，因为决策者会投入自己的精力，然后试图追溯该决定的合理性，或者证明这毕竟是一个好的决定（掩盖总是比原始决定更具破坏性）。

事实证明，我所做的大多数设计决策都是正确的，但是我学到了很多东西，并且对那些不正确的决策有了更多的了解。我希望我的决定很少是错误的决定，但是一个人的错误决定的部分问题是要认识到一个决定是错误的，并接受由此而来的令人讨厌的教训。

只要他们不是“ 星期一早上的四分卫”。对于没有参加过所有设计讨论而只说他们知道事实不起作用的人，我毫无用处。即使没有提出建设性的意见，您也必须能够接受批评。

SO站点的最佳功能之一可能是能够冒险并提出不确定的解决方案。这就是你学习的方式。一辈子都胡说八道，这是错误的，但从来没有被告知相反，这是真正的无知。

他们可能知道一些您不了解的东西，但他们不会一无所知。克服它，开始工作，并完成工作。让他们浪费时间以为自己是如此聪明。

我一直提供良好的设计吗？没有！我努力做到最好，并且努力变得更好，但是在每个后​​续项目中，我似乎总是可以做的是回头看我以前做过的事情，并以某种方式畏惧如何错过分数。

至于提出一个不太出色的设计的人，如果那个人表明他或她愿意从错误中吸取教训并乐于接受批评，我不会反对。如果我发现有证据表明这个人正在努力变得更好并且有能力这样做，那么糟糕的设计建议只是一个学习的机会。

现在再发生在每个人，所以做的最好的事情是要弄清楚为什么设计是错误的，从学习。如果缺乏知识，那么设计失败将希望给您一些新知识，供您下次使用。不要让它灰心，每个人都会在某个时候经历这个。这是获得经验并赶上新团队/环境的最佳途径。

这将经常发生。我们的行业瞬息万变，永远不会出错的机会实际上为零。

但是，您是否将不良设计推翻了他们的反对意见？这可能就是他们反应过度的原因。

如果错误很大，那么恢复尊敬当然需要时间。如果您的一个同事误导您并给整个团队带来麻烦，您是否需要他在短期内进一步证明自己？

您所能做的就是承认自己做错了，相信谁是对的，并努力在将来更好地倾听和研究各种选择。

您不认为是什么使设计出错？（不是随机的示例-设计一个导入过程以使用逐行运行的现有Web服务（代码重用，只需要在一个地方更改业务规则），而没有意识到某些导入将拥有数百万条记录，并且需要几天的时间才能完成完成）。从中学习并在将来考虑这些事情。

会有总是出现失误。犯错就是要成为程序员。继续向互联网上的其他人学习，尤其是向您的同事学习。这里唯一的耻辱是放弃，或者从头到尾解决此类问题。

把它放在你身后，低下头，尽力而为。如果您是一个优秀的程序员，那么您会犯错。

如果不确定自己的想法是否扎实，则应在向整个公司或部门提出建议之前与一些值得信赖的同事进行讨论。实际上，即使您确定，也应该与您的同事以及最有可能最了解您的人进行讨论。他们将帮助您及早发现问题。

它有时发生在我们所有人身上。使用第一个设计作为原型。找出确切的方法，什么没有，为什么。然后，您可以编写出更好的最终产品。

不要试图为自己辩解或防御。承认错误并继续前进。

基本问题似乎没有得到解释：这是一个社会问题。您几乎可以在每个职业中看到这种行为：如果您犯了一个错误，并且他们喜欢将您归类到某个特定的东西中，那将是永远的。这是一种社会行为。甚至聪明又聪明的人也会倾向于跟随所有人。

让我给你一个与编程无关的例子：在上一份工作中，我忘记洗碗一两次。从那时起，所有工人都以为我是那种从不洗碗的人。现在，一旦水槽里有脏东西，那就是我（还有谁可能）。

到处都一样：这是一种社会行为，无论它可能是什么问题。

您告诉我您想要诚实的反馈吗？唯一的解决方案是辞职。如果团队中的所有人都认为您不擅长工作，那么它很快就不会改变，很抱歉这样说。因此，寻找另一份工作，因为您永远都不会改变这种（我必须承认的愚蠢）社会行为。

关键是您如何陈述案情以及进行哪些更改。如果您自称是没有错并且比Jon Skeet更出色的编程专家，那么很可能在某个时候您会被拒绝。关键是如何呈现解决方案，以便能够证明这是解决问题的合理方法，而不是甚至不应该检查的完美解决方案。

我最好的例子是发现static在我曾经工作过的Web应用程序中放置类的副作用。我不知道让一个实例持久存在并在应用程序的所有用户之间共享将有多严重，但是我从中了解到并及时恢复了。有时可能是发现了某些东西，必须进行重大更正。我也曾去过那个营地，我不得不筛选一堆VBScript来减少我曾经工作过的导致内存问题的字符串串联。我什至还记得在1998年编写一个发现客户的代码段时必须动态生成SQL的代码，因为我在应用程序的那部分有大约20个可选字段，我什至记得写过易受SQL注入攻击的代码。

完美主义在这里可能是一把两刃剑，这是我看到第三条评论的方式，也是我有时的一种方式。糟糕的是看到所有这些错误，没有什么是正确的。好处是，尽自己所能，即使不超过他人对您的期望，您也很可能会满足。持续改进很可能是PC观察完美主义的方法，如果保持适度，我确实认为这是一件好事。对于所有的错误，您的代码会投入生产吗？完成工作了吗？这些都是要考虑的点，以及是否有人总是在修理它，还是您想变得如此出色以至于您不愿意在完成完美之前不做任何其他事情，这是件好事吗？实践可以帮助您找到更好地完成工作的模式。然而，