解决问题的第一步，也是最困难的一步就是发现问题。
所以这一篇，就是一个发现问题，然后确认，再尝试去解决的一个记录。
有一句话，叫做“我懂得很多道理，却依然过不好这一生。”
最近讲了太多关于“讲道理”这个事情，几乎快要替代“做正确的事情”在我心中的标杆地位了。但是最近的一些事情和思考，另外重新开始考虑，然后很显然的发现，“讲道理”并不一定是“正确的事”，所以“讲道理”其实只是一个解决问题的方法，并不能成为一个信条和根本驱动，在这个事情上，“讲道理”这件事情，太具体了。
想一想为什么会发生这样的事情呢，也许和这段时间的管理培训相关吧，因为在思考这样的问题，急于想找出一种方式向他人表达自己的观念，并且自认为找到了（“所谓讲道理的事情”），而且还觉得很有效，于是不由自主，不知道什么时候开始，自己不讲到底得开始强调“讲道理”了，在向别人一遍遍重复的时候，也对自己一遍遍重复。然后发生的事情，戈培尔已经告诉大家了。
现实世界中，发现了“万物理论”这种好事情是不会发生的，如果感觉发生了，可能就是错误的开始。
当然，一个你自己都解释不清楚的“万物理论”倒是没问题，比如我的“做正确的事情”。一个混沌的理论也就无所谓“遵守”。
说回具体的事情。
一直以来的行事方式都很简单粗暴：排除限制，解决问题。大部分的事情的限制其实都来自于自己，所以只要你“不要脸”，很多问题的解决其实都很容易，实际上也不需要什么特别的技能。所谓光脚不怕穿鞋的。
解除限制的过程，也是个拼命思考的过程。现实中的限制，往往都不那么显而易见，打破常规是必须的。这样的拼命思考，又带来一个问题：想太多。这个副作用其实不大，用“小心谨慎，深思熟虑”的说法就可以很轻易的说服自己。“至少想多比没考虑到要好嘛”。而问题的复杂和混沌，实际上也必须要依靠更加复杂和多层的思考，才能所谓“抓住本质”。“抓住本质”，变换问题，寻找真正需要解决的问题，可以说是最简单有效的方法了。
毕竟，只要问题在不断解决，其他的都不是事。甚至战略上的懒惰都能轻易的被战术上的成功掩盖。
并且，按照这个简单的逻辑，实际上也能发挥极大的杠杆率，让你成为环境中最能解决问题的那一个。习惯于自己解决问题。也确实的难以依赖他人。
追求正确性+讲道理带来了一个问题，就是难以让别人接受观点与帮助别人成长。换句话说，不好带人。这是一个我长期发现，但是难以接受以至于有点逃避的问题，事实上说，我其实不擅长带人，或者说是确实没有成功帮助别人成长。之前我也给自己提出了很多理论解释这个问题。从早期的寻找各种方法，到后期的觉得“就是不行”。但是实际上现在看来，原因很简单，“道理”这个东西，就是屁股决定大脑的，每个层级上需要解决的问题不一样，所以讲的道理也实际上是不一样甚至是截然不同的。而我的追求正确性，一个是让我经常没法花时间去讲道理（需要尽快解决问题），二是，讲出来的道理都过于“正确”，可能对特定对象来说就反而不是最佳的了。
这些问题，在早期其实并不会有太大的影响，而且对实际的发展很有帮助。甚至我依然觉得能有今天，之前的方法和方向还是对的。
（此时此刻，想太多的问题依然影响着我，每想到要写一段，就会想写10个背景知识说明为什么会产生这样的情况，以及为什么在当时是正确的，然后再说明10种情况下的变体，然后思绪就飘忽到天国去了）
但是到了现在，我必须要承认，在实际事情上的能力，我已经不如团队了，最基本的事情，原来可能我写的代码是最不会出bug的，最近发现，写的所有的地方，过段时间都能看到被修复的commit。而从团队的立场上，是不能把我考虑进项目流程中的。我对于团队就像是个网上认识的对项目很感兴趣，想要义务帮忙的热心网友。对于这种情况，我的观点一直很明确——再强都不能要，或者必须要有非常明确的隔离，并且不能有任何预期。事实上，团队也是这样对我的（当然正确，当然，也令人沮丧）。这样，对我来说最困难的情况就发生了——
我发现我不能靠参与项目来获取信息，让自己进步，但是我现在所在的职位要求我应该有巨量的信息并且做出决策。突然就死循环了。
意识到这个问题的时候，我的第一反应是这不讲道理。我能力不足我承认，但是我一直都很努力的从项目中学习，希望经历跟进项目的过程，能够成长。但是根据上述逻辑，其实我被禁止了这样做，这相当于要求我成为一个架构师，却不许自己写一行代码？甚至看别人写都得小心谨慎，因为很容易围观的时候一句话，造成未知的影响。
最绝望的问题在于，实际上自己是没有得选的，最终必须要解决问题。
真正意识到这个问题的沮丧感还是挺打击人的，首先从道理推断这些都是对的，那么我之前的行为就是个巨大的用“战术上的勤奋掩盖战略上的懒惰”。而且我过去一直以为自己只是用这种方式来度过一下低谷期，现在想来，其实我根本就没有在自己的职位上做正确的事情，我只是纠正了一些显而易见的错误，然后做了一些显而易见正确的决策，然后就安心的继续把自己当成一个优秀的程序员了。
想清楚道理，认错并不困难，困难的是然后怎么解决。虽然事情依然困难，但是已经知道了问题，至少就有很多方向可以去尝试了，首先我第一反应就是觉得可以去问人，第二天，我去找了Kiro。
Kiro那天很忙，下午开了很长的会后还跟我聊了很久，真的是很感谢，结论上说，我感觉很有帮助。
Kiro的观点是，我的根本目的是为了让事情做成，那么项目只是公司发展的一个部分，并且帮助项目做成的方式不一定是要靠直接影响项目，甚至直接写代码。眼界开阔一些，必须要承认有些事情就是没法控制的，也不可能控制所有事情。就算之前的经历让我有“事情最终都还是要靠自己解决的”，还是依然要再试一次。
我之前的观点在于，我直接影响项目，是最直接有效来确保达成目标的方法，但是事实上却是不一定是最好的方法，影响总会分积极和消极。这段时间的很多纠结都在于，我想确认到底这个影响是积极还是消极，以及没法说服自己，真的不这样做。有可能我回家躺着是对项目最好的方式，但是我又如何才能让自己确认真的是这样呢？
所以到底我还是没有确认这一点，但是Kiro的话让我发现了其实却是我还是有很多可以做的事情，可能过去是我不喜欢的，但是跟现在这种纠结的心情相比，那我就宁愿去做这些事情了。既然我事实上对现在的团队有着确实的信任，那何必想太多，一定要把道理讲到“100%”呢。
虽然我懂得很多道理，但是道理之上还有meta-道理，一件事情在这个角度符合自己的道理，在另一个角度可能就违反了。其实道理对自己来说，更像是一个让自己心安的借口。所以“讲道理”这件事情，还是应该让它去适合自己的地方——用于统一集体的文化价值——上去发展吧，束缚自己，就成了真的“不讲道理”了。
发表回复