把手绑在背后没有说明书拼高达

解决问题的第一步,也是最困难的一步就是发现问题。

所以这一篇,就是一个发现问题,然后确认,再尝试去解决的一个记录。

有一句话,叫做“我懂得很多道理,却依然过不好这一生。”

最近讲了太多关于“讲道理”这个事情,几乎快要替代“做正确的事情”在我心中的标杆地位了。但是最近的一些事情和思考,另外重新开始考虑,然后很显然的发现,“讲道理”并不一定是“正确的事”,所以“讲道理”其实只是一个解决问题的方法,并不能成为一个信条和根本驱动,在这个事情上,“讲道理”这件事情,太具体了。

想一想为什么会发生这样的事情呢,也许和这段时间的管理培训相关吧,因为在思考这样的问题,急于想找出一种方式向他人表达自己的观念,并且自认为找到了(“所谓讲道理的事情”),而且还觉得很有效,于是不由自主,不知道什么时候开始,自己不讲到底得开始强调“讲道理”了,在向别人一遍遍重复的时候,也对自己一遍遍重复。然后发生的事情,戈培尔已经告诉大家了。

现实世界中,发现了“万物理论”这种好事情是不会发生的,如果感觉发生了,可能就是错误的开始。

当然,一个你自己都解释不清楚的“万物理论”倒是没问题,比如我的“做正确的事情”。一个混沌的理论也就无所谓“遵守”。

说回具体的事情。

一直以来的行事方式都很简单粗暴:排除限制,解决问题。大部分的事情的限制其实都来自于自己,所以只要你“不要脸”,很多问题的解决其实都很容易,实际上也不需要什么特别的技能。所谓光脚不怕穿鞋的。

解除限制的过程,也是个拼命思考的过程。现实中的限制,往往都不那么显而易见,打破常规是必须的。这样的拼命思考,又带来一个问题:想太多。这个副作用其实不大,用“小心谨慎,深思熟虑”的说法就可以很轻易的说服自己。“至少想多比没考虑到要好嘛”。而问题的复杂和混沌,实际上也必须要依靠更加复杂和多层的思考,才能所谓“抓住本质”。“抓住本质”,变换问题,寻找真正需要解决的问题,可以说是最简单有效的方法了。

毕竟,只要问题在不断解决,其他的都不是事。甚至战略上的懒惰都能轻易的被战术上的成功掩盖。

并且,按照这个简单的逻辑,实际上也能发挥极大的杠杆率,让你成为环境中最能解决问题的那一个。习惯于自己解决问题。也确实的难以依赖他人。

追求正确性+讲道理带来了一个问题,就是难以让别人接受观点与帮助别人成长。换句话说,不好带人。这是一个我长期发现,但是难以接受以至于有点逃避的问题,事实上说,我其实不擅长带人,或者说是确实没有成功帮助别人成长。之前我也给自己提出了很多理论解释这个问题。从早期的寻找各种方法,到后期的觉得“就是不行”。但是实际上现在看来,原因很简单,“道理”这个东西,就是屁股决定大脑的,每个层级上需要解决的问题不一样,所以讲的道理也实际上是不一样甚至是截然不同的。而我的追求正确性,一个是让我经常没法花时间去讲道理(需要尽快解决问题),二是,讲出来的道理都过于“正确”,可能对特定对象来说就反而不是最佳的了。

这些问题,在早期其实并不会有太大的影响,而且对实际的发展很有帮助。甚至我依然觉得能有今天,之前的方法和方向还是对的。

(此时此刻,想太多的问题依然影响着我,每想到要写一段,就会想写10个背景知识说明为什么会产生这样的情况,以及为什么在当时是正确的,然后再说明10种情况下的变体,然后思绪就飘忽到天国去了)

但是到了现在,我必须要承认,在实际事情上的能力,我已经不如团队了,最基本的事情,原来可能我写的代码是最不会出bug的,最近发现,写的所有的地方,过段时间都能看到被修复的commit。而从团队的立场上,是不能把我考虑进项目流程中的。我对于团队就像是个网上认识的对项目很感兴趣,想要义务帮忙的热心网友。对于这种情况,我的观点一直很明确——再强都不能要,或者必须要有非常明确的隔离,并且不能有任何预期。事实上,团队也是这样对我的(当然正确,当然,也令人沮丧)。这样,对我来说最困难的情况就发生了——

我发现我不能靠参与项目来获取信息,让自己进步,但是我现在所在的职位要求我应该有巨量的信息并且做出决策。突然就死循环了。

意识到这个问题的时候,我的第一反应是这不讲道理。我能力不足我承认,但是我一直都很努力的从项目中学习,希望经历跟进项目的过程,能够成长。但是根据上述逻辑,其实我被禁止了这样做,这相当于要求我成为一个架构师,却不许自己写一行代码?甚至看别人写都得小心谨慎,因为很容易围观的时候一句话,造成未知的影响。

最绝望的问题在于,实际上自己是没有得选的,最终必须要解决问题。

真正意识到这个问题的沮丧感还是挺打击人的,首先从道理推断这些都是对的,那么我之前的行为就是个巨大的用“战术上的勤奋掩盖战略上的懒惰”。而且我过去一直以为自己只是用这种方式来度过一下低谷期,现在想来,其实我根本就没有在自己的职位上做正确的事情,我只是纠正了一些显而易见的错误,然后做了一些显而易见正确的决策,然后就安心的继续把自己当成一个优秀的程序员了。

想清楚道理,认错并不困难,困难的是然后怎么解决。虽然事情依然困难,但是已经知道了问题,至少就有很多方向可以去尝试了,首先我第一反应就是觉得可以去问人,第二天,我去找了Kiro。

Kiro那天很忙,下午开了很长的会后还跟我聊了很久,真的是很感谢,结论上说,我感觉很有帮助。

Kiro的观点是,我的根本目的是为了让事情做成,那么项目只是公司发展的一个部分,并且帮助项目做成的方式不一定是要靠直接影响项目,甚至直接写代码。眼界开阔一些,必须要承认有些事情就是没法控制的,也不可能控制所有事情。就算之前的经历让我有“事情最终都还是要靠自己解决的”,还是依然要再试一次。

我之前的观点在于,我直接影响项目,是最直接有效来确保达成目标的方法,但是事实上却是不一定是最好的方法,影响总会分积极和消极。这段时间的很多纠结都在于,我想确认到底这个影响是积极还是消极,以及没法说服自己,真的不这样做。有可能我回家躺着是对项目最好的方式,但是我又如何才能让自己确认真的是这样呢?

所以到底我还是没有确认这一点,但是Kiro的话让我发现了其实却是我还是有很多可以做的事情,可能过去是我不喜欢的,但是跟现在这种纠结的心情相比,那我就宁愿去做这些事情了。既然我事实上对现在的团队有着确实的信任,那何必想太多,一定要把道理讲到“100%”呢。

虽然我懂得很多道理,但是道理之上还有meta-道理,一件事情在这个角度符合自己的道理,在另一个角度可能就违反了。其实道理对自己来说,更像是一个让自己心安的借口。所以“讲道理”这件事情,还是应该让它去适合自己的地方——用于统一集体的文化价值——上去发展吧,束缚自己,就成了真的“不讲道理”了。