软件工程师应该如何吵架?

开发 开发工具
软件公司吵架不是管理不善,往往代表着开放、包容的文化,以及团队成员心无芥蒂的通力合作。

吵架的团队更有生命力

看一家软件公司是否靠谱很简单,在开放式的办公室中有没有随处可以使用到的白板就行。

一个好的软件开发团队往往看起来没那么“和谐”,程序员和产品经理之间,程序员和程序员之间是不是会发生“争吵”。好的软件公司没有不吵架的,不吵架的软件公司要么大家都在划水,要么大家为了维护 “职业形象”处处小心翼翼不敢献计献策。

刚开始和华为的人合作可能会有一些不适应,他们说话的方式简单而直接,往往让人不知所措。这种直接的背后是一种撸着袖子干的企业文化,把“职场文化”变成了团队协作。

软件公司吵架不是管理不善,往往代表着开放、包容的文化,以及团队成员心无芥蒂的通力合作。

回想一下,我们是不是往往都是和陌生人和和气气,和信任的人才大大咧咧呢。

文吵和武吵

不过吵架这事儿还有一些讲究。在公司吵架这事儿分为文吵和武吵:武吵是比谁的嗓门大,谁说话的分量重;文吵讲究的逻辑、推理和归纳。

而武吵和文吵各有用处。

武吵需要的是一个敢于担责,能在关键时候拿出主意的人。在很多讨论会中,群众容易陷入只对自己认知匹配的细节,然后各执一词,都很有道理,也各无过错。这个时候,文吵的逻辑难以派上用场,因为现实世界中没有完美的、正确的方案,只有不那么差的方案。那就需要武吵的人发挥他的影响力,给团队拿个主意,先结束这次讨论,得到一个基本可用的方案来,才能让事情继续。

文吵则不一样,软件开发毕竟是一门科学,大多数情况下需要用到逻辑,通过分析、归纳、总结得到方案。需要收集足够的信息,给出足够的理由,并对方案中的概念给出清晰地定义,最后通过因果分析,证明自己的想法。在大多数情况下,我们更多的需要文吵,通过分析和证明解决遇到的问题。

不管是文吵还是武吵,都需要讲逻辑。只有当团队对这些基本的逻辑规律达成共识的时候,“吵架”才能高效,并且避免落入谬误的陷阱。

逻辑学的三个基本规律

逻辑学的三个基本规律可以让吵架更加准确,避免无意义的争论,减少逻辑矛盾,让吵架有所产出。这三个重要的规律是:同一律、矛盾率、排中律。

同一律

在同一段论述(命题和推理)中使用的概念含义不变,这个规律就是同一律。形式化的表述是 A -> A。

“概念”在逻辑学中的意义非常重要,概念有两个逻辑学规律:内涵和外延。内涵指的是这个概念区别于其他概念的本质属性,例如大熊猫是指的生物学中某一个物种。外延指的是这个概念所能描述的事物的范围,比如白马比马这个概念外延要小,是不同的两个概念。

所以白马非马的本质争论在于自然语言的不确定性:

  • 从概念上说,白马这个概念不是马这个概念。所以白马非马。
  • 从谓词(“是” 这个谓词)逻辑来说,白马这个概念代表的事物集合属于马这个概念代表的事物集合。所以白马是马(白马属于马,但是白马这个概念不是马这个概念)。

同一律描述的是在一段论述中,需要保持概念的稳定,否则会带来谬误。我在大学辩论赛中利用了这个规律,赢了一次辩论。

当时的论题是“网络会让人的生活更美好吗?”,两个论点主要的论点是:

  • 网络让人们的生活更方便。
  • 网络让人们沉溺虚拟世界。

我们选择的论点是 “网络让人们的生活更方便”。在辩论赛的前期,另外一方为了论证 “网络让人们沉溺虚拟世界”,描述了打电话、写信也可以让人生活很美好,并不会沉溺。这刚好落入了我们的逻辑陷阱。我们指出,邮政、电话网络也是网络的一种,对方的逻辑不攻自破。

这属于典型的 “偷换概念”,我们偷换了“计算机网络”和“网络”这几个概念。

矛盾律

