如何在没有“为什么”作为答案的情况下问程序员一个问题

我们都有这种经验。您去找一个知道答案的人，问那个人这个问题，他们会以典型的回答回答：“为什么？” 您解释了为什么需要知道，他们试图解决您的问题。

将对话引导回原始问题并获得该死的答案需要时间，手臂弯曲和耐心。

为什么程序员会不断地这样做，为什么程序员变得越高级，行为就会变得更糟？

您如何以最有效的方式向程序员提出问题，以提取原始问题的答案？

当有人问他们如何实施解决方案时，为什么开发人员会问“为什么”？

因为与实际实施解决方案相比，评估解决方案是否需要更多的知识。

当某人说“我不知道如何做到这一点，但我确定这是我需要做的”时，很难相信他。程序员一直坚持要进行更深入的探索，因为人们总是坚持要求提出错误的问题。是的，有时最终会回到您原来的问题，但并非总是如此。

打个比方，想象一下是否有人走上机械师并问他如何更换汽车电池。通常，如果您有资格诊断有缺陷的电池，则有资格更换电池，因此技工将询问您如何知道需要更换电池。

他知道他是否不这​​样做，事实证明您不需要电池，然后您将不断提出更多问题，直到最终您发现必须在发动机熄火时关闭电灯。没有运行。通过事先询问您，感觉就像他在浪费您的时间，但实际上他从经验中知道他有可能为你们俩节省更多的时间。

因此，如果您想避免质疑，您需要先说服他知道您在说什么。

“问题特别是，一个人如何与另一位程序员互动，提出一个问题，另一个人给出答案，并跳过有关为何提出该问题的辩论。”

您不能，至少不是确定性的。另一个程序员是一个人，而不是计算机，而不是您的仆人。如果您问他们一个问题，他们会选择他们认为是最佳答案的方法。如果他们认为自己需要更多背景信息，那么他们会提出要求。

您可以尝试在声明中加入一个问题，即您只是在寻找简短的底线答案，但是他们仍然可以自由地回答，因为他们认为最好。

问题特别是，一个人如何与另一个程序员互动，提出一个问题，另一个人给出答案，并跳过有关为什么提出该问题的辩论。

你不能 程序员，特别是优秀的程序员，被接线以解决问题并提高效率。当客户或其他程序员来寻找答案时，他们将在提出解决方案之前确保知道他们正在解决的问题。这样，他们就会高效（他们不会通过给出不能解决您的问题的答案而浪费您和他们的时间），而他们正在解决实际的问题（通过为您提供您应该提出的问题的解决方案/答案）。

示例-当客户来找您说要实施X功能时。有时客户确实需要X功能，有时您确实必须深入挖掘并询问客户，以发现他们不需要X而是完全不同的东西。程序员越老，越有经验，他们越有可能在提出解决方案之前不去关注问题的核心而被烧掉。

因此，总结一下-如果您想精确地回答问题，则需要确保自己：

• 问正确的问题（因此，您需要事先研究问题）
• 提供问题的背景
• 分享一些您正在研究的内容，以便更快地引导他们解决问题

我认识的大多数人只是人类，而不是计算机。如果您只想要答案，请尝试使用Google搜索。

为什么程序员会不断地这样做，为什么程序员变得越高级，行为就会变得更糟？

不幸的是，它与一般事实相去甚远。

这种行为仅限于少数真正好的行为。而且您最好也应该学习它。

只需回答该死的问题，跳过为何原因，便是进入鸿沟，快速而确定的好方法。

如果您确实想跳过受过良好教育的部分，则可以在问题上加上几句关于局限性和跳过问题的愿望的前缀—您可能会得到一些答案，或者只是被发送出去。总结您自己的研究是一个更好的主意。

这里的每个答案都是对“为什么”问题的很好答案，但是没有人真正回答过OPs问题。

您如何以最有效的方式向程序员提出问题，以提取原始问题的答案？

答案非常简单：告诉他们为什么需要这样做，然后再问他们如何做。

