如何改正大三，但鼓励他自己思考呢？[关闭]

我是一个小团队的负责人，每个人都有不到一年的软件开发经验。我绝对不会称自己为软件专家，但几年来我在编写软件方面学到了一些东西。

当我们进行代码审查时，我会做很多教导和纠正错误。我会说诸如“这太复杂和令人费解，这就是为什么”或“将这种方法移到一个单独的类中您会怎么想？”之类的话。我要特别谨慎地进行交流，如果他们有问题或反对意见，那就可以了，我们需要讨论。每当我纠正某人时，我都会问：“你觉得怎么样？” 或类似的东西。

但是，他们很少甚至不同意或询问原因。最近，我一直在注意到更多公然的迹象，表明他们在盲目同意我的说法，但没有形成自己的观点。

我需要一个能够学会自主做事的团队，而不仅仅是遵循指示。如何纠正初级开发人员，但仍然鼓励他自己思考？

编辑：这是以下这些明显迹象之一的示例，这些迹象表明它们没有形成自己的意见：

我：我喜欢您创建扩展方法的想法，但是我不喜欢您如何将大型复杂lambda作为参数传递。Lambda迫使其他人过多地了解该方法的实现。

Junior（误解了我）：是的，我完全同意。我们不应该在这里使用扩展方法，因为它们会迫使其他开发人员对实现了解太多。

有一个误会，已经解决。但是他的发言中甚至没有逻辑上的要求！他以为自己是在反省我的逻辑，以为当他真的不知道为什么要说出来时才有意义。

简短答案：

吸引他们（让他们困惑），增强他们的能力（相信他们的答案）。

这是驱动我们的问题！-矩阵。

总的来说，根据我的观察，大三学生有他们自己的世界-他们对自己的想法的看法有限，在某种程度上，他们对事物的热情/喜好/看法。

直截了当地告诉他们你错了没有错，但是最好的办法是让他们思考。为什么？还有其他方法吗？有没有更好的方法来做同样的事情？我经常使用的轶事之一是-“给我三个解决方案（针对这个问题）！”

当他们考虑这些解决方案时，他们开始意识到许多问题。这需要他们花费一些时间-但是随着时间的流逝，他们倾向于形象化地思考自己的局限性和缺点。他们开始更多地看到“我没想到！” 这比回家时感觉“我错了！”要好得多。甚至更糟的是“即使我有正确的观点，也被告知/被证明是错误的”。

通常，很小的孩子往往更擅长于技术问题（例如哪种设计模式更好！）而不是过程问题，但是随着时间的推移，当他们指导他们时，它就会起作用。

但是，他们很少甚至不同意或询问原因。最近，我一直在注意到更多公然的迹象，表明他们在盲目同意我的说法，但没有形成自己的观点。

通常这是一个结果，您确实接受了他们的建议，但后来否决了他们的建议，他们同样对您的观点不服气。只是因为您年长，他们才避免打架！

我从我以前的一位老板那里学到的最好的事情是：他将首先要求团队成员进行辩论（他们在这里感觉相当平等），并希望在所有论点都用完之后，他只会带着一个问题进入会议室：“意见分歧？” -重点是，人们总是喜欢参加辩论和讨论，但是如果他们的（有效）要点下次不采取行动，他们会认为不值得参加讨论。

不仅在软件中，而且在所有地方最终，只有最有才能的队友才会敢于回答，更不用说质疑系统了。

如果您希望大三生自己思考，请不要纠正他们：请他们纠正自己。

与其告诉他们您对他们的解决方案有何错，请向他们询问有关此解决方案的相关问题。在您的示例中，您可以询问他们有关使用扩展方法的人创建lambda所需知道的内容。不断问这样的问题，直到他们认为这是一个问题。这样，您知道他们已经理解了为什么他们的解决方案可能会成为问题，而且更有可能从中学习到-如果您仅告诉他们他们的解决方案是错误的，那是一种外部判断，很容易被忽略。如果他们自己（一点点提示）就实现了实现，那么他们将意识到实现的基础，并且更有可能从错误中学习。

此外，这为您的初中生提供了捍卫其设计的机会-也许他们已经考虑了问题并有充分的理由解决您的问题，这意味着您无需进行任何校正。这样可以减少您对行政法令做出的任何判断（无论是无意的）。

由于您有多个初级开发人员，所以请不要以组1一对1的形式进行代码审查。

通过询问小组“其他问题如何解决？”来开放，并允许其他初级开发人员首先提出其实现建议。仅在其他团队成员发言之后，并且没有人提出与您的想法类似的建议时，才添加您的实施。

然后进行圆桌讨论，讨论不同实现的相对优势和劣势，以指导初级开发人员选择最佳实现，而无需告知它是什么。

