能编程与会编程

几个月前因为一个事情被怼了。起因是项目临近上线，后端统一了消息协议（.proto），然后要求前端也支持。我研究了一天，没走通——要么依赖项太多，要么一直报错，而且需要的对象兼容性也有问题。当时心里有点急，对这个方案也带着几分抵触，于是在会上说了我的想法：能不能友好地发发 JSON，兼容性好，也不需要什么第三方解析。结果自然是被否决了。理由很简单——大厂出品的东西，怎么可能用不了？用屁股想想也知道吧？你怎么遇到问题就想退缩呢。我一时无言以对。但那次对话让我印象最深的一句话是：能编程与会编程，是两码事。

开完会情绪有点低落。回到座位上继续打开 GitHub 找方案，没多久居然找到了。啪啪打脸的感觉确实酸爽。然后我开始认真想这件事。

是否抵触

带着抵触情绪去处理一件事，那基本做不好。找方案的时候，眼睛里只看到“NO”，自动忽略了“YES”。解决方法就在你眼前，你也未必看得见。就像一个人不想做事就找借口，这些借口在他自己看来都很合理。所以，如果情绪没处理好，不如先别开始。要么自己消化掉，要么拿出更好的方案去说服别人。

只要有一种解释是对自己有利的，我们便不想去推敲和反驳，再漏洞百出的事情看上去也不无可能。而且只要一种解释是可能的，我们就认定是一定的。强大的情绪大脑会阻止理性大脑往深处去想。而对于自己不利的解释，我们或忽略，或者异常仔细地去推敲，抓住一个漏洞就相信自己推翻了所有的解释。——《暗时间》

所以，动手做一件事之前，先把情绪理清楚。很多时候摆在我们面前的方案很多，如果是你熟悉的领域，当然好选，利弊清晰，能快速判断。但如果不熟悉，就要注意每个方案所适用的环境和条件。要归类和总结，因为你遇到的问题本身，就已经提供了不少前提条件。用这些条件先过滤掉一部分方案，而不是瞎猫抓死耗子一样一个个去碰。

另外，尝试新东西的时候，总会遇到各种困难。不同的碰壁次数之后，不同的人会选择退出。用程序员的话来说，大家都在 for 循环里，区别在于你在什么条件下 break。有的人退出阈值高，能坚持；有的人阈值低，早早就退了。过早退出的原因，往往是对未来的不确定，对投入时间无法收到回报的恐惧。其实再坚持一下，再想一想，答案可能马上就出来了。

不要等待

编程工作中，我们经常遇到需求不完整、接口文档没有、接口返回值错误之类的问题——都是别人的因素，然后导致项目进度缓慢甚至停滞。但话说回来，编程其实已经算是很轻松愉快的工作了，因为还有人给你提供需求、设计稿，你只管实现就好。实际生活中，很多事情根本没有人会告诉你该怎么做。比如自己装修，你需要定风格、选材料、按流程找施工队，还要考虑风格和成本、材料合不合适、喜不喜欢、甲醛高不高……建材市场鱼龙混杂，装修师傅可能阳奉阴违。就算你亲自监工，他都敢用料不够，总有一款能让你交点学费。更别提如果刚好很忙，父母又生病了……生活中的事，更考验人的协作、沟通和承压能力。没有人告诉你截止日期和责任，但你没做好就是没做好，别说什么“装修的人坑了我”。工作上的事，责任范围清晰，不属于你的锅你可以甩得远远的。但如果团队内部都是这样的氛围，那又能成什么事呢？雪崩的时候，没有一片雪花觉得自己有责任。还是应该积极主动起来，因为等待，耗费的终究是自己的时间。

做完了还是做好了

按照需求和效果图，你可能很快就实现了所有功能和效果。但是，自己测试了吗？可用性高吗？稳定吗？兼容性怎么样？功能做完，往往只是到了一个阶段，后面还需要自己做检验性的工作。确保交出去的东西是 OK 的，能达到预期。要敢于对别人说“我做好了”，让人用得放心，而不是说一句“我做完了”，暗藏的坑让别人去踩。有时间的话，还应该思考一下：代码能不能更简洁？接口设计能不能更简明？多个类似的方案能不能统一成一个产品？思考的价值，终会为你省下未来的时间，尤其是重复劳动的时间和遇到问题沟通的时间。

知识体系完善

你选择的方案，都是你已知的方案。也就是说，你的知识范围，决定了你的处理能力范围。甚至有些知识你知道，但关键的时候却未必想得出来。这个过程就像解题，自己苦思冥想不得其解，看到答案又恍然大悟。为什么呢？你的大脑就像一个图书馆，知识的碎片就像书架上的书。你想用的时候，却发现找不到它在哪里了。

知识分两种：一种是我们通常所谓的知识，即领域知识；另一种是关于我们大脑吸收知识的机制的知识，后者不妨称为元知识。虽说这也是领域知识，但跟其他领域知识不同的是，它指导我们学习其他所有的领域知识。

除了完善我们的领域知识，也许还需要补充一些其他领域的知识，比如心理学和思维方面的，当然最好是到生活中去解决问题。

小结：会编程是基于现有经验办事的能力，而能编程是对整个事情的解决能力。在学习一门技术的成本差不多的情况下，差别就来自于编程之外的能力。