本文翻译自https://redd.one/blog/how-to-ask-questions
作为一名软件工程师，你经常需要实现现实世界的功能并修复棘手的漏洞。有时你可能觉得自己缺乏知识，或者不确定如何完全处理任务。这是完全正常的，即使是最有经验的工程师也会偶尔遇到困难，没有人真正知道一切，尽管他们可能看起来很聪明。寻求帮助（以及提供帮助）是编程不可或缺的一部分，就像编写代码或进行代码审查一样。然而，提问本身就是一门学问，需要一些时间学习如何以较少的投入获得更多的成果。
提问即学习#
我知道害怕或羞于提问的感觉，担心你的同事可能会认为你智商或者技术水平较低，对你提出他们认为显而易见的问题皱眉，甚至欺负你，要求你现在应该已经知道答案。如果你感到所处的环境不鼓励提问，那么你可能处于一个很差的环境中，需要尽快离开。那些瞧不起兴趣、实验和提问的人，很少是聪明人，因为他们阻止自己和他人获取知识。知识来自学习，而学习来自提问。确保你与那些理解这一点的人一起前行。
然而，如果你在寻求帮助时感到害羞或不自信，我有一个小窍门给你：不要把你的问题看作是你不知道某件事情的标志，而应该把它看作是想要学到更多的标志。在我看来，提问是学习任何领域最有效的方式。通过这种方式，你可以在提问这门伟大的艺术中取得进步，并且更有可能记住答案，因为我们最容易记住自己亲身经历过的问题的解决方案。
💡 不要剥夺自己最好的学习方式：提问。
提问的伟大艺术#
提出正确问题的技巧非常难以掌握。然而，如果不去实践并关注那些让你更接近答案的细节，你是不会变得更擅长提问的。这个话题值得一本厚厚的书来探讨，但现在让我们探讨提问中最常见的问题之一：具体性。
问题的具体性通常是模棱两可的，既可能让你更接近答案，也可能让你离答案更远。让我们来看看为什么会这样。
无关的具体性#
这里有一个问题的例子：
如何在 React 中在页面刷新时保持来自谷歌的身份验证令牌？
虽然这可能是一个有效的问题，但它包含了太多在回答问题时没有用的细节。例如，不要将身份验证过程绑定到谷歌，而是考虑询问关于通用身份验证持久性的问题。因为对于谷歌、亚马逊或其他任何提供商，在这方面的情况大致相同。不要将答案限制在 React 生态系统内，而是尝试从问题中去掉框架，以了解 JavaScript 中的持久性。这样，你得到的答案更有可能被其他框架和库复用，使其更有价值。最后，当涉及持久性时，保持身份验证令牌、唯一 ID 或任何类型信息的重要性很小。即使是问题中的 “身份验证” 部分也可以用 “如何保持数据” 来替换，任何数据。
虽然你所处的背景可能很重要，但往往放弃它有助于找到一个最终会引导你找到正确答案的线索。
💡 提问就是调查：你找到线索，引导你提出更具体的问题，最终找到答案。
当你需要把一个红色的球体变成一个蓝色的尖锐立方体时，不要指望立刻找到解决这个任务的方法。首先学习如何将球体变成立方体，然后学习如何使任何立方体变成蓝色，最后学习如何使蓝色物体变得尖锐。任何编程任务都可以分解成一系列较小的任务，从长远来看，研究这些任务将是一个更有价值的过程。在这个过程的中间，你可能会意识到你甚至不需要让立方体变尖锐。
我强烈建议从问题中去掉背景的原因是，这样可以让你更有机会找到答案。这也会让你明白一个问题很少有唯一的直接答案。开始时可以从宏观方面入手，随着你逐渐发现的每一个知识点，逐渐缩小到具体的细节。你会惊喜于通过这种方式学到的东西有多少。
相关的具体性#
提供包括库名称、浏览器版本或特定选项名称在内的技术细节可以帮助缩小调查范围，让你更接近答案。但是，在提供这些信息时，有一件重要的事情：你必须知道哪些是相关的。
看看这个问题：
Axios 在 componentDidMount 中的 POST 请求失败。
评估这些技术细节的实用性完全不可能，因为它们可能既相关又无关，这取决于特定的用例。提问时知道包括什么，和省略什么，就成了你的责任。说实话，这是提出正确问题的难点之一，也是随着时间和实践而获得的技能之一。
💡 在包括技术细节时，你必须知道什么是相关的，什么不是。
不幸的是，提到无关的细节可能会使你的调查工作偏离轨道。幸运的是，如果你询问的人熟悉这个话题，他们可以帮助你根据相关性筛选这些细节。
随着时间的推移，当你不断提问时，你会开始注意到某些技术细节对你来说变得非常重要，而其他一些则逐渐变得不那么重要。关于这点，我没有其他更高明的建议，只是鼓励你继续提问！
15 分钟规则#
在提问时应该小心，不要养成把问题交给别人的习惯。虽然在绝境中寻求帮助是应该做的事情，但我们都不喜欢挣扎。因此，当我们期待已久的帮助终于到来时，我们自然会感到满足和欢喜。为了让这种帮助持续更长时间，试着在提问之前学会评估情况。这可以防止不必要的问题，并给你一种独立完成的感觉。
💡 最后，期望答案的质量与你愿意花费寻找它的时间成正比。
在我的职业生涯中，采用 “15 分钟规则” 对我非常有帮助。每当我发现自己陷入困境时，我就会专注地花 15 分钟时间自行解决当前问题。到时间结束时，我会检查我所提的问题是否仍然相关。如果不再相关，我会用另外 15 分钟处理接下来出现的问题。只有在我的努力证明无果时，我才会向同事或其他开发人员提问。
这个规则非常有用，因为它可以增加你问题的价值。在尝试解决问题的过程中，你通常会学到一两个知识点，即使没有找到答案。你所获得的知识和尝试过的方法，可能会帮助你未来的 “顾问”，也就是帮你解决问题的人，更准确地解决你的问题。同时，你在解决问题中的努力，也为得到他人理解和同情的回应奠定了基础。
耐心#
软件工程可能会让人感到压力：由于某个问题导致客户失去收入，经理对错过的截止日期愤怒 —— 我们都经历过。压力并不能真正解决这些情况，也不能找到问题的答案。
请记住，解释问题和提出正确的问题同样困难。花时间帮助你的人可能会努力寻找最合适的方式来向你传达答案。在这个过程中，耐心和善良至关重要。
帮助他人#
无论你认为自己有多么缺乏经验，总会有一个人比你落后一步。那个人正走着与你类似的道路，但他们可能还没有完全理解你已经掌握的某些概念或模式。下次当你看到有人对你觉得非常明了的话题感到困惑时，请帮助他们。
💡 提供帮助与寻求帮助同样有用。
无私奉献并不是帮助他人的唯一原因。最佳的确认自己是否真正理解了问题的方式，也许就是通过解释这个问题来实现。因为我们每个人的思考和记忆方式各不相同，一开始向需要帮助的人传达你的想法可能会很具挑战性。有时候，这需要你验证自己所学到的知识，以免给出错误或不完整的答案。这可能会帮助你发现自己知识中的一些盲点！
得出结论#
得到答案当然很有成就感，但请尝试将其记在脑海里。问题并不是一个燃烧的炉子，一个接一个地抛出答案并无益处，因为提问的目的是学习。从答案中获取有价值的信息可能需要回顾原始问题并得出结论。问题的原因是什么？解决方案是什么？解决方案是直接还是间接影响了原因？在解决这个问题时，还有什么补充知识可以帮助吗？
学习本身就是一项技能，因为我们所有人学习、记忆和解释事物的方式都截然不同。既然如此，为什么不在答案已经掌握的情况下提高另一项技能呢？尝试找到最适合你的学习方式，无论是画图、编写简短的文档，还是在书签中收藏有用的链接。下次有问题出现时，这个宝库是开始使用 15 分钟规则的好地方！