Beyond Question--后端程序员的反抗（1）

要是有什么方法能省掉动脑筋这档子真正的体力活，人们断断不会放过它。
--- Joshua Reynolds

目录：

引子：

之前翻看过一本书，介绍批判性思维的。中文书名是：《超越感觉--批判性思维指南》

当时看的是英文版，仅仅是翻看了，有很多都看不懂哈哈哈。

他的英文名是 《beyond feelings-- A Guide to Critical Thinking》。

从书名，望文生义一下就是大概讲要培养出一种批判性的思维，不要凭感觉。。

Beyond Question也是取自于此，就是面对一个问题的时候，不要急于去回答，因为这样很有可能会被问题本身限定住了。

先要抽身出来，Beyond This Question超越这个问题，最后往往能发现关键点不在这个问题当中，方能真正解决问题。

引例1：关于买早餐

每天在早餐店买单的时候，收银员总是会问：“要不要来杯豆浆？”
这个问题暗地里限定了两个答案：

• 要杯豆浆
• 不要豆浆

如果收银员换个问法：“来杯豆浆还是来碗粥？”，
问题虽然看似差不多，但限定的内容不同了，变成了：

• 要杯豆浆
• 来碗粥

小结：

不谈一些关于顾客购物的心理分析，可以先做出个简单的猜测：

用后者的问法(句式)所得出来的营业额会更佳，而这仅仅是因为一个问题的限定造成的。
如果你能Beyond Question一下，maybe你就能不会过度消费了。。。

so,进入正题，看看在日常怎么用beyond question来找到问题的真正所在。

Beyond Question--backend programmer's fight：

基本情况：

在公司，我负责的是用Python做后端.
一般是我先写完后端的程序，调试好了后，提供接口(api)和数据给前端整合到云平台中使用。

其中，充当产品经理的boss还要负责协调前后端的沟通。

一个新功能放到上线的系统后，bug就会随之而来。

出现bug后，boss和前端会叫我过去。
不止一次。。。他们会大声跟我说：

• 怎么你的程序又出错了？你过来看报错
• 你写的是什么api?
• 为什么你把api端口设为10086？
• 。。。。。

一般我都会回答：

剑拔弩张的一次：

有一次赶着将新写的漏洞扫描器上线，我写完交付给他们之后
他们还是照旧把我叫了过去。。。

由于赶着上线，他们就急匆匆凶我：

• 你的程序出错了！快看这是什么错。。！
• 你写的是什么api?怎么一下子程序就报错了？！一下子就断了？！。。

关键的地方来了，Boss和前端把问题定位在我的身上和我写的程序上。

他们的斩钉截铁，一开始让我也以为是我的后端程序与数据库那边的问题。。

我看了下报错，是一个socket报错，然后赶快google了一下。

这个时候，前端觉得不关他事，就下去吃饭了，而boss觉得是我的后端程序与数据库的问题，在一顿操作改我的代码。。

反击--beyond question：

查了下资料后，我beyond question，定位问题不在他们提出来的地方

然后我说：

• 问题不在后端程序的上面，而是前端在请求api的时候，等待的时间太短了，api在接受到请求后，还没来得及处理请求，就中断了与api的通信，这就是为什么api断掉，然后就不能接受任务的原因了。

boss听了后，将信将疑，继续改我的代码。他觉得问题还是出在后面。

结果：

最后的问题解决了，确实是前端在请求api的时候，等待时间只设置成了3s，改成8秒后，与api的通信就不会那么快就断掉了。

当然，我的程序也有一点问题需要改，boss定位的地方还是不全错的。

下次要谈谈在boss身上学到用必要性思维怎么快速解决问题。

总结：

“同一层面的问题，不可能在同一个层面解决，只有在高于它的层面才能解决。”
--- Albert Einstein

面对一个问题的时候，不要急于去回答，因为这样很有可能会被问题本身限定住了。

先要抽身出来，Beyond This Question超越这个问题，重新定义、定位、理解问题的根源。

(这当中涉及到理解的大局观，此处就先不展开谈了。)

最后往往能发现关键点不在这个第一次提出的问题当中，方能真正解决问题。

未详细谈到的：

• 理解的大局观
• 必要性思维

挖坑。。。之后填。。

关键词：

• Beyond Question超越问题
• 问题的层面

参考：

• 《影响力》
• 《超越感觉》