钩陈/ 解读:提问的智慧¶

普通老程序猿叕一则小结...

背景¶

参考: 蟒营™101.camp 开源网络课程框架...

大妈从99年开始自学各种技术, 到05年开始主动参与技术社区筹备, 已经隐隐发现自学的重要性; 再到09年开始尝试培训, 又9年各种尝试, 才敢在18年圣诞节正式上线 蟒营™Python入门班 , 准备应该算是充分的...

现象¶

但是, 绞尽脑汁儿设计的课程, 在运营过程中, 最大的困难竟然是:

学员不敢/不愿/不喜欢提问

都期待课程给部秘笈, 自己默默就能编程了...

分析¶

可是为什么呢?

毕竟编程是门手艺活儿, 过程中各种反直觉的经验, 必须通过交流才能确立的哪...

所以, 看看学员的感受?

"提问的智慧"我的解读版,VER.42,终极解读版.

元数据: pre 的时间,地点,时长,目的与要求,备忘...

20200106,北京,加入蟒营第5周,也是最后一周,完成第二项附加任务: 到底什么是蟒营™?之姊妹篇:什么是"提问的智慧"

pre 目标,要讲清楚的问题,想要达到的效果...

讲清楚蟒营三大核心元素:节奏,MVP,问好问题其中之一,也是蟒营的终极作弊条:提问的智慧

请先看提问的智慧原文

两位作者简介:

Eric Raymond

埃里克·雷蒙德(Eric S.Raymond)的主页
埃里克的个人倾向
埃里克的随笔:黑客与作家
埃里克·雷蒙德的常见问题集:一名Linux/Unix黑客,大多是关于Linux/Unix的问题

Rick Moen

瑞克·摩恩(Rick Moen)个人主页:Unix专家

瑞克·摩恩(Rick Moen)是旧金山湾区的Linux活动家,他因参加整个湾区的几乎所有Linux活动(或至少参加他的综合名单"湾区Linux活动"而闻名). Rick还是所有Bay Area Linux联盟的发起人,该联盟聚集了各个Bay Area Linux用户组. 一些Linux用户组已经开始用" Rick Moen会在那儿,对吗?"来宣传他们的活动.

信息清单:

本文的信息结构是:

作者们的价值主张
提问之前要做的事情
提问时的注意事项
如何解读答案
好问题的样子
如何回答问题

作者们的价值主张¶

我们不讳言我们对那些不愿思考,或者在发问前不做他们该做的事的人的蔑视. 那些人是时间杀手 --- 他们只想索取,从不付出,消耗我们可用在更有趣的问题或更值得回答的人身上的时间. 我们回答问题的风格是指向那些真正对此(技术问题细节)有兴趣并愿意主动参与解决问题的人,这一点不会变,也不该变. 如果连这都变了,我们就是在降低做自己最擅长的事情上的效率,让我们帮助那些不愿意帮助自己的人是没有效率的. 要求黑客个人无偿地帮助你,你必须表现出能引导你变得在行的特质 -- 机敏,有想法,善于观察,乐于主动参与解决问题. 如果你做不到这些使你与众不同的事情,我们建议你花点钱找家商业公司签个技术支持服务合同. 能立刻得到快速并有效答案的最好方法,就是像赢家那样提问 -- 聪明,自信,有解决问题的思路,只是偶尔在特定的问题上需要获得一点帮助.

上面是两位作者的价值主张,简单总结一下,他们倾向于回答那些主动参与解决问题的人提出的问题,他们把这些人称为赢家,赢家的特点是自信,有解决问题的思路,只是偶尔在特定的问题上需要帮助.因为他们是无偿回答问题,所以这是他们定的准入门槛,无可厚非.

作为提问者如何获得两位作者及其他黑客的无偿帮助:假装自己是一个聪明自信有解决问题思路的人,换句话说,就是自己能独立思考,愿意主动解决问题,而不是找个人替自己把问题解决.

找人替自己做的事情,都得花钱,价值就是这么创造的,社会也是这么运转的,想省钱,自己要么聪明点,要么会求助.

"你是靠提出有内涵的,有趣的,有思维激励作用的问题,自己去挣到一个答案,而不仅仅是被动的从他人处索取知识. "换句话说,问题的解决或者答案/知识的获取,都是主动参与的结果."你要表现出只要有人能指个正确方向,你就有完成它的能力和决心. " --手动右上角标↗1--

1.大妈曰:是也乎,(￣▽￣) 所以, 蟒营™课程指向的技能/习惯, 也是用学员自身的努力挣得的... 付费只能说获得一个机会...

提问之前要做的事情¶

在提问之前,请先做到以下事情: 尝试在你准备提问的论坛的旧文章中搜索答案. 尝试上网搜索以找到答案. 尝试阅读手册以找到答案. 尝试阅读常见问题文件(FAQ)以找到答案. 尝试自己检查或试验以找到答案. 向你身边的强者朋友打听以找到答案. 如果你是程序开发者,请尝试阅读源代码以找到答案.

也就是说,碰到问题时,如何像聪明者那样应对问题:

