梦想与伟大的执着——记每年放假前的脾气

由于研究生之后，感觉工程师情节的人不是很多了，就又跟老友泡在了一起，感觉也许这样可以残存一些“根本不存在”的坚持吧。事件的起因，就是这个同学给我叙述的一段事情，他是我本科时候所在的一个社团的前技术部长。

每年过年前期，一个社团的元老级人物都会给大家发一顿脾气。说是社团应该如何发展才能跟上节奏、不吃老本，真正称得起十佳社团之名。一是由于管事的学弟回答的比较认真诚恳，说是自己认真思考了两天，但是还是不知道真实可行的方法；二是每年都会有这一出，老会员也就慢慢习惯了；三是我自己的社团也就是散养政策，完全没有在意之后我们的社团发展成什么样子了，这里也为老学长的认真执着打CALL。基于以上的一些原因，我也没有站在元老这边，虽然个人关系还是跟这位老学长非常好的。我觉得这个问题就是梦想跟现实的冲突，谁不希望社团好呢，但是真正执行上就会有一些困难，而且也不是所有人都能够做到老学长那样既有大局观，又能讲课的。后来前部长给我详细的讲述了今年社团发生的事情。主要就是选主席和部长因为”只会搞技术“的原因没有选上重要技术成员，大刀阔斧改革删除了之前的老牌课程，以及讲课风格问题等。总之就是做技术的不被重视，选全才好像又是有点违背了技术社团的初衷了。这样我又觉得应该站学长这边了。

人与人之间什么算是相合呢？什么样的人算是我们的同路人呢？我觉得还是先有点技术吧，其他的真的都可以再说。突然想起美国内战时期一位好饮酒的将军了。有很多感受，不知道该如何说，可能之后会有一个比较清楚的阐述了。我下面想说说最近我想的一些可以成文的问题，可能和社团事件的关系不大了，也算是对老学长、师兄这样的能一起快乐的聊天的人的一种向往吧。也希望我能继续找到这样的志同道合之人吧。

科学精神

我这里想说的科学精神，就是指”对于理论、方法了解的渴望”，“对于工程实现的成就感”，“敢于尝试、实事求是的精神”，“了解一般的科研方法并将其用在生活之中”。下面我想逐个分析一下。

1. 对于理论、方法了解的渴望

有一个非常好的理论摆在面前，你是否有求知欲望呢。人们说小孩子的好奇心强，创造力强，长大了就被扼杀了，我觉得这不完全是社会的原因。因为除了有外界条件因素以外，自身对于世界建模的确定性也可以导致Agent使用更小的概率去探索，同样的，人也往往不想改动自己的认知模型，不接受新鲜事物可能是有理论依据的。但是谁能保持强烈的好奇心和求知欲望呢，我觉得他们就是真正应该被称为工程师和科学家的人吧。

1. 对于工程实现的成就感

项目使用高级的纠结写法，最终完成。使用自己做的软件，使用自己做的硬件，玩自己写的游戏。看自己做的麦克纳姆小车刷锅，看到自己的模型预测出自己觉得其不能预测正确的答案。在ksp中将自己设计的火箭升空。在MC中构造的各种机器和塔。这些事情给了工程师一种原始的成就感，他不来自任何其他更基础的快乐，其本身就是快乐。这种原始激动并不多，非欲望驱动的就更少了，我觉得除此之外只有求知和认可，而认可确有非常强的社会性，而求知才是能和此点媲美的。求知也是我们说的第一种科学精神。

1. 敢于尝试、实事求是的精神

有一种编程方法叫做霰弹枪编程。很多人是根本不分析一些事情的原因的，对于非科学工作者或者受教育程度比较低的同学来说呢，可能是由于很多东西已经在其理解范围之外了。就没有心情进行思考了，整个系统对于他们就是一个黑盒，真正的黑盒，不仅是透明而是的确不清楚，这就导致了可能会问出一些很奇怪的问题等。一个工程师他用到的东西可能也不能事无巨细的了解，但是，他却基本清楚设计和运行思路，这样就可以大大降低他搜索问题可能出现的位置，从而快速解决问题。所以即使细节不清楚，一些实现的trick不知道，但是大体实现和运行方式还是要清楚的。

1. 了解一般的科研方法并将其用在生活之中

我认为前三条都可以勉强算作精神，精神这种东西可以说是喜好、或者说是工程师的强迫症。若有则可畅谈，没有也可共事。但是，我觉得最后一条，是我们讨论问题的基础，是共用的推理逻辑体系，没有这个可能不能交流。我想证明 A，我说 ”B 这个你同意吗？”“恩。”“既然B，那么C，同意吗？”“为什么？”“推理不严谨或者有反例吗？”“不知道，但是我觉得不对。”。这种人是没办法讲道理的，她也听不懂你说什么。没有统一推理逻辑的讲道理不是讲道理，而是“劝说”。劝说其实和“你就同意嘛。”“你就相信我嘛。”是一个意思，只不过可能委婉一些罢了。当然此问题还会在下一节详细讨论。

