本文共 12957 字，大约阅读时间需要 43 分钟。

原文 。作者Raymond（ESR）是《大教堂与集市》的作者，著名的黑客，开源先驱。他在 2001 年第一次发布《提》后一直对此文进行着更新维护，大学时我曾读过这几本书，其对我后来的职业生涯产生了重要的影响。

下面按照原文章节进行注解，标题即原文章节标题。再次说明，我仅仅是注解了《提》中的部分内容，有时间的话请一定要看原文。

声明

该小节 ESR 建议项目维护者在用户指南文档的显著位置标注：

本指南不提供此项目的实际支持服务！

我们已经深刻领教到少了上述声明所带来的痛苦。因为少了这点声明，我们不停地被一些白痴纠缠。这些白痴认为既然我们发布了这本指南，那么我们就有责任解决世上所有的技术问题。

虽然看上去言语有点过激，但其实现实就是这样的。特别是在项目的用户社区里，情况会更糟：一个“伸手党”可以浪费成千上万人的时间。

简介

读懂该小节需要理解什么是“黑客”，我想能看到我写的文字的人应该都明白黑客是什么。当然，如果这也算一个问题的话可按《提》的方法获得答案。

黑客们喜爱有挑战性的问题，或者能激发他们思维的好问题。…… 好问题可以提高我们的理解力，而且通常会暴露我们以前从没意识到或者思考过的问题。对黑客而言，"好问题！" 是诚挚的大力称赞。…… 我们不讳言我们对那些不愿思考、或者在发问前不做他们该做的事的人的蔑视。

归纳并提出一个好问题黑客们会赏心悦目；提问前不思考、不动手的人会被蔑视。

我们意识到许多人只是想使用我们写的软件，他们对学习技术细节没有兴趣。对大多数人而言，电脑只是种工具，是种达到目的的手段而已。他们有自己的生活并且有更要紧的事要做。我们了解这点，也从不指望每个人都对这些让我们着迷的技术问题感兴趣。尽管如此，我们回答问题的风格是指向那些真正对此有兴趣并愿意主动参与解决问题的人，这一点不会变，也不该变。如果连这都变了，我们就是在降低做自己最擅长的事情上的效率。

时间对于黑客和用户都是非常宝贵的，用户对技术细节不感兴趣很正常，但是对于没有对软件真正产生兴趣或者不主动参与解决问题的人，他们永远也别想得到解答。

如果你厌恶我们的态度，高高在上，或过于傲慢，不妨也设身处地想想。我们并没有要求你向我们屈服 —— 事实上，我们大多数人非常乐意与你平等地交流，只要你付出小小努力来满足基本要求，我们就会欢迎你加入我们的文化。但让我们帮助那些不愿意帮助自己的人是没有效率的。无知没有关系，但装白痴就是不行。

黑客和用户是平等的，黑客们会无视“伸手党”的一切问题，并且默认提问者就是“伸手党”。

在提问之前

请注意该章节是“在提问之前”：

1. 尝试在你准备提问的论坛的旧文章中搜索答案。
2. 尝试上网搜索以找到答案。
3. 尝试阅读手册以找到答案。
4. 尝试阅读常见问题文件（FAQ）以找到答案。
5. 尝试自己检查或试验以找到答案。
6. 向你身边的强者朋友打听以找到答案。
7. 如果你是程序开发者，请尝试阅读源代码以找到答案。

当你提出问题的时候，请先表明你已经做了上述的努力；这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好，因为我们更乐于回答那些表现出能从答案中学习的人的问题。

如果你“不假思索”地提问，即使有人回答你，那多半也是“脸上笑嘻嘻，心里 MMP”，你基本得不到你想要的答案；即使你这次侥幸得到了正确解答，你肯定还会有更多的问题，而这些问题基本不会有人理你了。

当你提问时

慎选提问的论坛

• 在与主题不合的论坛上贴出你的问题。
• 在探讨进阶技术问题的论坛张贴非常初级的问题；反之亦然。
• 在太多的不同新闻群组上重复转贴同样的问题（cross-post）。
• 向既非熟人也没有义务解决你问题的人发送私人电邮。

找对的地方提问；不确定问题是否会受欢迎就不要提，因为你的提问对有能力解答你问题的人来说本身就是一些列问题：

