正文
原文：Don’t Learn to Code — Learn to Automate
别学写代码——学学自动化。
有人记得几年前纽约市长决定学习编程这回事吗？那会儿可真让人热血沸腾。我记得除了纽约市长，连 NBA 热火队的前锋 Chris Bosh 都在鼓励孩子们为了诸如人类利益之类的理由去学写代码。一时之间好像每个人都应该放弃除了写代码之外的其它愚蠢追求，去学点 Ruby 啊什么的。毫无疑问，如果 Andy Warhol 在 2012 年还活着，他会说「在未来，每个人都会写 15 分钟代码。」[1]
Jeff Atwood 对当前这种思潮写过一篇有趣的反驳文章，题为请不要学习编程。这则篇幅不短的文章表达了些有趣的观点，但总的来说主题似乎是「不要把写代码当作目标，应该去学习怎么解决问题」。我觉得这个观点很棒，但除此之外还想说点别的东西。
过去我写了一些关于做一个解决问题的人有多重要的文章，甚至表达过我对「问题解决者」这个称号的热爱。所以请别以为我不同意他的观点，即许多程序员过于纠结代码的细节。——我也认为这是个很常见的问题。但同时，我认为在纽约市长、Chris Bosh 这类人身上还有 Jeff 没有提及到的问题。具体而言，世界的技术性大大提高，这意味着相当多的工作将会被自动化淘汰，而剩下的工作则需要人不断提高技术能力。我的未婚妻是一个文案编辑，她就发现如果懂一点 HTML 和 CSS，各方面工作都会轻松不少。
现在有些人抱着发财或者仅仅是写很多代码的念头漫无目的地学习着编程语言，对这种现象我和 Jeff 一样，不认为简单地说「除非你是认真的并且愿意花时间投入，否则就别学了」有啥用。技术的快速发展创造了一个知识的黑洞，甚至吸引了本来无需关注它的人。
我有一个建议可以给这个问题做一个很好的区分——不是每个人都需要学习写代码，但每个人都应该学习和理解如何自动化。就算不去自动化，你至少可以判断出哪些东西可以自动化，然后对是否有必要自动化进行点有意义的讨论。
现实生活中的自动化
最好还是举个例子。比如今晚我和朋友正一起把一些课程材料做成 PPT，PPT 的大部分内容是图片，边边角角则散落着一些大字体的单词。我们把图片粘贴到 PPT 的界面，调整了下大小，然后用 Mac 的触控板费力地把图片居中。有次我朋友说「软件里应该有些快捷键把东西按垂直或水平居中才对，你可以试试。」
朋友们，这就是「自动化」观念的萌芽。在做 PPT 时把一个东西居中正是那种无脑又令人抓狂，还费时间的任务，这正值得拿来自动化。你知道这有多繁琐——用细微的操作把一个图片之类的东西拖来拖去，希望看到那条表明它在中间的线。这条线真难找啊……等等，那儿！完了，过头了，退回去再试一下。
当然这还没完。我倡导的——精明的自动化人才，还会进行下面这些评估且最终拥有自动化的潜能。
软件是否已经提供了这种功能，只是我们不知道？
经过一番搜索后发现答案似乎是否。如果有的话，一篇关于 PPT 的秘密的博文应该只需要两行来讲解决方法：「第一步：找到那个秘密；第二步：没有第二步。」
不过，有可能我们查找得还不够仔细呢？
值得多做研究吗？
现在不行，PPT 都快做完了。但从长远考虑，确实值得研究一下。
长远点看，这对我们来说值得吗？
很难讲啊。我也不确定这一辈子会浪费多少时间在 PPT 的图片居中。可能会有一些，但我也不是很常用 PPT 啊，可能好几年累积起来也不过几小时，而解决这个问题搞不好会花上数倍的时间。
长远点看，这对人类来说值得吗？
嗯……这点差不多可以肯定。即便我要做好几年 PPT 才会在居中这件事情上浪费一两小时，但把所有 PPT 用户加起来，每秒都可能会有数个小时被浪费。搞不好现在就有许多人一边做 PPT 一边因为居中问题骂娘。
如果我们成功了，我们可以卖掉它吗？
额，不好说呀。这玩意也许太微不足道了。但或者我们也可以把它贡献出去获得一些声誉。
好的，那么下一步怎么办？
让我们先把这当作低优先级任务收集起来，再找个空闲时间好好研究下——比如机场候机时。先定一个临时目标，看看我们能不能在限制的条件下搞定它。比如仅仅在一张空白的 PPT 页面上，通过快捷键「Ctrl+E」能不能达到水平居中的效果？如果可以的话，能不能再找到一种快捷键来垂直居中，再通过某种方式将这两个快捷键连接起来？如果这条路走得通，那么只需要做一点配置我们的问题就解决了！然后我们可以进行一个简单的测试，看看能不能达到点击一个快捷键，在一张空白的 PPT 页面上实现图片垂直及水平居中的效果。如果测试成功，我们可以稍微陶醉下，写篇博文，然后继续试试其它方案。
穷人写代码的方式？[2]
好吧，上面这段解决方法只是我的胡说，但我想借此指出一些事情。首先是识别出一个繁琐的任务和自动化方案。在做 PPT 的这个例子，找到某物的中心坐标显然最好靠计算机来做。随后的一系列问题包括可能已有解决方案了，再造新轮子有点不划算，或者我们在新方案上花的时间远超过它能达到的收益……这类考虑在软件开发中有各种名称，像是「需求分析」「迭代冲刺」……
然后，我们制定一个暂时的计划和一些风险规避策略。我们可以稍微投入一点精力看看我们能做什么，但注意要有所限制以免离题太远。还有一个具体点的战略——把大的任务分割成一些小的，可执行的，能让我们不断迭代的任务。这在软件开发领域称作「敏捷方法」。最后，尽管没有编写实际的代码，我们也有了实施和对成功清晰、可验证的描述。在业务领域这被称为「验收测试驱动开发」（ATDD）。
但忘掉这些术语吧。更重要的是，成功的软件开发项目——涉及代码、IDE、编译器等的项目——只是成功的自动化项目里的特例。你完全可以不编写代码自动化各种任务，甚至一些很特殊的工作。本着这种精神，Jeff 的观点完全正确。程序员喜欢写代码，但当我们面临问题时，写代码并不是首要目标——我们是要解决问题。
纵观人类历史，对重复性的工作一直有种「痛苦就是收获」的看法。埋头苦干、按部就班、努力完成琐碎的工作是有价值的。但在这段历史中的大部分时间里，我们没有计算机。事实证明，计算机非常擅长执行这些重复又琐碎的工作——涉及精确度而无需判断力的任务。电脑比我们擅长的事，就让电脑做吧。
假设未来每项工作的先决条件是能够编写复杂、专业的程序，那也太蠢了。但是，考虑到无处不在的计算工作，假设未来每项工作的先决条件是能够识别哪些任务更适合人类，哪些任务更适合计算机，这一点并不愚蠢。你至少得学会分辨工作中的哪些部分占用了你的时间。之后，也许可以学着通过你的聪明才智和创造力，利用你知道的工具来实现自动化（比如通过搜索引擎寻找解决方案，利用应用程序等）。而且如果你真的走到了这一步，那就试着撸起袖子来学习编程吧！毕竟纽约市长虽然没必要写代码，但做好跳槽的准备也无妨。
说明
这篇文章是念书时读的，一直放在收藏夹，内容没啥印象了但一直模糊有个「do not code, automate.」的印象。打工一年，尝试把工作上的一些流程自动化时偶尔就会想起这句话。想起有次用 Windows 自带的「Win + V」剪切板 CV 代码，同事夸我效率达人，就觉得这类文章还是有价值。趁机翻译分享下。