矛盾律应用的更为普遍,几乎所有人都能认识到矛盾律。它的含义是,在一段论述中,互相否定的思想不能同时为真。形式化的描述是:“A 不能是非 A”。

矛盾律这个词的来源就是很有名的 “矛和盾” 的典故,出自《韩非子·难势》中。说有一个楚人卖矛和盾,牛皮吹的过大,说自己的盾在天底下没有矛能刺破,然后又说自己的矛,天底下的盾是不能穿透的。前后矛盾是一个众所周知的逻辑规律,但是并不是一开始马上就能看出来,需要多推理几步才能看出来。即使如此,在同一个上下文中,出现了矛盾的逻辑论述也被认为是不可信的。

具有矛盾的论述有时候又被称为悖论。尤其是宗教领域充满了大量的悖论,例如是否存在一个万能的神,做一件自己不能完成的事情。

矛盾律的用处可以驳斥不合理的论断,也可以用于反证法。在软件开发过程中,我们时常遇到这种情况,需要开发过程中才能发现矛盾。这个很难避免,除非有充足经验的工程师。

需要注意的是逻辑学中的矛盾律和毛泽东思想中的矛盾论不是一回事,前者是逻辑学规律,后者是辨证唯物的一种方法。

排中律

排中律是逻辑规律中最难理解的一个规律。它的表述是:同一个思维过程中,两个互相否定的思想必然有一个是真的。用形式化的表述就是,A 或者非 A。

排中律的意义在于,明确分析问题的时候不能含糊其辞,从中骑墙。比如有人讨论:人是不是动物。不能最终得到一个人既是动物又不是动物,这种讨论是没有意义的。

比如在一次技术会议中,需要选择使用的数据库,只能使用一种数据库。如果采用了 MySQL 就不能说没有采用 MySQL。

排中律看起来好像没有意义,但具有非常大的价值,让讨论最终有结论,而不是处于似是而非的中间状态。

如何诡辩

在争吵中,人们会下意识的引入谬误,从而主动或者被动的诡辩。诡辩的方法非常多,下面聊几个有意思的诡辩方法,认识到诡辩的存在,让吵架的输出更可信。

偷换概念

偷换概念是一种利用同一律的诡辩方法。往往是利用一个词语的多义性来制造诡辩,这种例子相当常见,在一次日常对话中:

“朋友:为了让自己的判断和认知更为客观,我们应该同时学习多个学科的东西。

我(故意抬杠):人不能同时学习多个学科的东西。

朋友:为什么,学生不都是同时学习数学、语文、英语么。

我:你现在正在看手上这本书,能同时看我手上这本么。

朋友:。。。(感觉被套路)”

我偷换了概念,把 “同时” 这个词的时间精度调低了,导致这次对话变了味。

偷换概念在生活中无处不在。《武林外传》中的秀才利用 “我”这个概念的偷换,让姬无命莫名其妙并自杀了。

相关性不等于因果性

这个是一个不得不提的诡辩手法,我们从小深受其害。

最经典的例子是,很多父母信佛,然后娃高考的时候天天去求神问佛。如果小孩考上了大学,那么就是拜佛的功劳,如果没有考上,那就是小孩不努力。多么完美的逻辑闭环,完全无懈可击。

同样的桥段在各种电视、电影中存在。某一伙人闯入了一个村子,然后这个村子发生了瘟疫,群众认为是这些人带来了不详。

程序员圈子也会有类似的议论,因为大公司都用的 Java 而不是 PHP,所以 PHP 是一个垃圾语言,我们要成为大公司,所以要把 PHP 换成 java。所以很多公司明明可以苟一下,然后因为折腾死掉了。

我们需要时刻记住,相关性不等于因果性,才能认识到一些微妙的逻辑关系。

因果倒置

“可怜之人必有可恨之处。” 这是很多人挂到嘴边的话,支持者甚多。

我小的时候对这句话记忆深刻。小学的时候被年长的同学欺负,后来因为打架老师知道了,其他同学都表明我是个被欺负的可怜鬼,老师还是对我们都做出同样的处罚。

说出了一句举世名言:“为什么欺负你,不欺负别人”。