最好的做法是让开发人员参加有关产品的更高级别的会议-为他们提供更大的概览，以便他们了解为什么需要执行此特定操作。他们甚至可能会给您一个“第一”的惊喜。

优秀的程序员不只是想要实现任何解决方案，还需要更多的信息。他们希望针对特定问题实施最佳解决方案。这需要信息。问题是收集信息的方式。在没有所有信息的情况下，程序员知道他处于实施不能满足所有要求的解决方案的危险之中，并且将不得不再次这样做。不要向程序员隐藏信息。隐藏信息会浪费时间，破坏士气并导致劣等的解决方案。

程序员“硬连线”以解决问题。

优秀的程序员将尝试解决“正确”的问题。

仅提供某人的要求通常会解决错误的问题。

在MS Office自动化风靡一时的情况下，通常会在几周的时间里出现一系列问题，询问如何在一个Office产品中执行“ this”，然后在其他产品中执行“ that” ，然后在另一项中再进行其他操作。每个问题都可以迅速解决，但是“问题”（尚未完全阐明）尚未解决。他们不断回来寻找链中的下一个“链接”。

如果您阻止他们，问他们“为什么？” 然后他们必须回溯并更广泛地解释他们想要实现的目标，而不仅仅是在他们面前立即描述问题。（顺便说一句，程序员遭受的痛苦与其他人一样多（如果不超过），像这样的论据承受的痛苦也是如此。）
用户链“将大数据库中的数据获取到Access，然后输入Excel进行处理，然后再输入Word，以便他们可以将邮件合并结果并每周通过电子邮件发送给人们”，很快就被替换为批处理作业，做所有这些结果一星期一早上就放在人们的收件箱中，而无需人工参与。

用户数 喜欢这一点。

在为您提供到达目的地的最佳方法之前，我们需要知道您要到达的目的地。

或者，（用Monty Python解释）：“您想要5分钟的答案还是整个半小时？”

当您只想知道用一个小数点后三位的数字来输入某个特定函数的所有细节时，程序员就无济于事了。

了解您的观点通常可以从根本上改变您获得的答案。

最后一个问题是“如何以最有效的方式向程序员提出问题，以提取原始问题的答案？”

首先您要混淆“有效”和“有效”。为了提高效率，只需写下“答案是什么？” 在一张纸上，并显示给程序员。这是提出问题的非常有效的方法。它也很难获得答案。

其次，您假设软件开发人员是问答者。他们不是。他们是解决问题的人。您的态度清楚地表明您不了解解决问题的方法。解决问题的最有效方法是将问题理解到可以描述给问题解决者的程度，然后将其呈现给问题解决者。另一种方法是尽可能多地理解问题，然后向问题解决者提出您不完整的理解，问题解决者将首先询问您所担心的问题，以将其转变为完全理解的问题，然后加以解决。

一种非常低效的方法是您尝试使用的方法：对问题不完全了解，猜测如何解决该问题，并向问题解决者询问如何实现此解决方案。问题解决者以前已经看到过这种行为。如果他没有经验，则为10倍；如果没有经验，则为1000倍。因此，问题解决者知道您正朝着完全错误的方向前进。问题解决者会做些什么才能朝着正确的方向前进，即问问题以了解实际问题。第一个问题是要了解您对问题的不完全理解，第二个问题是要了解实际问题。

通过明确说明您要实现的目标以及正在使用的上下文来开始问题。如果提供足够的上下文，您将不会得到“为什么？” ，您将获得一个 “这真的有必要吗？”

因为从统计上讲，大多数提议的功能很烂，因此不值得麻烦实施。

一个典型的反驳是“但这是他的工作”。 他的工作是编写良好的代码，并且添加功能通常与此相反，因为大多数功能都需要重新设计工作代码库以及这种“重新设计的东西”：

1. 永远需要
2. 添加新的错误
3. 破坏了曾经有用的东西
4. 使维护不可渗透

那不是好的代码，好的代码很少。