作为一个不会写代码的人，看到 CODE 这个词总是望而却步。
但前一阵看《代码经济》有了新的启发，因为书上举了两个 CODE 的例子，发现其实从计算机尚未发明前，人类就开始写 CODE 了 ，比如：
- 菜谱就是代码，照着菜谱的步骤烹饪，最终应该能得到和菜谱上差不多的食物。
- 城市就是代码，地铁按照规律停靠；垃圾总是有人处理；堵车总是定时出现。
其实 CODE 并非只指代代码，其实也有法规、规范的意思。
从这个角度来看，其实我们每个人都拥有创建「 CODE 」的能力，从个人习惯到工作中的 SOP。但多数时候我们却没有将其完整记录下来，也容易忽略了背后的巨大价值。
01可重复性：别只关注结果，忽略构建过程
我从未就绘画写过任何一行代码。
毕竟是艺术创作，大家关注的都是最终的作品，至于过程如何，拼的都是「灵感」。许多时候真的是灵光一闪，妙手偶得之，基本上不会重复，也不可能重复。
比如这个以前无锡梅园校区门口的树林，记不清楚当天发生了什么，反正就是似乎有点悲春伤秋的情绪，然后一个人背着画架跑到门口去装 13 的写生。虽然从未用过水彩，但是居然整的像模像样 —— 但这也是我唯一一张水彩画，也是唯一一张大学时代的速写。
妙手偶得之，但不可再重复。
如果一辈子走艺术家路线，或许还行。但是后来机缘巧合进入了游戏公司，就发现这种灵感式的创作会让人很崩溃，因为在完成一个作品之前，需要有一系列标准的步骤：
- 需要先阅读策划写的场景
- 根据文案寻找对应的设计资料
- 根据主美的风格绘制场景的三视图，效果图，以及细节描述
- 绘制完成后根据要求命名并导出到指定公共文件夹
如果说程序员最想拍死产品经理，那么原画师最想拍死的就是策划。因为鬼知道他写一句波斯风格我们要找多少资料研究。但慢慢地发现，曾经以为要花费最多时间的绘画过程，让位给了素材寻找，风格探讨，以及完成三视图的修订 —— 因为最终我们要完成的是一整个世界的设计，必须能不断地在一套规则下重复，再重复。
其实这种重视结果，忽略过程的习惯迄今也有。
比如在设计 flomo 第一版视觉的时候，大概也就一天时间。但其中充满了许多随机性偶发性的设计，用来当第一个版本没有问题。但是当 flomo 的设计规模逐渐扩大之后，事情往往就会失控：
- 考虑中文版和英文版了么？
- 考虑黑暗模式和普通模式了么？
- 考虑付费和未付费的区别了么？
- 考虑安卓/iOS/Web 之间的统一性了么？
- 考虑旧版本的兼容性了么？
- 考虑和其他规则之间的冲突或者耦合了么？
这里很感谢 @Light 帮我擦屁股。但时间长了就发现，是自己着急得到结果，而忽略了构建得到结果的过程。短期看效率是很高，但是长期来看做类似的事情反而效率是极其低下的 —— 输出不稳定，且还会丢三落四（为此我曾写过：把碗刷完，空干，放回到柜子里）。
如果一件事情要经常重复，最好写下生产它的代码。
02高效执行：不假思索的做事
不要相信自己的记忆。当设计完构建的过程后，遇到同样的问题，只需要把对应的代码拿出来执行就好 —— 我们常说一个人有「原则」，其实就是他遇到相同的问题时，有一套标准的处理方式。
那为了每件事都去设置一套代码，会不会太复杂了？
答案是：会。因为这和设计产品非常类似，如果不抽象出模块和流程，一事一议，那么就会造成大量的代码冗余，也会让可复用性变得极差。
比如「休息」这件事，曾经给自己定了很多的规则，比如周末尽量不谈工作上的事；比如打游戏不要超过一小时；比如要每天早睡觉等 —— 放心吧，脸都被打成猪头了，没几个能遵守下来的。因为这些代码写的太琐碎太特例，抽象程度不够。
最近一段时间调整了下这些规则，只剩下一条关于保证睡眠的：只要没有要死人的事情，晚上十点关电脑上床，其他事情明天再说。
因为从休息的角度来说，如果不能保证睡眠，我的情绪和效率都会很差。其他那些就算优化的再好也不解决问题。而另一方面，这个代码判断条件又足够简单，非常便于不假思索的执行。
从这个角度再来看《原则》这本书，就会发现其底层逻辑，就是一整套工作和生活的代码集，并且「诚实」是最底层的核心代码。
所以花点时间构建自己人生的基础代码，还是很有必要的，能省去许多困扰人的事情。做其他事情亦是如此。
如果想要提高决策效率，需要花时间设计自己的底层代码。
03可扩展性：规模化你的能力
虽然写了五年产品沉思录，但是前一阵才完成了第一版写内容的原则（五年时间，五条写内容的原则）。在此之前，所有的内容选择都依赖我们两个人的「感觉」。
这期间其实也有不少人投稿，但是因为我们并没有时间停下来修订原则，继而也无法给出明确有效的反馈，对方也无法修改，只能作罢。
除此之外，随着订阅用户越来越多，基础运营的问题也会逐渐暴露出来。比如每周要在 N 个地方更新，客服问题从一周几个变成了一天几个，残破的运营体系摇摇欲坠，每次都告诉自己要提高效率，但是奈何体力是在有限，肝不得。
其实问题都在于，我们没有把已有的能力代码化，所以无法将这些能力复制到其他人身上，只能事必躬亲；而事情越来越多，时间却不会变多，所以为了结果更加忽略过程的构建，最终进入到一个负循环中。
除了时间之外，其实构建代码的过程对自己的能力要求是更高的。比如有些内容的选择有一些随机性和主观判断，这些在自己操作的事情不是问题，因为有「直觉」在。但是这些模糊的东西如果不搞清楚，交给越多人执行，出错的概率就越大。而最终也会因为这些模糊的东西引发更多的冲突。
如果想要扩展自己的能力，最好将真正懂的部分写成代码，并交给他人执行。
04小结
每个人都能构建代码，一条规则，一种方法都是。
- 构建的意义在于让我们能以某种标准快速执行，稳定输出，以及可以把自己的能力扩展到更多的地方。
- 构建的难点在于，需要我们真正理解得到结果的每个过程，并且需要花费额外的时间来设计和迭代这个过程，以及进行足够的抽象和提炼。
英国著名哲学家 怀特海 说过：
文明的进步，就是人们在不假思索中可以做的事情越来越多!我想个人和组织的进步，也大抵如此。