1. 要不要回答
2. 要怎么回答你才能避免你“误入歧途”，因为有的时候一个答案会引发更多的提问
3. 要怎么回答你才能既帮助到你也帮助到潜在的其他用户

回答者考虑的远比你想象的要多，所以尽量避免提问，要提就提一个好问题。

别像机关枪似的一次 "扫射" 所有的帮助渠道，这就像大喊大叫一样会使人不快。要一个一个地来。

论坛发帖、提 issue、群里问、发邮件、发 IM 选其一。如果你没和维护者面过基，千万不要把提问通过邮箱或者 IM 发给他，这对他是极大的骚扰和困扰！

对于 B3log 开源的项目而言，我个人更倾向于解决在黑客派上的提问帖，这样能帮助到更多人的概率更大。除非你是我的付费客户，否则请不要发邮件或者 IM 向我提问，我会忽略此类信息。

Stack Overflow

搜索，然后 在 Stack Exchange 问。

Stack Exchange 是一个站群，按大分类分了很多子站点，其中 Stack Overflow 是编程相关问答的子站。ESR 之所以推荐它，除了它是世界上目前最有效的问答站外，我觉得很可能还因为它们是非常开放的，所有上面的内容都使用共创协议发布，鼓励带原作链接进行分享演绎，并且可商用。

除了内容协议非常宽松开放以外，SE 还提供了非常实用的 API，让开发者可以更好地通过他们的数据来发展应用生态，这和很多类似的问答站点是截然不同的。就国内的问答站而言，基本都是强调保护作者版权、禁止商用转载，甚至是禁止转载，这对作者看似是保护，实则是在破坏内容创作的生态，导致恶性循环。

网站和 IRC 论坛

在任何论坛发文以前，先确认一下有没有搜索功能。如果有，就试着搜索一下问题的几个关键词，也许这会有帮助。如果在此之前你已做过通用的网页搜索（你也该这样做），还是再搜索一下论坛，搜索引擎有可能没来得及索引此论坛的全部内容。

搜索之后再搜索，实在搜不到答案了再想其他办法。IRC 我基本没用过，就不展开了，但如果你有 Linux 方面解决不了的问题，可以一试。

第二步，使用项目邮件列表

当某个项目提供开发者邮件列表时，要向列表而不是其中的个别成员提问，即使你确信他能最好地回答你的问题。

如果一个项目既有 "使用者" 也有 "开发者"（或 "黑客"）邮件列表或论坛，而你又不会动到那些源代码，那么就向 "使用者" 列表或论坛提问。不要假设自己会在开发者列表中受到欢迎，那些人多半会将你的提问视为干扰他们开发的噪音。

用户邮件列表和开发者邮件列表是两个邮件列表，开发者邮件列表是开发者之间沟通用的，不是对外解决问题的地方。ESR 也提到了如果有自信，并且问题在用户邮件列表中没得到解决，那也可以在暗中观察（学习开发者之间的沟通交流方式和文化）后向开发者邮件列表求助。

自从有了 GitHub 后，邮件列表也用得很少了。尤其是 GitHub 提供了 @Team 后，和开发团队交流就变得更有效率了。ESR 对于邮件列表的建议同样适用于 GitHub 上艾特团队，也就是要分清楚开发团队和支持团队的区别，或者是分清楚核心团队和 XX 项目团队的区别，作为提问者，请不要艾特个人开发者。

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

别用喋喋不休的帮帮忙、跪求、急（更别说救命啊！！！！这样让人反感的话，用这种标题会被条件反射式地忽略）来浪费这个机会。不要妄想用你的痛苦程度来打动我们，而应该是在这点空间中使用极简单扼要的描述方式来提出问题。

再多的跪求、在线等、标点符号、Emoji 或者特殊符号也解决不了你碰到的问题，反而会被黑客们“条件反射式地忽略”，简明扼要的标题是一个好问题的开始。

一个好标题范例是目标 —— 差异式的描述，许多技术支持组织就是这样做的。在目标部分指出是哪一个或哪一组东西有问题，在差异部分则描述与期望的行为不一致的地方。

X.org 6.8.1 的鼠标光标，在某牌显卡 MV1005 芯片组环境下 - 会变形。