先从相关论坛中搜索旧文章,看看前人有没有碰到过类似的问题,他是如何解决的
第一步如果没能提供详细的信息,就从网上搜.很多人是一上来就从网上搜,个人经验先从垂直网站上搜,得到的可能更是你想要的.从信息论的角度解释这件事:从垂直类网站上搜比从搜索引擎上搜信息熵要低,也就是说,从垂直类网站上搜,不确定性低,命中效率高.对应到蟒营的学习上,就是有问题先搜issue,再搜ref,再搜wiki,然后是百度/搜狗/Google.--手动右上角标↗2--
阅读官方文档,网上资料良莠不齐,别人的环境可能跟你的不一样,写的也可能不详细,很容易被他带沟里去,这时看官方文档最保险.如果问题稍微复杂一点,不是随便一搜能解决的,就要坚决地看官方文档.
如果官方文档写得看不懂,或者省略的信息太多,再去看官方的FAQ,看看有没有人跟你遇到同样的问题,官方给出的答案永远是最靠谱的,是他们仔细衡量过的应对方案.
如果上面四步都没有获得自己想要的信息,就要自己试验了,用对照试验,改变一个变量,看结果,看看能不能得出答案.
如果自己搞不定,此时要坚决找身边的朋友求助,同样的错误步骤,试验再多次也得不出正确结果.求助的对象,从学习共同体里找最佳,例如蟒营.
牛逼的程序员还会直接看源码来理解错误逻辑,小白就忽略这条吧.知其然也知其所以然,肯定是解决问题最好的方式.--手动右上角标↗3--

2.大妈曰:是也乎,(￣▽￣) 高兴你不用中文标点符号; 只是, 这样一来, 和引用内容中的标点就不一致了... 触发一个有趣的实用小任务: 思考, 是否有可能用 Python 完成一个工具; 自动化对指定文本清除/替换所有中文标点为半角符号?

ps:这个可以有,只是不知道啥时候能写,下期复训的时候可以搞一下

3.大妈曰:那么你自己的理解? 现在 Pythonic 的思路是, 先可以不理解, 但是, 必须能用起来解决真实问题, 否则, 太多好东西, 没时间体验了...

ps:我还没有转过这个弯来,毕竟被教育了很多年"要知道为什么",总是尽可能地想全面地了解为什么.我当初写python代码时极不适应的一点就是:不定义变量类型,直接用;不定义函数返回值类型,直接用.

提问时的注意事项¶

慎选提问的~~论坛~~邮件列表

用搜索引擎找到最相关的~~论坛~~邮件列表发问,先看看 FAQ和已有的话题
搜索一下论坛,搜索引擎有可能没来得及索引此~~论坛~~邮件列表的全部内容,用标签(Tag)搜索能让你缩小搜索结果
即使没有搜索出答案,也能归纳出更好的问题
一般来说,在仔细挑选的公共~~论坛~~邮件列表中提问,会比在私有~~论坛~~邮件列表中提同样的问题更容易得到有用的回答

简单的问题应该搜索~~论坛~~邮件列表之前就解决了,复杂些的问题就得从~~论坛~~邮件列表里找答案--手动右上角标↗4--

4.大妈曰:是也乎,(￣▽￣) 这其实有个翻译的坑:论坛, 我们以为是 BBS,但是, 其实是 mailling-list

ps: 查了下 mailling-list:

官方解释:

Mailing list 可能是互联网上最古老的人际交流手段之一,但到现在仍然是最有效的互联网交流手段之一.
Mailing list 不比直接的人与人之间的email交流,发往 Mailing list 的邮件会分发到订阅了 Mailing list 的所有人的邮箱,这一特性使得交流的效率相当高.
试想想,如果一个论坛有一万人注册用户,可能只要一千人会经常上线,你发一个贴子,去查看的可能不到一百人,回答问题的,恐怕就只有三五个了.
而一个有几百个订阅者的 Mailing list ,一个"有趣"的主题可能引起几十封回复.

Stack Exchange community

Stack Exchange 已经成长到超过一百个网站,以下是最常用的几个站:
- Super User 是问一些通用的电脑问题,如果你的问题跟代码或是写程序无关,只是一些网络连线之类的,请到这里.
- Stack Overflow 是问写程序有关的问题.
- Server Fault 是问服务器和网管相关的问题.

网站和 IRC 论坛 - 在使用 IRC 的时候,首先最好不要发布很长的问题描述,有些人称之为频道洪水. 最好通过一句话的问题描述来开始聊天.

IRC(Internet Relay Chat的缩写,"因特网中继聊天")是一个位于应用层的协议,其主要用于群体聊天. 可以简单理解成slack或者微信群聊,通常可以得到及时回应

使用项目邮件列表

当某个项目提供开发者邮件列表时,要向列表而不是其中的个别成员提问,查一查项目的文件和首页,找到项目的邮件列表并使用它. (理由看原文)
如果一个项目既有"使用者" 也有"开发者"(或"黑客")邮件列表或论坛,而你又不会动到那些源代码,那么就向"使用者"列表或论坛提问. 如果你确信你的问题很特别,而且在"使用者" 列表或论坛中几天都没有回复,可以试试前往"开发者"列表或论坛发问
建议你在张贴前最好先暗地里观察几天以了解那里的行事方式,事实上这是参与任何私有或半私有列表的好主意
如果你找不到一个项目的邮件列表,而只能查到项目维护者的电子邮件地址,尽管向他发信. 即使是在这种情况下,也别假设(项目)邮件列表不存在. 在你的电子邮件中,请陈述你已经试过但没有找到合适的邮件列表,也提及你不反对将自己的邮件转发给他人

