关于批评
每个人都是批评家。每个开发者都曾是批评的接受者,也曾是批评的给予者。批评是我们工作中至关重要的一部分,无论是代码审查、在社交网络上的评论,还是在回顾会议中。那么,让我们来看看批评的两个方面:
接受批评
首先,我们应该区分真正的批评和谬论(逻辑上无效的推理),例如人身攻击(人身攻击而不是对代码/文章/论点提出观点:“你没有经验来理解这一点”)或错误的二分法(在实际上有更多选项时提供两个选项:“你可以使用 Vue 或 React。”),并指出它们:
“请不要进行人身攻击,让我们集中精力于论点/代码。”
“这是一种错误的二分法,我们还可以使用许多其他框架和库!”
接下来,无论批评是否具有建设性,都要承认批评的合理性。即使是非建设性的批评,也能帮助你完善论点,或提供新的视角来思考你的代码。如果你觉得受到了不公正的批评,请保持沉默——抱怨只会显得你缺乏安全感;尽量避免在讨论中表现出你的自尊心。
“感谢您的评论。”
承认错误并不丢人,只要你不再犯错。告诉批评你的人:
“谢谢你纠正我之前的错误立场。”
是你在任何讨论中可以采取的最有力的举措之一。
最后,尝试从批评中寻找行动方向:如何利用批评来改进你的代码、文章或论点?如果这行不通,可以直接询问批评者,看看他们能否提供切实可行的建议:
“您对我该如何改进这一点有什么建议吗? ”
这通常要么让他们闭嘴,要么可能带来真正改进的机会。无论哪种方式,你都是赢家。
就是这样。你处理批评的方式既审慎又专业。干得好!
给予批评
批评能带来什么好处?这仅仅是为了满足你自以为是的欲望吗?还是为了说服别人支持你的事业?你指望通过富有洞察力且文明的讨论来强化你的论点吗?你甚至想成为该领域的专家吗?
无论你的目标是什么,如果很明显你无法实现,就避免讨论。不要陷入沉没成本谬误(因为你已经开始这样做了,所以浪费了你的时间),在明确你无法实现目标后继续讨论。如果有疑问,退出讨论比你想象的要简单:只需道别,不要再发表评论。你可能会感到有压力要回应接下来的评论,甚至是诽谤——不要这样做。这不值得你浪费时间,而且诽谤只会让那些说这些话的人而不是那些被针对的人受到更多影响。
否则,请让批评值得你和接受批评的人投入时间:建设性的批评总是可取的,但有时,如果从头开始是唯一的出路,破坏性的批评也是合理的。好的批评需要满足三个要求:逻辑严谨、不带任何自负,并且对接受者具有可操作性:
逻辑健全性
正如我们在接受批评时已经了解到的,论点应该合乎逻辑,因此要避免谬误。
👎 “每个人都在使用 React,你也应该使用!”
👍 “React 拥有庞大的生态系统,可以帮助您更快地完成项目。”
摆脱自我
论证不仅在内容上要客观,而且在形式上也要客观:
👎 “如果我是你,我会使用递归。”
👍 “这项任务适合采用递归方法。”
可操作性
最好的批评是接受者可以采取行动的批评:
👎 “这太糟糕了,根本无法改进!”
👍 “相反,如果你碰巧重写这个,你可以使用构建器模式。”
应该包括支持你的观点的外部来源,以加强你的观点,并提供更多了解该主题的机会。
你已经提出批评了吗?太好了。现在它本身可能又会成为别人批评的对象,而你可能又会成为被批评的对象。这是一件好事。
最后的话
🙏 “感谢您花时间阅读这篇文章。”
你可能已经知道这些了,所以才来这里批评这篇文章。尽管批评吧,你的批评只会让这篇文章变得更好。或者,这能给你一点小小的提醒,让你进步?太好了。无论如何,祝你今天愉快!
文章来源:https://dev.to/lexlohr/about-criticism-12f3