另外，这一小节对在回复中提出新问题也给出了建议：无论是邮件列表还是网页论坛，尽量不要在回复中提出新问题，新问题就新发邮件或者新开帖子。

使问题容易回复

以“请将你的回复发送到……”来结束你的问题多半会使你得不到回答。

在论坛，要求通过电子邮件回复是非常无礼的，除非你认为回复的信息可能比较敏感。

这点很好理解，用什么渠道发布的提问，回答者就回复到该渠道上。除了可能涉及敏感信息外，提问者这样的请求是无理并且无礼的。

用清晰、正确、精准并语法正确的语句

正确的拼写、标点符号和大小写是很重要的。通常来说，如果你觉得这样做很麻烦，不想在乎这些，那我们也觉得麻烦，不想在乎你的提问。

别以为别人不在乎拼写、标点符号和大小写，黑客们甚至在乎空格的使用！比如中文和英文、数字、符号之间必须要有空格，这个空格被称作“盘古之白”。

关于大小写引发的“悲剧”也不少，甚至可能就发生在你身上。比如你简历是不是写过“iphone/ios 开发”，“熟练使用 JAVA”，“熟悉 Mysql”？这样“不拘小节”的人恐怕不知道大多数编程语言是区分大小写的吧....

如果在使用非母语的论坛提问，你可以犯点拼写和语法上的小错，但决不能在思考上马虎（没错，我们通常能弄清两者的分别）。同时，除非你知道回复者使用的语言，否则请使用英语书写。

B3log 开源项目提问无论是在 GitHub 上还是在黑客派上，均可优先使用中文。

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

• 对一些特殊的文件不要设置固定宽度（譬如日志档案拷贝或会话记录）。数据应该原样包含，让回复者有信心他们看到的是和你看到的一样的东西。

帖日志要保证是纯文本格式，特别是服务器端日志，千万不要截图（特别是那种截图还“勾画重点”的行为应该立刻停止）；对于浏览器端的监控调试输出可以截图，但截图时要考虑信息是否完整，也不要包含无用画面。

• 勿滥用表情符号和 HTML 功能（当它们提供时）。一两个表情符号通常没有问题，但花哨的彩色文本倾向于使人认为你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来像个傻笑的小姑娘。这通常不是个好主意，除非你只是对性而不是对答案感兴趣。

可能你碰到问题后心情很复杂，需要大量表情符号、红绿色、超大标题或者 gif 动图来表达你心中的困惑，但是这样做除了表现出幼稚、干扰阅读外没有任何用。

这一小节中 ESR 还建议了很多条关于发送邮件时的细节，现在邮件在问答时用得比较少了，所以略过。

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

• 仔细、清楚地描述你的问题或 Bug 的症状。
• 描述问题发生的环境（机器配置、操作系统、应用程序、以及相关的信息），提供经销商的发行版和版本号（如：Fedora Core 4、Slackware 9.1 等）。
• 描述在提问前你是怎样去研究和理解这个问题的。
• 描述在提问前为确定问题而采取的诊断步骤。
• 描述最近做过什么可能相关的硬件或软件变更。
• 尽可能的提供一个可以重现这个问题的可控环境的方法。

项目维护者通常会提供问题报告模板来引导用户报告问题，如果你在报告问题时没有看到模板，那就按照上述建议进行问题描述。

话不在多而在精

你需要提供精确有内容的信息。这并不是要求你简单的把成堆的出错代码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境，尽量将它剪裁得越小越好。

这样做的用处至少有三点。 第一，表现出你为简化问题付出了努力，这可以使你得到回答的机会增加； 第二，简化问题使你更有可能得到有用的答案； 第三，在精炼你的 bug 报告的过程中，你很可能就自己找到了解决方法或权宜之计。

动手简化问题是非常重要的，也许你在简化过程中就可以获得解决方案。

别动辄声称找到 Bug

编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了 Bug，也就是在质疑他们的能力，即使你是对的，也有可能会冒犯到其中某部分人。当你在标题中嚷嚷着有 Bug 时，这尤其严重。

不要自以为是的认为你真的发现了 Bug，更不要直接说出来。大家都是为了软件的将来更好，礼貌明智的表达更能有效促进软件发展。