个人觉得这一条道出了提问的智慧的主旨,作者们也已经在上文中反复提到过,概括起来是一句很普通的话:找到合适的地方,找到合适的人,以合适的方式,提出合适的问题.

整理成提问清单:

找到合适的地方,看看是否有之前的文档可以解决问题,这是提问之前的准备工作里说的前5步,如果没有进行下一步
找到合适的人,或者是身边懂的朋友,或者是官方客服,或者是项目开发者
以合适的方式,合适的方式下面还会说明
提出合适的问题,最好先暗地里观察几天以了解提问地的行事方式,了解各种黑话或行话. 也就是说,用专业术语跟专业人交流(不懂的术语要去搜一下,不然说的可能是不一样的东西),这也可以避免问错人,或提出蠢问题.

或者,可以反问自己四个问题:

我找到可能解决我问题的地方了吗?
我找到可能解决我当前问题的人了吗?
我用什么方式向他提问能最快最好地得到我想要的答案?
我提出的问题在回答者看来对吗?是否跟回答者处在同一语境下?

使用有意义且描述明确的标题

50字以内的标题是抓住资深专家注意力的好机会,在这点空间中使用极简单扼要的描述方式来提出问题. 不要妄想用你的痛苦程度来打动他们.
一个好标题范例是目标 -- 差异式的描述,在目标部分指出是哪一个或哪一组东西有问题,在差异部分则描述与期望的行为不一致的地方. 编写目标 -- 差异式描述的过程有助于你组织对问题的细致思考. (详细案例看原文)
除非你只想在该讨论串当前活跃的人群中提问,不然还是起一个新的标题,重新提一个新的问题比较好

从信息论的角度解释一下这条建议就很容易理解了,标题能显示的部分有限(一行能显示的字数有限),所以需要用少数的字传递最大的信息量,用目标 -- 差异式的描述可以最好地做到在简短的字数之内提高信息量,降低冗余.--手动右上角标↗5--

5.大妈曰:是也乎,(￣▽￣) 信息论是个大坑, 推荐刷信息简史

列一下原文中的例子:

蠢问题:救命啊!我的笔记本电脑不能正常显示了!
聪明问题:X.org 6.8.1 的鼠标光标会变形,
    某牌显卡 MV1005 芯片组. 
更聪明问题:X.org 6.8.1 的鼠标光标,
    在某牌显卡 MV1005 芯片组环境下 
    -- 会变形.

第一个是情绪性标题,信息量很低,冗余度很高.换句话说,就是不确定性很高(未知的事情太多),容易引起人们的兴趣,这也是标题党通用的套路.但对于时间稍微有点紧的人来说,就非常反感标题党,因为标题信息量太低,得点开内容才能获得信息量.

单从信息量来看,第二个描述和第三个其实是一样的.但第三个句子更通顺些,别人读起来,认知资源消耗低,理解你的意思花的时间更短,所以第三种描述方式最佳.

使问题容易回复 - 在论坛,要求通过电子邮件回复是非常无礼的,除非你认为回复的信息可能比较敏感(有人会为了某些未知的原因,只让你而不是整个论坛知道答案). 如果你只是想在有人回复讨论串时得到电子邮件提醒,可以要求网页论坛发送给你. 几乎所有论坛都支持诸如追踪此讨论串,有回复时发送邮件提醒等功能.

用清晰,正确,精准并语法正确的语句 - 如果在使用非母语的论坛提问,你可以犯点拼写和语法上的小错,但决不能在思考上马虎(没错,我们通常能弄清两者的分别). 同时,除非你知道回复者使用的语言,否则请使用英语书写. 繁忙的黑客一般会直接删除用他们看不懂语言写的消息. 在网络上英语是通用语言,用英语书写可以将你的问题在尚未被阅读就被直接删除的可能性降到最低.

使用易于读取且标准的文件格式发送问题

使用纯文字而不是 HTML,同时没有一些奇怪的字符
不要发送一段文字只是一行句子但自动换行后会变成多行的邮件(这使得回复部分内容非常困难)--手动右上角标↗6--
~~绝对,永远不要指望黑客们阅读使用封闭格式编写的文档,像微软公司的 Word 或 Excel 文件等~~--手动右上角标↗7--

