其他 《提问的智慧》
提问的智慧
艾瑞克。史蒂文.雷蒙德（Eric Steven Raymond）
https://github.com/ruby-china/How-To-Ask-Questions-The-Smart-Way/blob/master/README-zh_CN.md
这是一篇长文，看完需要十几分钟的时间。如果之前没有认真看过并且思考过，这十几分钟会改变你的职业生涯。这文章可能会出现一些让人不适的词语或者过时的例子，但我认为这不会影响它要表达的内容，而你需要好好琢磨作者的思想。
《提问的智慧》是一个敲门砖，它把黑客间的礼仪和准则明白地写下来，让我们了解到一个事实，为什么那些看起来很牛的人几乎从不提问。其实他们也有问题，但是通常在提问之前就自己解决了。不是因为他们本来就牛，而是解决问题的经历让他们成为牛人。最终，你只会看到网络上多了一篇文章：关于解决 XXX 问题的方案。
要不要花十几分钟改变自己的人生，决定权在自己。
其它：
X-Y Problem http://coolshell.cn/articles/10804.html
说句题外话，这种现象的另一个原因是一些无趣的问题也有很多回答者。可能这确实是出于好心，但也会让提问者觉得发个帖子求助才是最有效率的解决方式。有时候，人之恶在于好为人师。
我不同意 人之恶在于好为人师 这句话，有经验的人一句话的确会节省别人的很多时间，问题在于“问”和“说”的人是不是快速的定位和解决问题，“话过三巡”就显得烦了。
@liwei78 我说这话只是针对一些没经过自己思考就求答案的提问者，但往往这类问题总有大批的回答者。从短期来说，这是快速解决了别人的问题。但从长期来说，会让人失去独立思考的动力。所以不见得是帮助。
论坛是讨论问题的地方，每个人都希望从讨论中获得他人的观点，弥补自己的不足。虽然论坛也有解决问题的功能，但无疑 StackOverflow 和 SegmentFault 是更合适的地方。因为它们给好的问题更多出头的机会，给回答者更多的奖励和权限，这点对提问者和回答者都更有帮助。
话说你是否中枪并不重要，重点是人家的确给指了一条光明大道，你若是回一句“受益匪浅”并试着做一做，任谁也不会说你什么了。
大过年儿的压岁钱没少收吧？灵劲儿都哪儿去了？
赞同
其实更广泛一点 不学会解决问题的方法 不会从初级程序员水平毕业 现在伸手党太多了 有些人连搜索一下都想省了 很多人遇到问题 就直接上来扔问题 自己都没思考过 而且大部分问题 Stack Overflow 是能解决的
社区主要是探讨 探讨要建立在思考和研究的基础上 当然我觉得偶尔吹吹逼也挺好的
很好的文章，文章中的内容其实也是我们日常工作中常做的事。 我们可以学习别人优秀的观点，但个人觉得不要以此作为对待其它人的行为准则，我们总不能要求别人的想法会和自己一样甚至更进一步。
偶尔看到一些注册 2、3 年的帐号，依然还在问些无趣的问题
我有种身中核弹的感觉，仿佛说的就是自己……好在现在看文档和 google 基本能解决我遇到的问题
nice，虽然现在并非在做 ruby，但对于回答问题和楼主一样深有体会，很多新手遇到问题第一想到的就是问，而不是分析问题和进行验证，似乎直接在某个论坛发个帖子就什么都会 OK
l used to typing "thanks advanced" before l read this article , but now , l will write "thanks for attention"....LOL....
Unknown action The action 'create' could not be found for LandInfosController 在 LandInfosController 中已经定义了 create 动作为什么还是找不到？使用 debug 发现完全没有运行 create 中的代码？ 网上有人说是个小 bug。。如果是 bug 那怎么解决呢？关了重启好像还是不行。。。这样不是不能新建。。汗？？
前几天在读「提问的智慧」的时候，整理了一份思维导图，分享。
常读常新，补充点儿小内容～
提问之前
先尝试自己用以下方式来解决问题：
搜索论坛或邮箱的存档文件。
搜索互联网。
阅读用户手册。
阅读 FAQ。
仔细检查或实验一下。
请教专业的朋友。
假如你是程序员，尝试阅读源代码。
谨慎选择论坛
不去主题不相关的论坛提问
不去高手论坛贴新手问题，或反过来，也不去新手论坛帖高手问题
不同时去太多不同的新群组提问
不单独发 email 或微信向一个你不认识或没有义务为你解决问题的人提问
程序员论坛推荐
问题描述
- 运用有意义且明确的标题
- 认真且清晰地描述你遇到的问题或 bug
- 描述问题发生的环境，比如设备型号、OS、应用或语言的版本号，以及相关的文件。
- 描述之前尝试解决问题而做过的研究，在你提问前搞懂你的问题。
- 描述之前尝试的诊断步骤，在你提问前自己先说清楚问题。
- 描述可能相关的电脑或软件设置的近期更改。
- 如果可能，在可控环境下提供一种方式来重现问题。