提问时，即使你私下非常确信已经发现一个真正的 Bug，最好写得像是你做错了什么。如果真的有 Bug，你会在回复中看到这点。这样做的话，如果真有 Bug，维护者就会向你道歉，这总比你惹恼别人然后欠别人一个道歉要好一点。

即使你真的确定是 Bug 了，也不要直接说出来，维护者会明白你的意思的，并且向你道歉。不要认为维护者是玻璃心，其实是他们只对他们认为有价值的问题上心。

低声下气不能代替你的功课

有些人明白他们不该粗鲁或傲慢的提问并要求得到答复，但他们选择另一个极端 —— 低声下气：“我知道我只是个可悲的新手，一个撸瑟，但...。”这既使人困扰，也没有用，尤其是伴随着与实际问题含糊不清的描述时更令人反感。

时刻记住大家的时间都很宝贵，描述问题是关键。

描述问题症状而非你的猜测

告诉黑客们你认为问题是怎样造成的并没什么帮助。（如果你的推断如此有效，还用向别人求助吗？），因此要确信你原原本本告诉了他们问题的症状，而不是你的解释和理论；让黑客们来推测和诊断。如果你认为陈述自己的猜测很重要，清楚地说明这只是你的猜测，并描述为什么它们不起作用。

往往简单的问题早都被解决了，你碰到的通常都是复杂的问题。复杂的问题可能有 100 种产生的可能性，你说的只是一种可能性，而且很可能是错误的，即使你提供了理论解释。

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

问题发生前的一系列操作，往往就是对找出问题最有帮助的线索。因此，你的说明里应该包含你的操作步骤，以及机器和软件的反应，直到问题发生。

描述问题发生的步骤至关重要，如果你按照你给的步骤不能重现问题，那就不要提问。另外，可自己尝试手动调整日志级别来观察输出情况。

记住，多不等于好。试着选取适当的调试级别以便提供有用的信息而不是让读者淹没在垃圾中。

描述目标而不是过程

如果你想弄清楚如何做某事（而不是报告一个 Bug），在开头就描述你的目标，然后才陈述重现你所卡住的特定步骤。

你别笑，我真遇到过这样报告问题的：“我发现了个 bug，你的软件不能做 XXX。”我回复：“这不是 bug，是个 feature。”并关闭。

软件所有的功能通常都在界面或者参数上提供出来，文档上也会有相应描述。如果某个功能你找不到入口，只有两种情况：

1. 这个功能是个彩蛋
2. 没这功能

别要求使用私人电邮回复

黑客们认为问题的解决过程应该公开、透明，此过程中如果更有经验的人注意到不完整或者不当之处，最初的回复才能够、也应该被纠正。同时，作为提供帮助者可以得到一些奖励，奖励就是他的能力和学识被其他同行看到。

秉承开源的理念：开放、共享、协作来进行提问和解决问题很有效也很有价值。

对于 B3log 开源项目而言，优先到论坛发帖提问，请勿私信我，私信我的话我只会回你：“请到论坛发问答帖。”或者直接忽略你的提问。

清楚明确的表达你的问题以及需求

漫无边际的提问是近乎无休无止的时间黑洞。最有可能给你有用答案的人通常也正是最忙的人（他们忙是因为要亲自完成大部分工作）。…… 因此，问“我想更好的理解 X，可否指点一下哪有好一点说明？”通常比问“你能解释一下 X 吗？”更好。

如果你对可能的答案的边界不清楚，最好不要问。

询问有关代码的问题时

这一节 ESR 建议在反馈代码问题时可以通过最小化测试用例（前面“话不在多而在精”一节有提到过）进行描述。

一般而言，要得到一段相当精简的测试用例并不太容易，但永远先尝试这样做的是种好习惯。这种方式可以帮助你了解如何自行解决这个问题 —— 而且即使你的尝试不成功，黑客们也会看到你在尝试取得答案的过程中付出了努力，这可以让他们更愿意与你合作。

如果是 code review：

一定要提到你认为哪一部分特别需要关注以及为什么。

别把自己家庭作业的问题贴上来

黑客们很擅长分辨哪些问题是家庭作业式的问题；因为我们中的大多数都曾自己解决这类问题。同样，这些问题得由你来搞定，你会从中学到东西。你可以要求给点提示，但别要求得到完整的解决方案。

这里“家庭作业式的问题”主要就是指那种 显然 是要通过自己学习来解决的问题，并且通过学习肯定能解决的问题，总之，你学了就知道了。

