您在所建议的软件设计中是否始终从根本上正确？当您给出一些根本上是错误的设计时，您往往会失去团队成员的尊重。无论您做什么，之后都将对事件发生后您提出的所有建议进行交叉检查。当您刚加入团队并且他们不知道您的过去并取得了一些成功的故事时，情况尤其糟糕。
也许您设计不好的原因是由于在该领域缺乏经验或知识或两者都不是。面对这种情况的您如何处理？这是您职业生涯中的一回事吗？还是它会断断续续地发生？是将其抛在后面还是在这种情况下需要寻找新的工作方式？请提供一些诚实的反馈...
谢谢。
#1 楼
一次，一家财富500强企业的副总裁，该公司因一项糟糕的商业决策而损失了100万美元。当他向CEO辞职时，他得到的回应是：“我刚刚在您的教育上投入了100万美元，现在您正打算离开？我不接受。”我成长厌倦了经理和其他工人，他们很快就将错误归咎于某人是菜鸟或认为自己没有能力。成为好的设计师只有一种方法，那就是提高几百美元。我不在乎我的员工是否犯错，我不在乎他们是否多次犯同样的错误。问题是，你有多谦虚，又有多受教育？当有人向您提出错误时，您是先为自己辩护还是听到他们的声音？如果您是少数能够吞并他的骄傲并从中学习的人，那么您值得一试。您一次因犯错误而失去尊重的人，也不应该得到您的尊重。
我个人至少不得不重写我设计的前两个项目两次，但是您知道吗？我学到了很多东西，尽管当时我的老板很烦恼，但很快就被我愿意从错误中吸取教训所获得的效率所抵消。
关于羞辱方面以及如何要恢复，我有两条建议。首先，人们会随着时间的流逝而忘记。同样，当其他人成为他们的焦点时，他们也会搞砸。然后，所有人将再次平等。其次，当别人犯诚实，学习和错误时，不要对他们混蛋。实际上，除非他们确实需要坚决反对，否则您应该鼓励他们。随着时间的流逝，您可以记住自己犯了一个诚实的错误时的感受，从而帮助改变团队的文化。您最终将激发人们成为更好的程序员，设计师和人类。
评论
我真的很喜欢这个评论。过去，我在工作场所犯了一些错误，虽然我并不完美，但我确实有一点要向他们学习。我去找我的同事（这个领域比我高得多），问我可以做得更好，她给了我一些很好的指导。我想认为我现在做得更好。知道自己搞砸了确实很痛，并且感到羞辱，但最终还是过去了。这对我来说是鼓舞人心的，因为它告诉我我做了正确的事，并且这将会发生。特别是因为这实际上是我的第一份工作。 :)
–本·理查兹（Ben Richards）
2011年8月4日在18:22
人们确实会忘记您的权利。有一次，我曾在拙劣的数据库升级中帮助公司倒闭了半天。那真是可怕的一天，但我已经过了，我想其他所有人也是如此。
–克拉茨
2011年8月4日在19:57
有趣的轶事和一个重点。我当然在想：CEO容易说。没有投资自己的钱。游戏中有皮肤的人对巨大的错误不会有如此离奇的反应。但是，如果说实话，他们会认识到他们在此过程中犯了许多小错误，并从每个错误中吸取教训。关键是要迅速失败，说实话并为下一个错误选择新的东西。 :)这种态度将在值得您投入其职业生涯时间的公司中得到认可和奖励。
– Greg Hendershott
2011年8月4日23:20
@BiAiB副主席-通常表示“第二把手”。
–乔纳森·汉森（Jonathan Henson）
2011年8月5日14:03
@格雷格H：“ bizzarely超脱？”不，只有理性。试图做好工作的人会犯错，并从中汲取教训。在学到更好的知识后，用没有经验的其他人来代替这个人是一个错误的决定。他们的新家伙可能拥有干净的记录，但这仅仅是因为他从未尝试过任何有趣的事情。
–赞·山猫
2011年8月6日，下午5:50
#2 楼
我已经进行了很长时间（超过15年），但第一次还是做得不好。最好的设计来自迭代的协作过程。当您从事一段时间的设计时，很容易陷入思考这是唯一可以完成设计的想法。全新的视角有助于发现您错过的事物。为了使这一工作正常进行，团队需要相互信任。您不必害怕向人们展示可能存在缺陷的设计，并且需要能够接受对设计的批评。反过来，团队的其他成员需要了解设计中的缺陷并不是对设计师的反映。这是设计的预期部分。这也是团队成员如何学习和变得更好的方法：从他们自己的错误和其他人的错误中得到的改善。
如果您的团队运作不正常，那么您有两种选择：
尝试修复团队
（在内部或在新雇员身上）找到新团队。
#3 楼
据我所知，我从根本上是可以辩护的。从根本上说，这与完全不同。通常情况会在您必须做出“ x”决定的时间与清楚地知道“ x”是事后看来是错误的决定之间的时间发生变化。这就像在准备您的美国所得税。许多人认为应该有一个答案。没有。您有自己的见解；您的税务会计师有她的意见；国税局有他们的意见。
当我犯错时，我不会失去任何人的尊重。 （据我所知。）我认为这是因为，在某种程度上，我总是承认自己的错误。 （实际上，我经常发现自己的错误。）而且，几乎所有重要的设计决策都需要一个以上的人来签名。这些决定中的任何错误均归团队所有，而不是一个人所有。
就承认错误而言，我认为，随着您获得能力和经验，这会变得更加容易。根据我的经验，您设计和开发的新事物越少，您犯错误的可能性就越小。
它会不停地发生，并且不应该破坏您的职业生涯。承担重大责任的人都不会始终做出正确的决定。实际上，没有一个承担重大责任的人总是做出合理的决定。
但是大多数时候，您应该能够基于不完整的信息做出合理的决定。就像我女儿会说的：“那只是人。”
评论
我知道的越多，我知道的我就越不知道。我的知识广度比我对要知道的事物的认识要慢。我只是每天努力变得更好。我使用我所知道的最佳实践。我了解到，其中一些并不如我想象的那样好。不幸的是，我同意随着经验的积累，承认错误会变得更加容易。但是，如果您没有经验，应该会犯错误。
–BillThor
2011年8月5日在2:46
好答案！我当然在设计上犯了错误，但我不认为我曾经被他们羞辱过，也没有失去队友的尊重。我的决定总是出于某种原因而做出的，当事实证明我的推理是基于错误或不完整的知识时，我总是承认错误并努力予以纠正。
– Carson63000
2011年8月5日在3:59
#4 楼
有时每个人都会出错。错误是不可避免的。错误地自由承认，从错误中学习并表现出谦卑，尤其是当您最初不相信自己确实是错误的时。“屈辱”永远不会发生。根本不可能改善一个人的表现。
在我公司，我们已经树立了一种尊重那些仍然愿意在艰难的决定上坚持不懈但可以接受的人的文化。错误，并在需要时调整其行为。
评论
我将第二个“尊重文化”。我很遗憾地成为我们公司的两位程序员之一。为什么不幸呢？因为每次我（或者确实有人）犯错时，其他程序员都会在您的面前大笑，就像您是个白痴。更糟糕的是，当他犯了一个错误时，他总是设法将责任归咎于其他地方（另一名职员，Windows和行星定位）。这根本不是应该的事情，因此，我绝对不愿向他寻求帮助，因为担心会变成小便竞赛。
–hermiod
2011年8月4日在22:24
#5 楼
您在提出的软件设计中从根本上是正确的吗？
是的，我是超人！好吧，当然不会。
当您提出一些根本上是错误的设计时，您往往会失去团队成员的尊重。
不！如果发生这种情况，那么团队合作精神就会出问题。
每个人都会犯错。有些解决方案是好的，有些是坏的，大多数介于两者之间。您和团队的其他成员都应该将成功和失败都作为一个教训。
第一个错误可能让人感到难过，但是在犯了数百个错误之后，这就像部分错误一样工作。
#6 楼
它发生在每个人身上。最主要的是要从错误中吸取教训，并尽量避免再次发生。另外，请务必承认这是您的错误。例如，我曾经犯过使用劣质数据访问层（SubSonic3）的错误。在我做出决定时，我只是想摆脱手工制作的SQL查询。因此，我选择了当时最容易上手的工具之一。我对DAL也不太了解。好吧，在解决了一些问题之后，我想知道为什么有些查询花费的时间太长，并且发现SubSonic没有充分的理由拉下整个表。因此，我告诉老板，解释我犯了一个错误，并给出了解决方案。当然，我的老板并不热衷于我犯了一个相当大的错误，需要几天的纯粹迁移。但是，他还确保我不会再犯同样的错误。他让我为我建议迁移到的下一个数据访问层创建了一个概念验证项目，我们确保它可以满足我们的要求，并且不会拖延整个表。总而言之，这对我来说是一次很好的学习经历，现在，我将确保确保项目的关键部分能够满足要求，并且不会出现大问题。
所以基本上你是怎么做的：
承认你犯了一个错误
制定一个计划来解决它
确保你的错误该计划将真正生效。
请再次确认。
解决该问题！
如果不确定如何解决该问题，请不要害怕让其他团队成员参与其中。
最后一件事，放松！每个人都会犯错误。很少有人第一次就能做到完美
#7 楼
这是令人讨厌的撒尿大赛的东西，不是一个好情况。没有人永远是对的，如果有人想出了一种更好的方法来解决问题，或者发现问题出在这里，也不会感到羞耻。您需要从解决方案中脱颖而出，并花时间尝试寻找最佳解决方案，这样即使问题解决了，您也可以感到满意。被其他人。
#8 楼
您在问题中没有说很多。我无法告诉您“设置外观”的设置。是与同行就您计划的方法进行初步讨论，还是交付您希望的最终代码？如果是前者，则没有理由感到难过，也没有理由让同行对
如果您要等到最终交付与他人讨论您的设计时，那么我不怪他们对您的其他工作表示怀疑。
每个人都需要与他人讨论他们的设计。根据复杂性或重要性，您可能需要多次与多人讨论。每个人都可能犯错，误解要求或错过特殊情况。
早期发现的错误更容易修复，而且成本更低。除非您一遍又一遍地重复同样的错误，否则它们应该是可以原谅的。通过同行评审，可以更轻松地及早发现错误。
如果您想成为团队环境中的孤独程序员，那么您将犯下（几乎无法原谅的）罪恶，认为自己足够完美，可以做到不需要别人的帮助。这是一个团队环境，这一事实证明问题足够大，以至没有人会完全了解它。人们必须互相交谈，否则错误会使他们的丑陋的头抬得太近而无法释放（或释放后）。
评论
我提出的解决方案并没有受到我的团队的质疑，因为他们都是大三。我被带到团队来解决团队无法解决的问题。另外，已经存在设计不良，代码异味等问题。我被当做万能药来解决所有问题并使客户满意。当我向比我有更多经验和更好质量的客户提出新设计时，我开始意识到，就像他击倒它一样，我在某处做出了根本错误的决定。它比团队所做的要好一些，但是仍然有很多缺点。
–user20358
2011年8月5日上午10:11
作为高级资源，我应该知道这些事情。我敢肯定，我的团队也有同样的想法。
–user20358
2011年8月5日上午10:12
@ user20358我想说，仍然应该有时间挽救您在团队中的声誉。重大问题无法立即得到解决。您是成为一发不可收拾的魔术子弹，还是一直在为团队增加经验？希望后者。假设您需要与团队融合，这样他们就可以教给您他们在此过程中学到的知识，并可以利用您的经验指导他们朝着更好的方向发展。认可他们的成功并指导他们，以便他们看到并发现改善产品的方法。
– Jimreed
2011年8月5日在12:23
#9 楼
一方面，我总是在好决定与坏决定之间做出区分。以及其他正确和不正确的决定。一个好的决定是，在相同的情况下，使用相同的信息，您将以相同的方式做出决定。一个错误的决定是您将做出不同的决定。一项正确的决定是，经过事后的了解和其他信息，证明是正确的；常常会说没有做出错误决定的人从不做任何事情。错误的决定是人们学习的方式。错误的决定常常会加剧，因为决策者会投入自己的精力，然后试图追溯该决定的合理性，或者证明这毕竟是一个好的决定（掩盖总是比原始决定更具破坏性）。我所做的大多数设计决策都被证明是正确的，但是我学到了很多东西，并且从那些不正确的决策中学到了更多。我希望我的决定很少是错误的决定，但是一个人的错误决定所造成的部分问题是认识到一个决定是错误的，并接受由此而来的常常令人不快的教训。
#10 楼
只要他们不是“星期一早上的四分卫”。我没有座无虚席地参加所有设计讨论，只是声称他们知道事实不起作用，这毫无用处。即使没有将其置于建设性的环境中，您也必须能够接受批评。SO网站的最佳功能之一可能是能够冒险，提出和不确定的解决方案。这就是你学习的方式。愚昧无知地生活在你的脑海里，这是错的，但从来没有被告知相反，这是对你的无知。
他们可能知道一些您不了解的东西，但他们不会一无所知。克服它，开始工作，并完成工作。让他们浪费时间以为自己是如此聪明。
#11 楼
我一直提供良好的设计吗？没有！我努力做到最好，并且努力变得更好，但是在每个后续项目中，我似乎总是可以做的就是回顾我以前所做的事情，并以某种方式畏惧我如何错过分数。对于某人提出了一个不太出色的设计，如果该人表明他或她愿意从错误中吸取教训并乐于接受批评，那么我不会反对该人。如果我看到有证据表明这个人正在努力变得更好并且有能力做到这一点，那么糟糕的设计建议就是一个学习的机会。
#12 楼
它不时发生在每个人身上，所以最好的办法是弄清楚设计错误的原因并从中学到东西。如果缺乏知识，那么设计失败将希望给您一些新知识，供您下次使用。不要让它灰心，每个人都会在某个时候经历这个。这是获得经验并赶上新团队/环境的最佳途径。#13 楼
这将经常发生。我们的行业瞬息万变，永远不会出错的机会实际上为零。但是，您是否将糟糕的设计推向了他们的反对？这就是为什么他们反应过度的原因。
如果犯下的错误很大，那么恢复尊敬当然需要时间。如果您的一个同事误导您并给整个团队带来麻烦，您是否不需要他在短期内进一步证明自己？
您所能做的就是承认自己是错误，对谁是对的给予赞赏，并在将来努力更好地倾听和更好地研究。
您认为设计有误的原因是什么？ （不是随机的示例-设计一个导入过程以使用逐行运行的现有Web服务（代码重用，只需要在一个地方更改业务规则），而没有意识到某些导入将拥有数百万条记录，并且需要几天的时间才能完成完成。）从中学到东西，以后再考虑。
评论
不，我努力推动不良设计。我被带到团队来解决团队不断失败的问题。另外，已经存在设计不良，代码异味等问题。我被当做万能药来解决所有问题并使客户满意。可以说，当我向比我有更多经验和更高质量的客户提出这种新设计时，我开始意识到，就像他拒绝它一样，我在某处做出了根本错误的决定。它比团队所做的要好一些，但是仍然有很多缺点。
–user20358
2011年8月5日下午14:05
我确实承认自己错了，但这对我有很大帮助，因为考虑到我的经验，我应该对我的经理和客户都了解得更多。
–user20358
2011年8月5日下午14:09
然后，您只需要努力在短期内向他们证明自己。人们会犯错，重要的是他们如何从错误中恢复过来。听起来好像您没有进行设计所需的信息，也许您需要在下一个设计建议之前考虑进行更彻底的研究。当somethign已经处于不良状态时，很难设计解决所有问题的方法，您可以集中精力解决一些问题，但更关键的问题可能并不那么明显。
–HLGEM
2011年8月5日14:13
#14 楼
总会有错误。犯错就是要成为程序员。继续向互联网上的其他人学习，尤其是向您的同事学习。在这里，唯一的遗憾就是放弃，或者从头到尾都将头埋在沙子里。将它放在身后，低下头，尽力而为。如果您是一个优秀的程序员，那么您会犯错。
#15 楼
如果不确定自己的想法是否扎实，则应在向整个公司或部门提出建议之前与一些值得信赖的同事进行讨论。实际上，即使您确定，也应该与您的同事以及最有可能最了解您的人进行讨论。它们将帮助您及早发现问题。#16 楼
它有时发生在我们所有人身上。使用第一个设计作为原型。找出确切的方法，什么没有，为什么。然后，您可以编写出更好的最终产品。不要试图为自己辩解或防御。承认错误并继续前进。
#17 楼
基本问题似乎没有得到解释：这是一个社会问题。您几乎可以在每个职业中看到这种行为：如果您犯了一个错误，并且他们喜欢将您归类到某种东西中，那将是永远的。这是一种社会行为。让我给你一个与编程无关的例子：在我以前的工作中，我忘记洗碗一两次。从那时起，所有工人都以为我是那种从不洗碗的人。现在，一旦水槽里有脏东西，那就是我（还有可能是谁）。
到处都是一样：这是一种社会行为，无论它会带来什么样的问题是。
您告诉我您要诚实的反馈吗？唯一的解决方案是辞职。如果团队中的所有人都认为您不擅长工作，那么它很快就不会改变，很抱歉这么说。因此，寻找另一份工作，因为您永远都不会改变这种（我必须承认的愚蠢）社会行为。
#18 楼
关键是您如何陈述案情以及进行哪些更改。如果您自称是没有错并且比Jon Skeet出色的编程大师，那么很可能在某个时候您会为此而失望。关键是如何呈现解决方案，以便能够证明这是解决问题的合理方法，而不是甚至不应该检查的完美解决方案。我最好的例子是在我曾经工作过的Web应用程序中发现类
static的副作用。我不知道让一个实例持久存在并在应用程序的所有用户之间共享将有多严重，但是我从中学到了并及时恢复了。有时可能是发现了某些东西，必须进行重大更正。我也曾去过那个营地，我不得不筛选一堆VBScript来减少我曾经工作过的导致内存问题的字符串串联。我什至还记得在1998年编写一个发现客户的代码段时必须动态生成SQL的代码，因为我在应用程序的那部分有大约20个可选字段，因此我甚至还记得写过易受SQL注入攻击的代码。完美主义在这里可能是一把两刃剑，这是我看到第三条评论的方式，也是我有时的一种方式。糟糕的是看到所有这些错误，没有什么是正确的。好处是，尽自己所能，即使不超过他人对您的期望，您也很可能会满足。持续改进很可能是PC观察完美主义的方法，如果保持适度，我确实认为这是一件好事。对于所有的错误，您的代码会投入生产吗？完成工作了吗？这些都是要考虑的点，以及是否有人总是在修理它，还是您想变得如此出色以至于您不愿意做任何其他事情直到完美就好呢？实践可以帮助您找到更好地完成工作的模式。但是，要理解在首先要处理其他火灾时再进行细微调整的成本效益分析，有话要说。
评论
我不是乔恩·斯凯特（）
–user20358
2011年8月5日在10:19
我也犯了类似的错误。决定在MVC应用中将静态类保留为控制器。来自程序背景，我的OOP思想每天都在发展。在决定何时抽象和何时不抽象时，我仍然认为我需要学习很多东西。什么时候继承，什么时候进行合成。更糟糕的是，被击落后，我会花时间学习，一段时间后感觉好像我终于明白了。直到我再次被击落..然后才回到花时间学习。
–user20358
2011年8月5日上午10:25
我不介意学习。即使您每次都会犯错误，但您不断犯错，这就是您失去的声誉。对于周围的每个人，看起来您仍然犯了很多错误。您每次都从中学到并且变得越来越好，这不是一个新事物。
–user20358
2011年8月5日上午10:26
评论
也许设计是正确的，只是针对不同的系统；-)不要在代码/设计中投入大量的自我，因为有太多因素期望完美。相反，要投资于您的学习意愿，诚实（尤其是自诚实）和团队合作精神。在第一天设计就可以完美，而在第二天需求就改变了！从中学习并继续为什么要附加到您的设计中？目标应该是为产品/公司做最好的事情。提出一些建议。询问人们的想法；让他们发现缺陷。发现瑕疵？冲洗并重复。没有瑕疵吗？去吧。需要就利弊进行辩论或讨论吗？然后这样做。在需要保护的地方捍卫您的设计。当它不起作用时，放开它。为什么这会令人尴尬？正在集思广益。人们应该总是灵活地建议最荒唐，最愚蠢的事情....
我认为您并没有讲完整的故事。尽管每个人并不总是能产生出出色的设计，但除非设计师明显不知道，否则他们不会倾向于使其他人认为自己没有能力。我怀疑您只是不“了解”，还是他们试图指出一些改进而您不同意，很可能在此过程中拒绝了一些非常基本的原则。两者都会使我对开发人员的工作进行更多的监督。
我没有不同意。我提出的解决方案并没有受到我的团队的欢迎，因为他们都是初中生。当我向比我有更多经验，质量也更好的客户提出这个建议时，我开始意识到他正将其击落我在某处做出了根本错误的决定。我不仅觉得自己是个傻瓜，而且还觉得我让我的团队成员失望了，因为他们信任我，现在我怀疑他们会这样做。我不怪他们。我会怀疑我是否在他们的位置。
一个好的开发者不是一个总是做出正确决定的开发者，而是一个做出错误决定，承认并迅速从中恢复的开发者。