以前,我认为一个事物对我没有直接用途的时候就不会去理会它,心理学上说我们都戴着自己的认知偏见的有色眼镜去有选择性地看待这个世界,纷繁的信息经过我们的认知图式过滤之后便成为少量有序的事件,所以我们都在有强烈选择性地关注一些事物和忽视另一些事物,然而,这样可能会导致丧失一些很有价值的信息,而总是将知识面停留在自己的小世界中——当然这倒也不是说看到什么都要凑上去学一学。如何在这两者中间取得折中,我觉得一个好的办法是先简略地想一下这是个什么东东,他的本质是什么,出现是为了满足什么需求,等等比较“高层”的问题(即“What”和“Why”而不是“How”),这些问题应该是可以通过简单的调研和思考得出结论的,至于背后的技术细节,如果你打算入行,就可以去学,如果不打算的话则可以免了,至少前面的思考和简单的调研能够一定程度上保证当有价值的信息或机会摆在你面前的时候你不会把眼睛蒙上走开,并且多做做这类思考对于思维的广度也很有价值。最近我开始认为,最佳的学习方法就是先广度优先遍历(先弄清What和Why),然后择最合适的分支深入(How)(算法牛人DD同学在TopLang上的一个帖子里面也提到类似的想法,刚进大学就能够如此清晰地看清前方道路的走法,我对DD很佩服)。
方法论看似是个很抽象的东西,并且的确有一些方法论是抽象到 over-generalized (泛化过度)的地步,然而说实话在实践当中我总是发现(正确的)方法论是再现实不过的东西,比如一个大家都明白的道理是:如果方向走错了,那么做的功就基本全白费了(还有比如“如果方法对头,就能事半功倍,反之可能多走很多弯路”)——然而现实中有多少人能够真正实践这个方法呢?绝大多数人都是只顾解决眼前问题,抓了这头丢了那头,更多人是不知道问题是什么,只管把头脑中能联想到的一个以前类似情况下的类似方案套用上来。以前我总是觉得一个公司里面,CEO/CTO 这样的角色是基本摆设,但我现在不这样想了。在 How 层面把事情做好,做成一个精钻的程序员,那顶多就是能把钳子使好,这样的事情很多人都能做到,熟能生巧嘛。换句话说程序员基本上是去解决一个定义好的问题,去实施一个定义好的方案。然而决策问题就不一样了,决策问题是需要去定义问题是什么,以及权衡最佳方案是什么,不管是决策技术架构还是决策商业策略,都是非常复杂的思维过程,需要综合和权衡大量的信息,这种能力就不是简单楞着头搞下去能练出来的了,很多时候需要抬起头来看,免得只见树木不见森林。(以上也是为什么我在讨论组里面一篇帖子(什么是算法?为什么学习算法?以及学到什么程度?)中提到我觉得学数学学到精通未必就会思考日常决策问题的原因——数学几乎总是去解决一个定义好的问题,用的也都是定义好的严密的逻辑推导。然而现实中的问题是一个复杂系统,诸多变量互相影响,如何权衡最佳方案实际上是一个复杂的统筹规划。更重要的是,你往往甚至都不知道问题是什么,能够从纷繁的信息中抽象出问题,是一种极大的能力。这里推荐《你的灯亮着吗?》和《失败的逻辑》)
当然,我自己还没能到这个层面,尚需要不断实践和总结,所以只能稍微的谈一点感受,再往下扯只怕就会流于空泛了。这一点上我还是举一个程序员们喜闻乐见的例子吧,在程序员眼睛里面,做一个项目,也许首先想到的是用什么语言,什么框架,什么库,在这个方向上那就是什么看上去牛B用什么,恨不能都用 haskell、lisp 来写才爽,用 Java?那多没意思啊,Java 那坨弱智语法我小学的弟弟都能掌握,也没啥牛B的语言特性,忒没成就感(只可惜真正判别弱智与否的并非用什么语言技术,而是做出什么产品满足什么需求)。这就是属于只考虑单个孤立因素的简单(或者说 Naive 的)决策,这个因素就是——只要让我自己感觉爽——只可惜并不是让自己感觉爽的做法就是真正解决问题的做法,始终要弄清问题是什么,在后者意义上,一些对于技术型程序员往往没有吸引力的话题其实有着极其重大的价值——比如什么时候设计,什么时候重构,什么时候集成,再往上一层其实这些又都是次级问题,首要的问题还是这个产品满足什么需求,有什么市场(即这件事情值不值得做),有一句话想必很多人常听说,如果不知道要做什么,套上十二层架构也无济于事,方法永远不是因,而是果(我在以前的另一篇文章“Failing to see the Big Picture – Mistakes we make when learning programming”中也阐述了类似的观点)。
再举个例子,如果我想给我的网站做一个 feature ,我认为这个 feature 技术上很牛很强大,而且刚好有机会使用一下我最近修炼的某某 framework 和某某语言,而且这玩意很有挑战性,还不是一般人能够做得了的,综合以上三点,我立时觉得心痒难耐摩拳擦掌。然而实际上这个问题应该怎样分析呢?首先,考虑到以上三点,这将会是一个投入相当大的项目,那么其收益就必须要对得起这个投入,技术上很牛不代表商业上就牛,再牛再难做的 feature 如果不能带来商业价值那就是负收益。总而言之,
1.一件事情仅仅让你感觉挺牛不代表这件事情就是值得做的;
2.一件事情仅仅让你感到很有兴趣并不代表这件事情就是值得做的。
情绪价值之外,这样的事情在本身的价值上有没有你感觉到的那么牛呢?如果你只是在削铅笔,那么何必磨一把倚天屠龙剑来?反之,如果你做的是一个本身功能很牛很创新很有价值的软件,那么语言技术其实完全是次要的,并不是看上去越眩越好,关键是选择各个方面综合考虑起来最合适的工具即可,瑞士军刀也许很丑,但对于丛林冒险很实用就行。拿着一把屠龙宝刀去野外生存,同样也不靠谱。
这两句话和我们日常的认识并不冲突,其实我们几乎总可以找到既有价值、又有趣、又有足够挑战性的工作。举个例子,本科数学学得精纯无比的同学有没有偶尔也会觉得盲目呢?做这些题目到底有什么实际用途呢?这就像是你总是在磨一把刀,磨得闪闪发光锋利无比,你可以向别人炫耀自己的刀很牛B,但是刀是为了冲锋陷阵血溅五步的,你也不想让它折戟沉沙吧,不管是将数学用在数学物理上还是用在人工智能、机器学习、密码学、通信上,都是既让人有成就感,同时又有意义和价值的事情。对我们程序员来说,你把一门语言玩得很精通,不仅知晓它所有的语法细节,陷阱和缺陷,还了解它的底层实现模型是如何。你觉得很牛很有成就感——的确,我们都会为一件自己做到了别人做不到的事情而感到自豪,然而反问一句,除了