程序员让我又爱又恨🤬

我从事编程工作已经快15年了，我真的很喜欢这份工作的大部分内容。有时候我会觉得自己对编程上瘾，下午5点下班后，我会花6个小时继续写一些与工作无关的东西。而有时候，我又会想开一家墨西哥卷饼餐车。我已经快40岁了，之前也做过其他工作，所以我知道其他领域也会有令人沮丧的地方。但是，也许通过交流，我们整个行业可以一起努力，让情况变得更好。

我以前在DevPoint Labs编程训练营教编程。我热爱教学，尤其喜欢教编程。看到学员们在学习新知识时恍然大悟的那一刻，真的令人兴奋。教书让我很快明白的一点是，你必须要有极大的耐心。你会遇到各种考验、纠缠、不被认可的情况，但你必须面带微笑地应对这一切。一个学生会问你刚刚讲完的东西该怎么做，然后另一个学生又会问同样的问题，却没意识到之前已经有人问过了。这种情况确实很烦人，但最糟糕的做法就是对他们或者全班同学发火。其实有很多恰当的方法来处理这种情况以及其他类似的情况。

当你开始学习编程时，你需要尽早决定你想走哪条职业道路。你是想把编程当作一份朝九晚五的工作，还是想把它发展成一种职业生活方式？两种答案都完全没问题！我以前在三明治店打工的时候，不会跑到其他店里问他们需不需要帮忙，也不会给他们出主意教他们怎么做三明治才能省钱。我以前是音乐家的时候，也不会去音乐会上告诉他们和弦进行如果换一种方式会更好。然而，作为程序员，我们中的很多人却总觉得有必要快速地贬低和否定其他开发者的作品。如果你选择成为一名朝九晚五的开发者，那就按时上班，写代码，写完就回家。再说一遍，这没什么错。

编程生活方式

随着编程生涯的深入，我们会不断学习新知识。有些人掌握新知识的速度比其他人快得多。很多资深开发者都忽略了这一点。很多人也忘记了，当你学习所有这些知识，并将其作为你的生活方式时，你就成了一名老师。到了这个阶段，这已经不再是一种选择。如果你不想成为老师，那就去做朝九晚五的开发者吧。不要到处宣扬你是一位拥有渊博知识的开发者。

其实，你不需要有几十年的编程经验才能当老师。我对 ReactJS 也不是很精通，但最近几期训练营的学员们都比我了解得多。我可能需要向他们请教，而这些人编程经验还不到一年。如果你知道答案，并且真心愿意帮忙，那就应该伸出援手。

快乐的开发者

有时候，程序员们的帮助之大让我惊叹不已。他们素未谋面，却愿意抽出时间，放下自己的私人生活，远在地球的另一端与我合作。这些人让我由衷感激，也正是他们让我坚持在这个行业。事实上，我想借此机会特别感谢几位让我印象深刻的程序员：

1. Serdar Dogruyol住在比我早 10 个小时的地方，他曾多次熬夜（甚至凌晨？）帮我处理一些棘手的事情。
2. 保罗·史密斯。这家伙真是个球星。超级好相处，而且总是乐于助人。
3. Russ Smith。不能忘记我的好朋友！他可能总是骂我是个混蛋，但如果没有他的帮助，我就不会成为今天的程序员。
4. 杰夫·卡西米尔。我的同行，一位和蔼可亲的巨人。他是我认识的最乐于助人的人之一。
5. 尼克·弗兰肯。如果我有机会去内布拉斯加州，我一定要请这家伙喝杯啤酒！

我还能轻松地把另外20个人加到这个名单里，以后我可能会把他们加进去，但是那样的话我得花上一整天的时间才能把他们都加进去。抱歉！

这些人身上最棒的品质就是，他们让我不敢问问题。有些知识渊博的人，我反而会因为对方的回答让人感觉很不舒服而不敢问。但这些人，我问他们问题都能得到非常真诚且有帮助的回答。不用紧张，不用担心，只要说声“嘿，最近怎么样？”就行了。做一个快乐的开发者的关键就是保持放松。除了“超级放松、随和”之外，我不知道还能怎么解释。

脾气暴躁的开发者