去掉无意义的提问句

避免用无意义的话结束提问，例如“有人能帮我吗？”或者“这有答案吗？”。

这和问你“在吗？”一样，大部分时候我都很想回复“不在。”你要知道，在一些代码实现中，我们都是尽自己的最大努力来做简化，看到你这样问，我们会条件反射地把它优化掉。

即使你很急也不要在标题写紧急

这是你的问题，不是我们的。…… 有半个例外的情况是，如果你是在一些很高调，会使黑客们兴奋的地方，也许值得这样去做。在这种情况下，如果你有时间压力，也很有礼貌地提到这点，人们也许会有兴趣回答快一点。

过分强调往往适得其反。

礼多人不怪，而且有时还很有帮助

彬彬有礼，多用请和谢谢您的关注，或谢谢你的关照。让大家都知道你对他们花时间免费提供帮助心存感激。…… 坦白说，这一点并没有比清晰、正确、精准并合法语法和避免使用专用格式重要（也不能取而代之）。

礼多人不怪，但别颠倒主次，精准描述问题永远是第一位。

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

问题解决后，向所有帮助过你的人发个说明，让他们知道问题是怎样解决的，并再一次向他们表示感谢。…… 在黑客中，这种良好的后继行动实际上比传统的礼节更为重要，也是你如何透过善待他人而赢得声誉的方式，这是非常有价值的资产。

问题即使是自己解决的，也请在解决后补充下简短的说明，这对于积攒声誉很有帮助。其他遇到同样问题的人会感激你的，黑客们也会对你有始有终的行动表示赞赏，即使这个问题对他们来说不是个好问题。

如何解读答案

RTFM 和 STFW：如何知道你已完全搞砸了

如果你收到 RTFM （Read The Fucking Manual）的回应，回答者认为你应该去读他妈的手册。当然，基本上他是对的，你应该去读一读。…… 如果你收到 STFW（Search The Fucking Web）的回应，回答者认为你应该到他妈的网上搜索。那人多半也是对的，去搜索一下吧。…… 你不应该因此不爽；依照黑客的标准，他已经表示了对你一定程度的关注，而没有对你的要求视而不见。

鸟哥语录.jpg。

如果还是搞不懂

如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。

只要你有搞不懂的东西，永远优先尝试自己解决。

处理无礼的回应

很多黑客圈子中看似无礼的行为并不是存心冒犯。相反，它是直接了当，一针见血式的交流风格，这种风格更注重解决问题，而不是使人感觉舒服而却模模糊糊。…… 另一方面，你偶尔真的会碰到无礼和无聊的言行。与上述相反，对真正的冒犯者狠狠地打击，用犀利的语言将其驳得体无完肤都是可以接受的。然而，在行事之前一定要非常非常的有根据。

这一点让我想起了曾仕强的“只讲妥当话、不讲实在话”。至少在黑客的圈子里，这样说“妥当话”完全就是在浪费大家时间。

如果你想得到的是信息而不是消磨时光，这时最好不要把手放在键盘上以免冒险。

做个键盘侠实在是太容易了。

如何避免扮演失败者

如果你搞砸了，并且被人在公开场合告知你的愚蠢行为时：

熬过去，这很正常。…… 当有人评论你的一个说法有误或者提出不同看法时，坚持声称受到个人攻击也毫无益处，这些都是失败者的态度。…… 夸张的讲法是：你要的是友善（以上述方式）还是有用？两个里面挑一个。

这一节 ESR 建议大家不要卷入毫无意义的口水战。有些“自以为是专家的不中用家伙”他们其实是“测试你是否真会搞砸的心理专家”，这些人就靠引战和表演来满足他们的内心。

其它读者要么不理睬，要么用自己的方式对付他们。这些来找麻烦的人在给他们自己找麻烦，这点你不用操心。

不该问的问题

这一节是一些常见的不该发问的示例，建议看原文。

好问题与蠢问题

这一节是一些常见的好问题和蠢问题示例，建议看原文。

黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙；我相信他是对的，如果我像个乞讨者那样提问，不论我是谁，一定会惹恼某些人或者被他们忽视。

如果得不到回答