为什么只欺负你,不欺负别人,所以你也不对,同样要受到惩罚。这是典型的强盗逻辑,从结果推导出原因,但是这个原因并不成立,因为我们知道原命题为真,逆命题不一定为真。

归纳法的局限

逻辑学上把个别的知识推广到一般的知识规律叫做归纳推理。归纳推理是一种朴素的认识方法,在逻辑学中,归纳推理有其意义,但是需要注意的是逻辑学从来没有把归纳法得出的结论当做真理。

归纳法的问题和类比谬误类似。古人认识的到了一个规律,鸡叫三遍天会亮,但是后来出去旅游发现其他地方的鸡不是这样的,真的是应了那句,“东方不亮西方亮,黑了南方有北方。”

中国太大了,甚至二十四节气的规律都不能适用于每一个地方。归纳法只能有限的反应某种规律,不能广泛、绝对的得到真理,也不能从个体推出一般。

算命先生希望从四柱八字、面相分析、掌纹、笔迹这些中归纳真理,如果认识到归纳法的局限性,就不会平白无故交这些智商税了。

责任转移

证明神存不存在,保健品有没有功效,壮阳药有没啥作用是科学界三大难题。

从逻辑上证明有其实很容易,只需要找出一个例子即可,比如证明天鹅是白色的,只需要找出一个白色的天鹅即可。但是证明黑色的天鹅不存在,是非常困难的,除非穷举世界上所有的天鹅,才能得出这个结论。

人们的思维中,天生偷懒,所以人们才会有 “宁可信其有,不可信其无”。

所以有一种诡辩,我姑且称之为责任转移,就是在辩论中把举证的责任推给别人,然后再来挑对方的毛病。这是一种非常高级且隐晦的诡辩手段。

比如有神论要求无神论者给出证据,证明神不存在,但是证明无非常困难。对方只能举出一些例子,但是这些例子非常脆弱,如果再结合偷换概念就更无懈可击了。

“大师:神会保佑你的。

无神论者:神不存在。

大师:你怎么证明神不存在呢。

无神论者:我从来没看到过神。

大师:没看到过神,不代表神不存在。

无神论者:看都没看见,怎么能说神存在呢。

大师:神是一种信念,它无处不在,慢慢体悟吧。

无神论者:。。。”

责任转移大法是不断把举证的责任推给对方,然后在挑错,让对方自顾不暇。

总结

逻辑学中的内容非常多,还有很多有趣规律,比如三段论、命题和演绎等。

但对生活来说,本文介绍的一些方法用于吵架足够了,当然不是为了学习怎么制造诡辩,而是为了分辨诡辩。当我们在工作中交流时,能注意概念的统一和尊重同一律、矛盾律、排中律等逻辑学基本要素时,沟通会变得更加高效,吵架也更加有理有据,并从中得到成长。

【本文是51CTO专栏作者“ThoughtWorks”的原创稿件,微信公众号:思特沃克,转载请联系原作者】

戳这里,看该作者更多好文

 

 

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2016-03-21 13:20:45

中国网

2009-02-11 13:15:54

软件工程师女工程师google

2015-04-08 10:34:28

软件工程师计算机书

2023-06-05 10:07:13

软件工程平台工程师

2017-11-09 14:12:44

大数据软件工程师算法工程师

2022-07-29 09:12:44

软件硬件开发

2022-04-18 10:13:32

软件开发写作

2014-08-20 10:24:11

软件工程师

2009-02-12 14:45:17

软件工程师

2013-09-03 09:30:44

软件工程师软件工程师头衔

2010-08-10 13:29:58

软件工程师

2022-09-16 08:00:00

软件工程师求职薪酬

2013-06-25 10:47:21

软件工程师软件开发开源项目

2011-05-16 10:05:33

软件工程师Java工程师

2009-02-23 11:22:29

系统架构师软件开发经验

2009-12-03 12:29:54

嵌入式软件工程师

2016-02-18 10:18:34

Java工程师面试考纲

2009-08-25 10:47:17

Delphi梦魇新病毒安全

2015-06-02 11:29:55

软件工程师程序员

2010-08-10 13:22:41

点赞
收藏

51CTO技术栈公众号