我遇到的问题，而且最近似乎越来越频繁，就是遇到脾气暴躁的开发者。他们明明知道答案，却因为你问了问题而恼火。“RTFM”这个词你可能在查找答案时见过。如果你不知道这个缩写，它的意思是“去他妈的读手册”。谢谢你，混蛋……也许我读了手册，但还是看不懂，因为手册是另一个混​​蛋写的，他只写了一半信息，想当然地认为读者已经知道另一半了。据我观察，这种心态在电子游戏开发社区里很常见。你看到一个quaternion函数，或者你对着色器有疑问。问题是你根本不知道函数quaternion是什么，甚至不知道着色器是什么。显然，你需要阅读更多资料，但如果有人简单地告诉你“哦，这个quaternion方法是用来旋转3D物体的”，那么你需要阅读的“手册”或许就能更容易理解了。

作为一个正在开发大型知名项目的人，你必须做好成为名人的心理准备。在各种会议上，会有狗仔队想和你合影。你会听到人们一遍又一遍地问你同样的问题。你会遇到一些窃取你成果却不给你任何赞誉的人。你还会遇到一些莫名其妙就讨厌你的人。如果你无法接受这一切，那么或许开源软件开发者的聚光灯生活并不适合你。你可以选择去做一名朝九晚五的普通开发者，或者退出这个项目。这完全没问题！

另一个爱抱怨的开发者会做的就是插嘴发表意见。他们非得参与讨论，才能表达对其他开发者提出的修改方案的不满。我最喜欢的是GitHub上的各种drama列表。

以下是我总结的一些识别脾气暴躁的开发人员的迹象。如果你曾经做过其中任何一项，那么请意识到这一点，并努力改正！

1. 那些“没用”的评论者发现有人开始开发新的 Web 框架后说：“既然已经有那么多框架了，为什么还要开发新的呢？” ……嗯，也许他们只是为了好玩？也许只是个学习练习？也许他们根本不知道其他框架的存在？管它呢！你的评论一点用都没有。
2. 这位“精英”听到有人问如何解决某个问题时，反问道：“你为什么要用这种方法解决？” ……我告诉你我为什么用这种方法，对回答这个问题有什么帮助呢？显然，我的方法是我唯一能想到的，而且显然是错的。你到底帮不帮我？
3. “踩”者。看到自己不喜欢的仓库里的拉取请求：👎 或 😕……嘿，谢谢你踩我或者给我一个困惑不悦的表情。那我该删掉我花了整整两天时间做的拉取请求吗？
4. 那些“爱抱怨”的人，喜欢在聊天室/推特上抢着回答每个问题，但他们的回答却晦涩难懂，让人更加困惑，然后当你追问更多问题时，他们又会恼火。（也许我干脆就别问了）
5. 这位“一丝不苟”的人读了另一位开发者的回答，然后迅速否定了对方的答案，认为它是错误的……好吧，我两个都不认识，我该相信谁呢？
6. 这位“管理员”看到有人提交了问题，然后告诉他们这里不是提问的地方，只能提交问题……这在 GitHub 上尤其搞笑。GitHub 内置了问题模板，这些模板旨在让用户以统一的格式提交问题。如果这里不是合适的论坛，你也可以利用这些模板引导用户去正确的提问地点。你创建了 ISSUES_TEMPLATE.md 文件吗？没有？你更新了 README.md 文件，让用户更清楚地知道该去哪里提问吗？也没有？好吧，那就闭嘴回答问题，或者干脆别回复。
7. “放弃式回答”。被问到一个问题，回答了。被追问一个后续问题，又回答了。被再次追问后，就以一句“嗯，我不知道”来结束对话。就这？能不能给我指点一下？如果你真的不想回答问题，那就别回答。如果你没时间或者太忙，直接说出来就行了！（基本上就是第4点）
8. 这个人“态度恶劣”。回答问题就像个冷血机器人。看到“如何……？”这样的问题，就回答“你不能……”。嗯，为什么不能？“这行不通。它不是为此设计的。”好吧，谢谢，你确实回答了我的问题，但总觉得你是个混蛋。

克服脾气暴躁的开发人员

我承认，我变得脾气暴躁了。我以前不是这样的，而且我非常希望自己能改掉这个毛病。我已经意识到这一点，并努力改变现状。那么，该如何改变呢？首先，你要决定自己想走哪条程序员之路。如果你选择的是像我一样的生活方式，那么下一步就是如何与人沟通。