作为初级开发人员的信心构建者，您可以从一些案例开始，在这种情况下，他们选择了您认为是最好的选择，并让您的选择成为具有半明显缺陷的稻草人，并引导讨论为什么最原始的实现是最佳的。

当我刚开始从事编程工作时，我所做的与您描述的完全相同：当被告知我可以做的事情时，我总是会同意的。这主要是因为我没有足够的经验可以说不。

使我能够实际讨论方法和思想的能力是从经验中学习以及阅读有关不同方法和新技术的知识。为了使您的团队自己思考，他们需要真正了解“过分复杂和令人费解的”代码之类的东西可能会导致什么问题，而他们发现的唯一真正方法就是通过经验。

促进个人思考的一个好方法是让他们研究诸如Stack Overflow或Programmers SE之类的编程网站。我知道这些帮助我了解了现有的各种技术，并让我与团队的高级成员进行了讨论，而不是一味地同意他们。

关键是，没有经验，高级成员的建议总是对他们有用。

帖子中的互动展示了教授几乎所有内容的关键原则：请他们解释他们的想法，并认真听取他们的回答：它将准确地告诉您需要纠正的内容。

大约25年前，我从我的数学老师那里无私地复制了这个技巧，从那以后我一直没有失败过。在我短暂的教学助理期间，我在课堂上使用它，在谈论软件设计时在工作中，以及在与八岁的孩子谈论她的学校作业时与我一起使用。

当然，对于要求他们重复刚才所说的内容，您可能并不总是直言不讳，因此您需要调整策略。例如，这是我如何将OP中的后续声明重新表述为“探测”问题：

我喜欢您创建扩展方法的想法，但是我不喜欢您如何将大型复杂的lambda作为参数传递。您是否看到这种复杂的 lambda 如何迫使其他人过多地了解该方法的实现？

如果不了解您要突出显示的问题，就无法正确回答该问题。我发现以一个问题结尾的解释需要对我刚才所说的内容进行分析，从而加快了学习过程，并提供了我需要进行更正的反馈。

通常，当人们没有说出您想要的内容时，这意味着您需要继续聆听。聆听是指在通过判断之前先听到其设计的原因。这意味着不仅要告诉他们可以表示异议，而且还应诚实地考虑他们所说的话，而不仅仅是纠正他们，以此证明这一点。寻找有关其解决方案的好处，然后修改您的解决方案以合并这些问题。

您还需要以身作则。我的意思不是写超棒的代码，而是要征求他们对自己设计的意见。事实结束后，请不要等待代码审查，而要一路工作。说些类似的话，“我的界面似乎太复杂了，但是我不确定简化它的最佳方法。” 让他们有时间回答，而不必首先让他们偏向于自己的想法。

当我不得不处理这个问题时，我诚实地说过：

您知道，这是我从未想过的非常有创意的解决方案。它是如何扩展的？/您是否认为可能有一种在概念上更简单的方法来使开发更快或维护变得更容易？/不幸的是，我不认为它与项目的其余架构真正吻合。配置看起来像什么？

通常，这足以使人们朝着新的方向发展。

责任是可以帮助他们的一件事。

我过去曾领导过一两个团队，而让初中生大放异彩的一件事是个人责任的负担。当一个人意识到自己的行为可能会牵连到他身上时，他/她通常会在自己所做的事情上多花些功夫。更不用说当他们感到自己的工作时，良好的结果更加令人满意。

我不会为他们盲目地跟随您这一事实感到担心，这是他们作为大三学生应该做的。事实是，直到他们消失并在具有可怕的软件开发人员，糟糕的管理和糟糕代码的其他地方工作，他们才可能无法理解您在代码审查中解决的项目的真正原因。

到那时，他们将已经习惯性地学习了良好的做法，并且不得不度过别人犯的编码和设计错误，并且被迫使他们现在必须使用设计和实施不当的软件。

在他们职业生涯的某个时刻，这将是最终的必然。通过使它们习惯良好的编码标准和实践，可以为它们提供出色的服务。不幸的是，我们大多数人不得不学习艰难的方式。

根据给出的示例，我想说的是跟进您的问题并提出建议可能是最好的方法。如果您在提出问题的同时提出自己的意见，则不会让他们简单地同意或不同意，他们至少必须考虑如何实施某些措施。

例如：“我喜欢您创建扩展方法的想法，但我不喜欢如何将大型复杂的lambda作为参数传递。lambda迫使其他人对方法的实现了解得太多。您能想到一种更好的方法吗？实现这种扩展方法而不会暴露太多信息？”

这使他们可以看到正在开发的错误，同时使他们有机会解决他们引入到应用程序中的问题。