总的来说，简单的重复张贴问题是个很糟的点子。这将被视为无意义的喧闹。…… 另外，你可以向很多商业公司寻求帮助，不论公司大还是小。别为要付费才能获得帮助而感到沮丧！…… 就算软件没花费你一分钱，你也不能强求技术支持总是免费的。

总之，正确的提问但没有得到回答时不要沮丧，因为这两者之间没有必然的因果关系。付费咨询也是解决问题的一条路径，就像你选择使用免费软件一样。

 

菜鸟提问需知

原文：

速记

1. 不要大喊大叫
2. 使用一个好读的呢称
3. 不要抱怨
4. 语气请低调
5. 请帮助他人
6. 尊重他人

全文

对新人来说，最好的学习方式是：去找个DM，让他手把手的教你。你会发现，这只不过是个游戏而已，并不难学.新手需要的不是160RMB的“精装”PHB，而是一种态度——认真、热情、严谨、谦虚，呃，还有好奇心和想象力，在这个快餐文化的时代，并不是人人都具有这些东西。不要到IRC的公共频道里去寻求帮助，那里都是BT和烂人，他们最喜欢KUSO那些大喊大叫的新人-____-b————哥布林诗人给新手的忠告

• 以上文字采自最深的地下城，这是一个很上等的网站。在我做网游开发的时候，经常去看。我想以后我还会重新回到那里，毕竟我这种人对一个到处是坑的站点还是充满亲近感的。

• 上面那段话，给我深刻的印象，因为在国内的大多数IT社区，包括CSDN、Python中文，以及大大小小的QQ群，小论坛等等，无不充满了大喊大叫的新人。
• 很不幸，那里也游荡着各种不靠谱的BT和烂人……于是，我们每天都可以看到有无数的新人在抱怨对他们充满敌意的恶劣环境，这样的环境下，年轻人如何成材？中国如何有希望？等等等等……
• 然而，实际上，初学者们不正确的交流方式，大大影响了他们得到帮助的机会。总结起来，以下几种表现，几乎是一定会被BT的。
  • 大喊大叫。特别是在QQ群里，使用过大的字体，过于鲜艳的颜色，都会严重影响阅读。本来QQ默认的窗体尺寸就小，你放一堆二号字上去，何况又是鲜红或嫩绿的二号字，让人怎么读？技术交流首先要保证消息的可读性，不要没事儿走视觉系。要知道每天坐办公室啃代码的老家伙们骨子里跟非主流艺术青年八九是不搭界的。黑色或靛蓝等传统的书写颜色可以让人舒服的阅读。
  • 使用一个不好读的ID。这一点可能不太容易被人理解。然而如果你的ID别人都没办法念出来，大家就很难给你一个私密的回复。与其说是技术原因，更多的是心理因素。理由同上。不要指望每天坐办公室的老coder会跟你一样喜欢玩儿非主流视觉系。事实上靠谱的老程序员们往往跟这帮子家伙很不搭界。至少他们进入编码的心理状态时，是非常不喜欢看到一个花里胡哨的家伙跳出来在他面前画火星文。我从来没见过哪个靠谱的家伙顶着一个火星文ID在IM上写一堆鲜红嫩绿的二号字初号字。这些人最多也就是在QQ或MSN的签名上放几个表情而已。我曾遇到一个非常悲惨的实例。有个朋友多年来一直因为ID的问题在我们这个小圈子里被人BT，事实上他的名字一个火星文都没有，甚至也是一个合乎文法的名词词组。然而这个名字非常奇怪，念上几遍就会让人有想去抽他的冲动。于是大家不约而同的对他进行疯狂的BT。好在这位兄台有非常强健的神经，就像踩不死的小强一样生存了下来，并且在这种互相精神攻击的恶劣交流状态下学习到了很多东西。他的顽强还表现在工作的风格上。事实上这些年来他解决了很多很BT的技术问题，写出的代码搞定了很多我看来完全发疯的需求。就这一点，我是非常佩服他的学习精神、钻研精神以及娱乐大众的牺牲精神。为此我就不告诉你们他的ID叫“想你的我”，因为太难念，我们一致称他为水煮鱼。另外我要说的是，如果你没有水煮鱼那种被人切成一片片还要丢进锅里水煮再浇上辣椒也不怕的精神，还是起一个正常点的，好念的ID吧……事实上用自己真名的新人往往会得到比较亲切的帮助，不信你试试？
  • 不要没事儿就在公共地盘报怨没有人帮助你。要知道在自由软件社区帮助你的人，九成九都是义务劳动，他们还要牺牲自己的工作和休息时间。没人欠你的。有个家伙因为五分钟没有人在QQ群里回答他的白痴问题，就开始大骂，于是他被我用各种方式羞辱了几个星期。没人会同情他。好吧，我不是一个心胸开阔的人。就是我这样一个小心眼又虚荣的家伙曾经在没有任何报酬的情况下翻烂了一本牛津高阶词典来翻译Python tutorial。这件事是我在失业的时候蜷缩在冬天冰冷的小屋里完成的，而且五年来我还把这件傻事重复做了四遍，正准备做第五遍。如果你能做到同样的程度，你也一样有资格去BT那些乱喊乱叫的家伙。如果你觉得应该支持比我更有RP的前辈，那可以无视我，请你去花钱买一本陈儒的Python源码剖析，或者去吹捧一下ZQ、Limodou、黄冬这些为大家做了很大贡献的人（不知道他们是谁？你真的是Python中文社区的成员吗？那你一定是新警察……）。
  • 尽量少问软件破解的问题。我是说在自由软件社区。我不想争论道德高度的问题，这样的问题已经讨论过太多次了。我只想说，在自由软件社区找人要破解版或注册机，真的看起来很蠢。
  • 语气请低调一些。趾高气扬的菜鸟只会被加倍的BT。这一点不需要多解释了，提醒一句：这个世界比你想像的NB的多。
  • 遇到一个厚道的解答者，请珍惜，不要把他当作垃圾桶，什么白痴问题都丢过去问。学着自己解决问题永远是一种美德。如果你是一位青春美少女，对方是一个单身的宅男coder，另当别论，看在他厚道的为新人解答问题，任劳任怨的份上，嫁给他吧。
  • 尽量帮助和你一样的菜鸟，不要BT他。这会使高阶的人力资源得到更有效的利用。就好像不要总是在游戏公会里请求顶级玩家帮你做新人任务一样，其实找个高你5级的帮手就很豪华了。同样你也应该多帮一帮比你更低级的玩家。
  • 被BT时，请先检讨自己是否使用了挑衅技能。对于一个小圈子，往往BT新人会是老鸟们的重要福利之一。乱凑热闹或者灌水过多，都有可能招致灭顶之灾。在QQ群里发连锁消息尤其愚蠢。如果被BT，请先不要回击，通常来说，正是你这个新来的家伙破坏了生态平衡。如果觉得留下来学习更重要，就闭上嘴巴，多听少说。

 