然而在我们的生活中，有严谨逻辑的人不多，认同推理体系的人也不多（当然这里那些只在考试的科目上同意推理体系的人不算在内），有科学精神的人就更少了。

科学意识与方法

1. 准确的描述

讨论问题是非常受欢迎的一种社会活动，如果在讨论的时候问题都不一致就开始发表见解显然是不靠谱的。但是往往是会出现这种问题的。这时候，科学的方法是“哦，我想我们在xxx上有认识的，不同，我们应该同步一下对于xxx的定义了。” “好的，我觉得xxxx的就叫xxx。”“OK，那是我们定义不同导致的这个问题。”讨论结束。

我见过非常不清晰的问题比如：我打开这个页面他就会出问题，那个问题应该怎么解决呢？诸如此类。要知道这是一个同学直接给我微信发的话。我知道的也是这么多，基本上和现在看这个文章的你是一样的。我也是一脸懵逼。很多git仓库作者都会写no log no help，更别说这种没有报错，没有运行情况，没有环境说明，所有指代都不明，而且还给计算机拟人的问题了吧。题外：不要把计算机或软件系统成为“他”了吧。它没有意识，错误都是人犯得。这种行为感觉就跟小时候你撞到桌子上，妈妈一边骂桌子一边劝你不要哭似的。

1. 换位思考

同样的，讨论问题时要换位思考，尽量照顾对方。比如我出现了一个什么问题，尽量把问题简化，把相关业务代码删掉，仅保留最小的重现问题的代码，让别人一眼能看明白的，方便别人指出问题。同时在给别人解决问题的时候，也要尽量按照别人的思路考虑，之后给出他思路中的漏洞和问题，如果你仅能用自己的思路解决问题，而发现别人的思路找不到什么问题，却指向了不同的答案，就说明你并没有解决问题，因为对方纠结的一般是我哪里错了，而不是这个问题的答案是啥。这种情况在很多中学老师的身上非常突出，当学生问我怎么错了时回答不要使用这种方法做题。我觉得这就是一种没有科学意识的行为。

1. 设计实验与排除错误

这种概念或者说想法应该是就在我们生活的方方面面，而不是只在工作中的。使用实验解决问题非常重要。一次一个同学的服务器启动不起来了。我问她是不是端口被占用了之前的服务没有关。她给我解释了一下应该不是这个问题。因为她给我截图和描述之中这种问题的可能性很大。我就让她确认是不是这个问题，我说你把端口换了再打开试试。之后她又给我分析了10分钟，说肯定不是端口占用导致的。我已经有点生气了，我说你先按照我说的办法试一下。最终果然是端口占用的问题，之前的程序没有正确关闭。总结一下，少说多试，用实时说话，分解问题，猜测原因进行实验，修改问题。

员工的最低标准

我对于下属的最低要求就是比机器做的好一些。（虽然没有下属吧，现在想这个问题就是白日做梦，有时候总是在想一些奇奇怪怪的东西，比如……参见《重大灾害及挫折应对与解决办法》）我觉得这个标准不高，因为我雇佣了这个雇员，他总应该发挥其作为人的一些功能吧。否则为什么不在电脑里面跑一段程序呢。不要说在很多方面人不如机器，但是作为一个员工，作为老板我也肯定不会限制不让你用机器的，员工 + 机器 > 机器，这个我觉得是我雇佣的标准。

具体的体现在，不要让我给员工编程。想象场景，员工甲来问我 A 这个事情怎么办，我提供指导思想 B 或者 先 C 后 D，又问 B 这个事情应该怎么做，我说 应该 E F 这样做。如果 E F 中包含比如“把这段复制到这段”、“打 xxxxx 指令”、“把 n 行 改成 xxx”之类句式，说明我说的太详细了，简直跟我亲手复制、亲手打指令、亲手改一样麻烦，那么我觉得机器应该比你做的好。你可以走了。

当然人还有另外两中错误，一是你说 A 的做法是 B 或者 先 C 后 D，之后他做了 B C。理解偏差，这是一个要磨合的问题，我觉得如果是歧义是可以理解的，但是不要与大多数人的理解不一致，并尽量与同事磨合；对于实在听不懂人话的，那也没啥办法，只能是您的想法非常犀利，我们公司跟不上了。人能够犯的另外一种错误是忘记，后来有来了 A 问题，就会又问你，或者做了 G 操作，人确实不擅长记忆，我希望你能合理利用机器来帮助你。