1. 看到某个新框架或其他项目突然冒出来，而你的语言社区里这类项目又很多？不妨请维护者在项目 README 文件中添加一些内容，说明一下这个项目的目标是什么？或许你可以引导他们讨论如何将类似的项目关联起来，或者告诉他们哪里可以找到指向其他项目的有用信息。你也可以主动提出帮忙，让他们参与到其他项目中来。“嘿，如果你想参与框架的开发，我们[issue#4]项目非常需要人手帮忙！”
2. 了解别人为什么选择用某种特定方式编写代码并不能真正帮助你给出更好的答案。如果你知道答案，直接解释就好。如果你不知道，那就让他们一步步解释清楚他们是如何想到这个方案的。这或许能让你找到一些思路，从而帮助他们解决当前的问题。只有到了那时，你才能说：“太好了！它能用了，现在我们来重构一下，这样可以优化代码，提升速度，并修复一些引入的边界情况。”
3. GitHub 真应该去掉“踩”和“困惑”这两个表情。它们毫无帮助。如果你真的非常不喜欢这个 PR，因为它移除了一个非常重要的功能，那么请解释一下你为什么认为这个 PR 不应该被合并。重要提示：你的表达方式很重要。这个人可能刚刚花费了时间和精力来编写这个 PR。“嗨，我对这个改动不太确定。我有一些项目非常依赖这个功能，我还发现其他一些项目也依赖它。有没有其他替代方案？”
4. 如果你总是急于抢答问题，只是为了炫耀自己有多聪明，那你就是个蠢货。如果你想回答问题，最好做好应对所有问题的准备，而不是仅仅指望遇到和你水平相当的同学提出的高深莫测、发人深省的问题。
5. 仅仅因为别人错了，并不意味着你非得恶语相向，当面指责他们。因为自己犯错而让别人难堪，会让他们感到不受欢迎，也会让你显得很没礼貌。你可以花点时间私信给提供错误信息的人，指出（而不仅仅是告诉他们）他们的信息错在哪里。或者你可以说类似这样的话：“我以前也遇到过这个问题，我的解决方法是[其他解决方案]”。这样可以让对方明白，如果一种方法行不通，我还会尝试另一种方法。
6. 如果你真的需要完全掌控代码库的方方面面，那就使用官方提供的工具。如果 GitHub Issues 不适合提问基本的“操作指南”问题，那就创建一个 ISSUES_TEMPLATE.md 文件来说明这一点。确保你的 README.md 文件顶部包含了所有链接和位置信息。最后，如果有人仍然提问（这种情况肯定会发生），那就回复类似这样的内容：“嗨，感谢使用[我的代码库]！我希望 Issues 区域只用于 bug 追踪，所以请把问题[放在这里]提问好吗？非常感谢！”，然后将问题标记为“问题”，并等待回复（或等待 X 天）后再关闭它。
7. 如果你开始尝试帮助别人，却不知如何继续，也许你可以问问身边有没有朋友可以帮忙？“说实话，我现在也不太确定，不过也许@mybuddydev 可以看看？”。如果你实在太忙，也可以直接告诉他们：“嘿，不好意思打断一下，我得走了。如果我回来的时候你还没找到解决办法，我会马上上线，我们一起讨论。” 没人会说“喂，你个混蛋！我还没用完你的空闲时间呢！”。他们更有可能说“哦，没关系！非常感谢你的帮助！”
8. 这才是最重要的。重要的不仅是你说什么，还有你怎么说。我知道我们从事的职业需要和很多说不同语言的人打交道。英语通常是程序员之间的通用语言，所以英语不是你的母语完全没问题。我肯定也说过一些西班牙语的话，听起来有点让人不舒服，但我当时不知道该怎么更好地表达。如果你知道自己正在用一种不太熟悉的语言和别人交流，那就直接告诉对方：“抱歉，我不是故意冒犯，只是不知道该怎么恰当地表达。”

概要

用热情友好的话语欢迎他人。并非每个人都了解你所知道的一切。当别人学习新知识时，请给予帮助和耐心。详细解释远比解释不足或简短回复更友好。如果你写了“TFM”（可能是指“Tumblr”），却只是让别人自己去看，那你最好祈祷一个五岁的孩子都能看懂。否则，就要做好被提问的准备。

快乐的开发者比脾气暴躁的开发者多得多，但如果你脾气暴躁，并且意识到这一点，你就可以再次快乐起来！