IT行业人员的提问建议

 

里面提到的两个例子比较典型。另外后面有人评论中也给了一个例子。

• via: 

 

实例郁问

• 这几天对几个网友的请教方式颇感无奈。这里举2个实例：
  1. 有个网友因为项目比较急，而且之前也没有怎么接触过该项目的一些相关知识。正好我对这方面熟悉，于是找到我给出一些建议和提示。我大概知道了其要点，然后从头到尾给出了一些架构和技术上的要点。我觉得凭这些应该没有什么大问题了。没想到在未来几天里，该网友一直问我一些我已经解答过的问题。更意外的是同一问题问了至少5遍。我很郁闷，就问了一句，你工作几年了，他告诉我4-5年。我不再说什么了。如果工作4-5年，按照我的理解是不应该有这样的情况的。
  2. 另外一个网友因为一个小问题卡住了。我说了一下我的想法。他说他以前也做过，没有问题，而且特别坚持自己的意见。最后我只能说可以试一试我的建议。一个礼拜之后，他看见我，问我同样的问题，我惊诧道，"你还没有解决吗？"。他说还没有。我继续把我的建议重复了一遍。他过了一会高兴的回答我说可以了。

在上面的2个实例中，我感概太多了。

• 针对第一件事情，我觉得至少存在以下方面的问题：

1. 做事情太着急了   2. 应该有把握整个project的能力   3. 应该能够控制自己的心态   4. 问问题之前最好总结一下，或者是思考一下人家给你的提示。不要一二再再二三的去问同一个问题大于3次。