6.大妈曰:是也乎,(￣▽￣) 为什么回复部分?bottom-post 原则,参考: [邮件列表的规范和礼节:创造良性发展的交流空间](http://s5.zoomquiet.top/050730-usMaillist/index.html)

7.大妈曰:是也乎,(￣▽￣) 为什么? 你的态度?

ps:这些礼仪,没泡过邮件列表的人是不容易理解的;另外不用word或Excel,之前在Mac或Linux上打不开微软软件的情况下是可以理解的,毕竟看一封邮件谁也不想装一次系统.

精确地描述问题并言之有物

仔细,清楚地描述你的问题或 Bug 的症状.
描述问题发生的环境(机器配置,操作系统,应用程序,以及相关的信息),提供经销商的发行版和版本号(如:Fedora Core 4,Slackware 9.1等).
描述在提问前你是怎样去研究和理解这个问题的.
描述在提问前为确定问题而采取的诊断步骤.
描述最近做过什么可能相关的硬件或软件变更.
尽可能的提供一个可以重现这个问题的可控环境的方法. 尽量去揣测一个黑客会怎样反问你,在你提问之前预先将黑客们可能遇到的问题回答一遍. 以上几点中,当你报告的是你认为可能在代码中的问题时,给黑客一个可以重现你的问题的环境尤其重要. 当你这么做时,你得到有效的回答的机会和速度都会大大的提升

这条给人的启示是要想解决自己当前的困境,就先搞清楚自己当前的处境. 自己当前处境搞清楚之后,一是方便别人复现自己碰到的问题,另一个是自己或许也可以通过改变变量找到出路.

碰到问题时,可以对自己进行灵魂的拷问:--手动右上角标↗8--

我在哪,我现在的环境(处境)如何?
我从哪里来,我初始的环境(处境)如何?
我要去哪里,我该改变现在环境(处境)的哪些变量?
我做过哪些尝试,我已经改变了哪些变量,起到了哪些效果,排除了哪些可能?

8.大妈曰:是也乎,(￣▽￣) 其实, 这是通用拷问, 在任何场景中任何问题面前, 都应该准备好这些问题的答案先.

话不在多而在精

还是在强调信息量要足--手动右上角标↗9--

9.大妈曰:是也乎,(￣▽￣) 其实, 就是信息的纯度, 不包含形容词,情绪, 介词...所谓脱水版陈述.

别动辄声称找到 Bug

跟程序员打交道的基本社交礼仪

低声下气不能代替你的功课,取而代之的是,尽可能清楚地描述背景条件和你的问题情况

情绪和态度的信息量不足以解决当前的困境,需要给帮助者提供更多的环境信息才行

描述问题症状而非你的猜测 - 你要原原本本告诉了他们问题的症状,而不是你的解释和理论;让黑客们来推测和诊断. 如果你认为陈述自己的猜测很重要,清楚地说明这只是你的猜测,并描述为什么它们不起作用.

这条在看病的时候也格外重要,也许你的搜索能力比较强,在网上搜到了相应症状的名称,就告诉你的医生你得了某种病,这就跟学医的大三学生一样,有个词叫"大三学生综合征",讲的是大三学生学了一种症状就往自己的身上套,感觉自己得了很多的病,其实很多病都有些共同的症状,得去一个个排除,并不是有症状就一定得了某种病,也可能是休息不好累的.

找人求助的时候,判断的事情让专家去做,你要做的就是描述症状,提供足够多能做出判断的信息量.

这条也算是提问时的最最最基本的原则了:提供足够多的,能做出判断的信息量,搞清楚现在的状况后,没准自己也就知道该怎么做了. --手动右上角标↗10--

10.大妈曰:是也乎,(￣▽￣) 这其实就是提问时, 最反直觉的事儿了...多数问题本身就包含解决方案, 只是我们对问题本身的定义不够明确前, 反而自己看不到...参考: [创新算法 (TRIZ,系统创新和技术创造力)](https://book.douban.com/subject/3354596/)

按发生时间先后列出问题症状

问题发生前的一系列操作,往往就是对找出问题最有帮助的线索. 因此,你的说明里应该包含你的操作步骤,以及机器和软件的反应,直到问题发生. 在命令行处理的情况下,提供一段操作记录(例如运行脚本工具所生成的),并引用相关的若干行(如 20 行)记录会非常有帮助.
如果挂掉的程序有诊断选项(如 -v 的详述开关),试着选择这些能在记录中增加调试信息的选项. 记住,多不等于好. 试着选取适当的调试级别以便提供有用的信息而不是让读者淹没在垃圾中. --手动右上角标↗11--
如果你的说明很长(如超过四个段落),在开头简述问题,接下来再按时间顺序详述会有所帮助. 这样黑客们在读你的记录时就知道该注意哪些内容了

11.大妈曰:是也乎,(￣▽￣) 这其实在反向要求探索过程必须配合科学的记要... 问题是:如何记要/记要在哪儿/记要格式?/记要什么?

ps:你要避免的软件开发模式中提到,DDD(Debugger-Driven Development)合格的程序员的代码是一行行写出来的;不合格的程序员的代码是一行行调出来的. 多花时间思考和设计,使用 TDD(Test Driven Development),如果非要追踪状态,合理地使用日志(log)而非断点.

描述目标而不是过程 - 如果你想弄清楚如何做某事(而不是报告一个 Bug),在开头就描述你的目标,然后才陈述重现你所卡住的特定步骤. 经常寻求技术帮助的人在心中有个更高层次的目标,而他们在自以为能达到目标的特定道路上被卡住了,然后跑来问该怎么走,但没有意识到这条路本身就有问题. 结果要费很大的劲才能搞定.

就是xy问题

别要求使用私人电邮回复

跟程序员打交道的社交礼仪之赞赏篇

直截了当地表达你的问题以及需求

最有可能给你有用答案的人通常也正是最忙的人(他们忙是因为要亲自完成大部分工作). 这样的人对无节制的时间黑洞相当厌恶,所以他们也倾向于厌恶那些漫无边际的提问.
如果你明确表述需要回答者做什么(如提供指点,发送一段代码,检查你的补丁,或是其他等等),就最有可能得到有用的答案. 因为这会定出一个时间和精力的上限,便于回答者能集中精力来帮你. 这么做很棒.

直截了当,效果最好,你离问题的解决越近,越容易得到答案,因为别人要做的可能只是最后的临门一脚.

询问有关代码的问题时

最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例(bug-demonstrating test case). 什么是最精简的测试用例?那是问题的缩影;一小个程序片段能刚好展示出程序的异常行为,而不包含其他令人分散注意力的内容. 怎么制作最精简的测试用例?如果你知道哪一行或哪一段代码会造成异常的行为,复制下来并加入足够重现这个状况的代码(例如,足以让这段代码能被编译/直译/被应用程序处理). 如果你无法将问题缩减到一个特定区块,就复制一份代码并移除不影响产生问题行为的部分. 总之,测试用例越小越好. --手动右上角标↗12--
一般而言,要得到一段相当精简的测试用例并不太容易,但永远先尝试这样做的是种好习惯. 这种方式可以帮助你了解如何自行解决这个问题 --- 而且即使你的尝试不成功,黑客们也会看到你在尝试取得答案的过程中付出了努力,这可以让他们更愿意与你合作. --手动右上角标↗13--
如果你只是想让别人帮忙审查(Review)一下代码,在信的开头就要说出来,并且一定要提到你认为哪一部分特别需要关注以及为什么.

这条建议也能用信息论解释,跟之前的所有建议相反,不是要加信息量,而是要减信息量,也就是奥卡姆剃刀原则:如无必要勿增实体.

简单解释一下,如果解决你的问题只需要10条信息,而你一下子给了100条,其余90条没有实际效果,换句话说,这10条信息能达到的效果和100条是等价的,给多了反而会使问题看起来变得复杂,解决起来要耗费更多的时间,主要时间都用在过滤那些无用的信息上了,徒增工作量而没有实际产出.

12.大妈曰:是也乎,(￣▽￣)也就是 bug 的 MVP,一定是包含你的 bug, 而且是可运行的...否则, 没人有空从头构造你本地所有环境的...这其实, 也包含了一个隐藏的要求 -> 你的运行时环境必须是良好可用的

13.大妈曰:是也乎,(￣▽￣)其实, 这种 MVP 化 bug 本身, 就是对自己代码的重构...

ps:bug抽离调试重构大法

别把自己家庭作业的问题贴上来
去掉无意义的提问句
即使你很急也不要在标题写紧急
彬彬有礼,多用请和谢谢您的关注,或谢谢你的关照. 让大家都知道你对他们花时间免费提供帮助心存感激.

问题解决后,加个简短的补充说明

思考一下怎样才能避免他人将来也遇到类似的问题,自问写一份文件或加个常见问题(FAQ)会不会有帮助. 如果是的话就将它们发给维护者.
在黑客中,这种良好的后继行动实际上比传统的礼节更为重要,也是你如何透过善待他人而赢得声誉的方式,这是非常有价值的资产.

以上都是社交礼仪类建议.

如何解读答案¶

RTFM / STFW / Google 是你的朋友

自己查文档,在提问之前,请先把自己该做的事情做足. "自己去搜索这些信息比灌给你,能让你学到更多".

如果你看不懂回应,别立刻要求对方解释. 像你以前试着自己解决问题时那样(利用手册,FAQ,网络,身边的高手),先试着去搞懂他的回应. 如果你真的需要对方解释,记得表现出你已经从中学到了点什么. 比方说,如果我回答你:看来似乎是 zentry 卡住了;你应该先清除它.,然后,这是一个很糟的后续问题回应:zentry 是什么? 好的问法应该是这样:哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries,而且还都没有清楚的解释如何清除它. 你是指这两个中的哪一个吗?还是我看漏了什么?

这也是小白的无奈之举,毕竟自己不知道得太多,还是像"自己解决问题时那样(利用手册,FAQ,网络,身边的高手)",把专业术语补足吧. --手动右上角标↗14--

14.大妈曰:是也乎,(￣▽￣)那么问题来了, 这是在互联网中的礼仪, 在付费课程中呢?助教有义务指引你到对应官方文档的具体段落嘛?如果是英文看不懂, 课程有义务替你翻译嘛?翻译后还是看不懂, 课程有义务替你完成代码嘛?也就是说, 在学习过程中, 课程或是其它第三方助力的边界在哪儿?否则说, 这个边界和自身学习效能的关系是如何的?

ps:互联网中的礼仪其实是陌生人之间的礼仪,课程之间的礼仪更加偏熟人一些,自然应该对礼仪的要求要放宽一些,社会礼仪的设定本来就是为了避免陌生人之间不必要的摩擦设定的. 课程组的和自身学习效能的边界在哪,不同的人不一样(换句话说,就是看情况),即使是熟人之间也没有两个人的关系是相同的,所以边界也就不同,有的学生需要多帮一些,有些学生只需要指点一下,既然是小班,因材施教的难度应该小一些.

好问题的样子¶

我在 S2464 主机板上试过了 X , Y 和 Z ,但没什么作用,我又试了 A , B 和 C . 请注意当我尝试 C 时的奇怪现象. 显然 florbish 正在 grommicking,但结果出人意料. 通常在 Athlon MP 主机板上引起 grommicking 的原因是什么?有谁知道接下来我该做些什么测试才能找出问题?

通过我的提问方法,我给了别人可以咀嚼玩味的东西;我设法让人们很容易参与并且被吸引进来. 我显示了自己具备和他们同等的能力,并邀请他们与我共同探讨. 通过告诉他们我所走过的弯路,以避免他们再浪费时间,我也表明了对他们宝贵时间的尊重.
事后,当我向每个人表示感谢,并且赞赏这次良好的讨论经历的时候, 一个 Linux 内核邮件列表的成员表示,他觉得我的问题得到解决并非由于我是这个列表中的名人,而是因为我用了正确的方式来提问.
黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙;我相信他是对的,如果我像个乞讨者那样提问,不论我是谁,一定会惹恼某些人或者被他们忽视. 他建议我记下这件事,这直接导致了本指南的出现.

这条说明了这篇文章诞生的背景,同时也侧面印证了黑客们的价值观,以及专家级黑客是如何思考和解决问题的

如何更好地回答问题¶

对初犯者私下回复. 对那些坦诚犯错之人没有必要当众羞辱,一个真正的新手也许连怎么搜索或在哪找常见问题都不知道. 试探性的反问以引出更多的细节. 如果你做得好,提问者可以学到点东西 --- 你也可以. 试试将蠢问题转变成好问题,别忘了我们都曾是新手. 尽管对那些懒虫抱怨一声 RTFM 是正当的,能指出文件的位置(即使只是建议个 Google 搜索关键词)会更好. 如果你决定回答,就请给出好的答案. 当别人正在用错误的工具或方法时别建议笨拙的权宜之计(wordaround),应推荐更好的工具,重新界定问题. 帮助你的社区从问题中学习. 当回复一个好问题时,问问自己如何修改相关文件或常见问题文件以免再次解答同样的问题?,接着再向文件维护者发一份补丁.

毕竟谁都是从小白过来的,给后来的人一些引导也可以给自己减少点更多的麻烦. --手动右上角标↗15--

15.大妈曰:是也乎,(￣▽￣)所以, 小白时的状态非常珍贵, 毕竟几乎立即就会失去...就象处女时的心态... 所以, 一定要在自己是小白阶段多记录, 多提问,并将对应问题对小白而言最困难之处, 变成文档反馈给社区

ps:这个怕是非处女不能同意吧,(￣▽￣)

-------------¶

3. 给我的启示¶

什么是提问的智慧?

如果让我用一句话概括,就是从无知变成知道该怎么去做,换句话说,提问的智慧也就是找到方向的智慧.

本文中说的学习,提出问题,解决问题单指编程领域,迁移到其他领域可能会有些出入.

仅仅从提问这一行为本身看,"提问的智慧"主要是强调了两方面:

信息量要给足,但是不要给过,给少了时间多耗费在沟通上,给多了时间多耗费在缕清真正的问题上
跟程序员打交道要遵守基本的社交礼仪

由于作者都是大忙人,有非常多的工作要做,授人以鱼不如授人以渔,因此他们在教别人如何正确地提问时,顺带回答了两个更有价值的问题:

小白如何知道自己不知道的
小白如何像聪明的专家那样思考和解决问题

我就从上面四条出发,调整原文的信息结构,重新梳理一下信息清单里的内容.

两位作者都是unix黑客,也参加过很多活动,经常无偿回答一些技术问题. "提问的智慧"里,包含了两个前提假设:

大家都是大忙人,有很多工作要做,时间有限
大家都是聪明人,自己能做的事,不要丢给别人--手动右上角标↗16--

16.大妈曰:`是也乎,(￣▽￣)这点前提假设, 在网络课程中遇到的学员, 多数并不俱备;以往传统学校教育,目的就是打掉自信, 老实听从社会安排.所以, 大家都认为自己不够聪明,所以, 不成功, 所以要上课来补.这导致行动僵直, 不敢,或是习惯不探索...甚至于, 自己能作什么, 都没有好奇来探查了...

16.ps:这可能是社会阶层决定的,平心而论,中国的教育跟世界其他国家做的相比,已经可以做到世界前列了.至于它造成的副作用,只能看个人造化了,如果愿意继续学习,就能冲破这层玻璃顶.比如我参加蟒营之后,就更加自信了. `

因此,他们"愿意帮助那些真正对此(技术问题细节)有兴趣并主动参与解决问题的人,这些人机敏,有想法,善于观察,乐于主动参与解决问题,只是偶尔在特定的问题上需要获得一点帮助. "

换句话说,问题的解决或者答案/知识的获取,都是主动参与的结果. "要表现出只要有人能指个正确方向,你就有完成它的能力和决心. "这样更容易获得别人的帮助.

提问时的注意事项,跟信息量相关的:

使用有意义且描述明确的标题
精确地描述问题并言之有物
话不在多而在精
低声下气不能代替你的功课,取而代之的是,尽可能清楚地描述背景条件和你的问题情况
按发生时间先后列出问题症状
描述目标而不是过程
询问有关代码的问题时

提问时的注意事项,跟社交礼仪相关的:

网站和~~IRC论坛~~--手动右上角标↗17--
使用项目邮件列表
使问题容易回复
用清晰,正确,精准并语法正确的语句
使用易于读取且标准的文件格式发送问题
别动辄声称找到 Bug
描述问题症状而非你的猜测
别要求使用私人电邮回复
直截了当地表达你的问题以及需求
别把自己家庭作业的问题贴上来
去掉无意义的提问句
即使你很急也不要在标题写紧急
彬彬有礼,多用请和谢谢您的关注,或谢谢你的关照. 让大家都知道你对他们花时间免费提供帮助心存感激
问题解决后,加个简短的补充说明

17.大妈曰:是也乎,(￣▽￣)IRC 门槛太高, 可以放弃...在中国网络中 qq/wx 已经替代了 IRC

小白如何知道自己不知道的:

提问之前要做的事情
慎选提问的论坛
Stack Exchange community
使用项目邮件列表
RTFM / STFW / Google 是你的朋友

小白如何像聪明的专家那样思考和解决问题:

作者们的价值主张
提问之前要做的事情
精确地描述问题并言之有物
按发生时间先后列出问题症状
描述目标而不是过程
询问有关代码的问题时
好问题的样子

作者们花了很多笔墨在社交礼仪上,这说明虽然黑客不看重钱,尊重和价值感对他们来说还是很重要的,关系搞对了能省却很多烦恼,尽量别让"他人帮你"这事是一件在情绪上输出很大的事. 社交礼仪的运用,是让你的问题不被讨厌,从而增大被回答的概率,不要妄想别人会因此而喜欢你,这个心态摆正了,就更明白社交礼仪要怎么去做了. 符合上文提到的两个前提假设,即紧抓时间和主动两点,基本不会犯大错. --手动右上角标↗18--

18.大妈曰:是也乎,(￣▽￣)关键点是尊重,问题在相互尊重.如果你对自己的问题没有足够尊重, 那么跪求什么的姿势是自然发生的了...所以, 一个好问题的出发点, 就是对自己的问题足够认真, 并证明这种认真

礼仪过关了之后,就要提供充分必要的信息量了,充分是指环境信息量要足够下判断,情绪对解决技术问题信息量是最低的;必要是指冗余信息别提供太多,只提供跟目标,问题有关的信息. 作者们介绍的具体技巧都可以用信息论解释,可以往上翻信息清单一章,看我给的解释. 了解这一原理,提问会高效很多,甚至缕清问题后自己就可以解决了.

不过让我更感兴趣的其实是跟小白有关的问题,我经常学一些新东西,所以我经常会处于一种状态,那就是:懵逼,当我打出这两个字的时候,我发现它极其准确地描述了:我不知道自己该干什么,甚至都不知道自己不知道什么,连该怎么搜,甚至搜什么都不知道的状态. 作者们给出的解决方案是什么呢,答案还是那个字:搜. --手动右上角标↗19--

不知道搜什么怎么办?两种方法,第一逛垂直类网站,看里面的旧文章,说不定能找到线索,也可能直接解决问题;第二,就是不停地搜,不断调整跟我们目标接近的关键词,这里要注意一点,搜关键词要比搜句子命中率更高一些,实践经验. 当然也有算法和信息论支持,两个关键词正好,一个噪音太多,三个有时会啥都搜不出来,信息量太多了.

小白解决无知的两大法宝:官方文档和搜索引擎. 即RTFM大法和STFW大法. 既然是小白,说明遇到的问题前人早就遇到过了,答案都是现成的,关键是提出一个好问题.

19.大妈曰:

>> 懵逼
- 这个关键状态词选择的好..
- 只是, 分析还不够:
    - 懵 -> ignorant/uneducated/boorish -> 僵住 <- 被百万种可能性吓住了
    - 逼 -> bigger -> 对 懵 状态的加强
    - 合起来就其实说明几个结果:
        - 自己认定自己无法理解
        - 对这种认定深入灵魂
        - 导致无法进行任何尝试
- 可其实并不一定:
    - 多数这种状态的触发都发生在:
        - 输入/抄录一些代码
        - 一运行
        - 出来一大堆红色警告
    - 而警告都是英文, 自己看都不敢看...
    - 但是,真的直面细读就能用自己积累的英文知识看明白:
        - 99% 信息对当前自己是无用的
        - 而那 1% 精确提示具体哪行哪个字母周围出了问题
            - 以及问题性质是什么
            - 基本就可以定位到具体问题代码
    - 然后, 就自然能发现
        - 问题都是自己造成的
        - 解决问题根源 -> 探索/探查/实验/搜索/理解 自己写的代码
        - 自然就知道如何处置了...
问题在:
    - 一开始, 这种工程化的
    - 问题定位/分析/分割/逐步调试/...
    - 这种经验没有时
    - 想象中调试就象念魔法咒语一般不可理解和尝试
    - 自然就 懵逼 了

所以, 触发一个最深层的 SM:
    - 42小时以内
    - 使用 Handbook 模板, 发布 Issue 分析
    - [FAQ] 代码调试的 MVP 经验
    - 说明:
        - 什么是调试
        - 如何开始调试
        - 调试中最常用的技巧是什么
        - print 如何使用最舒服
        - 自己调试经验中, 最神奇的一刻是什么?

解决了无知,小白如何进阶呢?如何像聪明地专家那样思考和解决问题?这就提问的智慧的精髓了,回到这一章的开头,我说提问的智慧就是找到方向的智慧,专家比小白强的就是知道路怎么走,坑他都踩过了,没踩过的他也能沉着应对,解决问题的方法是近似的,只是待解决的对象不同,另外真到需要帮忙的地方,他也知道要如何求助. --手动右上角标↗20--

20.大妈曰:是也乎,(￣▽￣)参考俺反复展示过的,其实, 专家并不比小白知道的更多, 只是探索效率在逻辑思维支持下, 更加高效而已:

当你处于懵逼的状态,发现没有了方向的时候,可以在心中把自己当成专家,然后虚拟出这么一个人,他跟你碰到了相同的问题,我要怎么帮助他?没错,你要通过提问,一步一步帮他找出方向.

结合"提问的智慧",我整理了一份关于提问的清单,也就是关于提问的IDD,从小白到专家的金手指:

[ ] 我的目标是什么?我清楚我的最终目的是什么吗?
- [ ] 更高级的是我当前的解决方案是服务于最终目标的吗,它真的是一个需要解决的问题吗?
[ ] 我找到可能解决我问题的地方了吗?
- 先从相关论坛中搜索旧文章,看看前人有没有碰到过类似的问题,他是如何解决的
- 第一步如果没能提供详细的信息,就从网上搜
- 如果问题稍微复杂一点,不是随便一搜能解决的,就要坚决地看官方文档.网上资料良莠不齐,别人的环境可能跟你的不一样,写的也可能不详细,很容易被他带沟里去,这时看官方文档最保险.
- 如果官方文档写得看不懂,或者省略的信息太多,再去看官方的FAQ,看看有没有人跟你遇到同样的问题,官方给出的答案永远是最靠谱的,是他们仔细衡量过的应对方案.
- 如果上面四步都没有获得自己想要的信息,就要自己试验了,用对照试验,改变一个变量,看结果,看看能不能得出答案.
- 牛逼的程序员还会直接看源码来理解错误逻辑.
[ ] 我找到可能解决我当前问题的人了吗?
- 如果自己搞不定,此时要坚决找身边的朋友求助,求助的对象,从学习共同体里找最佳.
- 试着找一下官方的客服
- 查一查项目的文件和首页,找到项目的邮件列表并使用它
[ ] 我用什么方式向他提问能最快最好地得到我想要的答案?
- 邮件,微信,电话,面基?注意必要的社交礼仪.
[ ] 我提出的问题在回答者看来对吗?我该怎么提问?
- 提出合适的问题,最好先暗地里观察几天以了解提问地的行事方式,了解各种黑话或行话. 不懂的术语要去搜一下,不然说的可能是不一样的东西
描述问题时,可以对自己进行灵魂的拷问:
- [ ] 我在哪,我现在的环境(处境)如何?
- [ ] 我从哪里来,我初始的环境(处境)如何?
- [ ] 我要去哪里,我该改变现在环境(处境)的哪些变量?
- [ ] 我做过哪些尝试,我已经改变了哪些变量,起到了哪些效果,排除了哪些可能?

如果用一句话概括的话:根据目标,找到合适的地方,找到合适的人,以合适的方式,提出合适的问题,然后找到方向. 这就是我对"提问的智慧"的理解. --手动右上角标↗21--

21.大妈曰:是也乎,(￣▽￣)最后的总结非常工程化, 而读起来气势很足 ;-)最后 IDD 应该每一阶段, 追加上时间限制建议, 不然, 很容易用正确的过程, 以无限的时间, 将自己的心力耗尽...

ps:加时间限制这个暂时还做不到,现在就是拿时间硬怼,怼累了就求助,要不就明天继续怼

ref:¶

Logging¶

用倒序日期排列来从旧到新记要关键变化

20200107 根据大妈的反馈修改用时:0215+0205
20200106 整理,输出用时:0103+0022+0233
20200105 整理,输出用时:0100+0050
202001004 阅读原文用时:0107+0120
20200103 阅读原文用时:0110+0056
20200102 init,了解作者用时:0049+0052
200106 shankai init

NN 4002

好文笔,感叹号年度配额: 1/3

投稿/反馈邮箱:

askdama@googlegroups.com

(邮件列表地址, 当成正常邮件发送邮件就好, 不用注册, 不用翻越...)

ZoomQuiet/大妈

就是四处 是也乎,(￣▽￣) 的那个大妈:


私自嗯哼: ZoomQuiet (订阅号: ZoomQuiet42)
公开课程: 蟒营 (订阅号: Mainium)
历史吐糟: Chaos42 (订阅号 PythoniCamp)

as 核心组织者:
    PyChina (订阅号: PyChinaOrg)
    本地社区: 
        GDG珠海 (订阅号: GDG-ZhuHai)
        TFUG珠海 (订阅号: ZH_TFUG)