• 对于工作4-5年的人，已经培养了自己解决问题，分析问题的方法。而且在把握一个项目上应该有一定的经验。
• 冷静思考，沉着应对，都是现在浮躁的环境必须要有的。这些技能和心态和技术没有直接的关系。对中国的IT业，我一直认为是比较浮躁的。在这样的环境下，难道不能有自己的做事风格来行走着浮躁之面上吗？
• 针对第二件事情，我觉得可以这么理解：

1. 每个做IT人骨子里或多或少都自以为是，包括我自己也是。请教别人时还是那样   2. 既然自己没有解决，何不试一试别人的建议呢，也许会给你带来意想不到收获。   3. 多听听人家的意见或建议，对自己是有帮助的。放下一些不必要的面子。

• 如果坚持自己是对的，又不肯听从人家意见，那你问人家干嘛呢？
• 对待学习，对待工作，我们确实应该保持自信，但这绝不是自以为是。虚心请教他人，听取别人意见，在整个过程中我们会学到不少东西。别总以为自己是对的，每个人的知识面和知识的掌握程度都是有限的，这样自己的理解出现偏差和错误在所难免。
• 从另外一个角度上讲，我们在处理学习和工作上，应该知道一件事情如何去做，如何以什么样的心态去做。对于一个工作4-5年的人出现上面的情况我觉得实在不应该。这样的情况在刚工作时存在。随着自己的阅历增长，在态度，方式上都会逐渐成熟，都会有自己的一套方法。这些方法在面对一些复杂事情，未熟悉事情都是有帮助的。

Service Is Living 建议

所以我的想法是：

1. 戒浮戒躁，踏踏实实做事情   2. 谦虚，自信，不是自以为是   3. 有自己的做事风格，包括工作方式和心态。   4. 沉着，冷静，从大局考虑。   5. 做事情（例如向别人请教）前自己先做好必要的准备，想想。   6. 态度   7. 沟通。

上面的情况中，我是否真的让人家明白了，也许自己以为说清楚了。后来我也开始有些着急了，我心里还是告诫自己应该平和一些。尽管有些做的不好，我也一直按照上面的思路做。 转几个评论：

• #23楼 2008-09-10 11:28 李胜攀
• "做事情（例如向别人请教）前自己先做好必要的准备，想想。" 这一点很重要 我记得很多次别人问我问题时，我都会让他把问题详细描述一遍，结果到最后，不用我回答，他自己就知道怎么做了。
• #24楼 [楼主] 2008-09-10 11:33 Confach
• @lkc 冷静，很重要。我见过好多人一遇见问题就开始这里找找，哪里问问，其实有这些时间还不如先分析一下原因所在，然后再继续寻找，这样节省时间，也锻炼自己的分析能力
• #30楼 2008-09-10 11:43 绝世无才
• 博主说得很对，碰见再急的问题时，也需要冷静，冲动是解决不了技术问题的 一次，两个医院客户那里同时有一个新模块（门诊收费）上线，这个模块我做的，并且也测试了几周，但我知道真正用的时候肯定会有问题，而且我并不在现场，于是我不断的告诉自已，再急也要冷静，　于是我远程指挥两个同事，并且不断的收到Bug，不断的编译　发邮件过去。从早上８点开始直到１２点医院下班，我竟然发送了将近３０封邮件。我和同事交流的过程中不断的说：冷静 他们说晕了，挺不住了，要不就停吧，此时我也说冷静。结果又经过一个下午的苦战，两边的系统都成功的上线了。 此刻比踢完一场球还痛快！
• #36楼 2008-09-10 14:01 4681 [未注册用户]
• 30楼做的东西真牛,到最后还有这么多的bug.
• #38楼 2008-09-10 14:40 绝世无才
  • @4681
  • 有些时候，我们无法决定自已的软件装到客户机器上后是如何运行的，
    但我们要保证在自已的电脑上和测试用的电脑上是能正常运行的，
    另外我们更不能保证客户一定要按我们想象的那些步骤进行操作，
    所以问题是无法避免的。
    我们能做到的是经过仔细的需求分析，设计架构，编写代码，出现问题时，尽量不要因为一个修改带来更多的问题（耦合性）
    当然，最重要的是需要时时保持一个冷静的头脑 

 

 

转载地址：https://kevin.blog.csdn.net/article/details/84935185 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！