第四章 黑魔法般的编程思维¶
作为一个程序员。我常觉得程序员这个职业被 Overrated。外界常觉得程序员是魔法师。我们却常觉得我们自己是码农。只是用生命在农耕而已。
而且，程序员虽然高薪。但是这行却只有一个隐藏秘密。就是程序员这个职业很短命。一般来说 22 出社会，到 30 出头会最高薪。35-40 岁就可能下岗被迫转行。
这是因为编程真的是一门新兴行业。很多程式语言到目前的寿命从诞生到现在只有 20-30 年而已。但是，因为科技的发展，行业每十多年就会有诞生新的应用方向，产生新的语言。
而学习一门语言精通要时间，这个过程至少要 5-7 年以上的时间。但是程式设计师的职业寿命却只有12-18年上下而已。
为什麽程式设计师职业寿命会这麽短命呢？为什麽这行不像老师、律师、医师一样，是越干越值钱呢？
我后来终于想通这件事了。
我打个比方来说好了。我觉得程序员这个行业，比较像是职业司机。程式语言就像车一样。一班人在解决问题，都是用手工方式解决。而程序员就像会开车的司机，可以快速将你带到想要的目的去。所以，程序员的薪水非常的高，因为写好一个程式，可以爆发的生产力是数倍到数百倍。
然而，因为市面上，不同的车子种类一直在诞生，每种车子的驾驶方法又不一样。比如说虽然开车驾驶技术应该都是相通的。但家用车、卡车、垃圾车、巴士、联结车，他们的驾驶方法又很不一样。所以一个程序员会开 A 车，不一定有办法开 C 类型的车。
再者，写程式不止吃技术，也很吃体力。所以，当然年轻的工程师非常吃香。科技公司的老板都知道 29-32 的资深工程师，C/P 值是最高的一群。所以 35 岁还是工程师的话，多数薪水并不会有显著的提升，因为还有更年轻的能取代你。
但是这行更残酷的是，你会开的车型，有可能会被淘汰下市。理论上你会开车，但实际上在业界你可能没有车可以开了。所以接下来的问题，就是你还要再去学新的车怎麽开呢？那问题又变成，你如何跟 20 多岁的人竞争开车岗位呢？
但是，会开车这件事还是很迷人。毕竟可以比很多人高效很多倍。
为什麽很难在程式学校裡面学会写程式¶
我曾经开过程式学校，学生口碑也很不错。但是开程式学校这件事也很头大。因为，开程式学校目前来说，在程序员界是很政治不正确的。无论你教得再怎麽好，一定会遭受到攻击。（通常没被攻击的，多数是因为教得烂，很多学生从入门到放弃，以为是自己天赋不够）
为什麽会遭受到攻击呢？
第一个原因是挡人财路。程序员是一个高薪职业，高薪的原因有两个原因，一是提高产业效率，二是程序员野生居多，供应稀少。一旦你能成功供应大量的程序员，业界就会大大的跌价。那麽原有的程序员就会不爽了。这就像计程车司机抗议 Uber 司机抢他们饭碗一样。
第二个原因是学会开车，不代表能当计程车司机。
有的人来学写程式。是因为只是想学驾驶技术。另外有一类人，是想成为职业司机。而且目前佔大宗。
但是教会一个人开车，不代表这个人最终能够当计程车司机，考上驾照对吧（还有其他因素，比如说要当计程车司机要熟路，要亲切待客，要懂做生意等等）。
但是学生期待是这样的，甚至业界看你的眼光，也是这样。坦白说，程式学校最强也只能带一个人考上职业驾照而已，不代表这个人最后真能开计程车司机，甚至保证赚大钱。
第三个原因是期待不一。
程式学校目前多数还是以职业司机为导向。教得是你某一类车的开车法。如成唯一个 Python、Ruby、JAVA工程师等等等等。
市面上很多人其实只是想要学会驾驶技术而已。并不是真的想真正想开垃圾车。
所以当他们一碰到程式语言语法，就昏头了。入门一套程式语言并且到能解构问题，真正用这门程式写出解答，我算过，大概至少要粗估碰100个单字与知识点以上。所以很多没碰过程式的一般人，刚入门就放弃。
因为这些学习者，希望学的是如何解构问题，但是学校课程要过那麽难的关卡，才能开始学解构问题，没有人有那个美国耐心。
更何况是，很多程式学校教学者。自己根本不懂解构问题，何况教人。
你该学习的是编程思维，而不是编程语言。¶
我后来发现，一般人跟程式设计师讲想要学写程式时，程式设计师往往理解的是他要学开垃圾车，去当职业司机。这时候通常就会觉得对方薪水已经够高了，没事干嘛想转行。
但实际上，对方可能说的却是他想学开车而已。
但是，有办法将特定车辆驾驶方式与驾驶技术的学习剥离出来吗？
我认为是可以的。其实“驾驶技术”，甚至有个专业名词，叫“编程思维”。
超强的资深程式设计师往往有个通灵的能力。就是你跟他讲目前的一个苦恼，他能够瞬间跟你讲一个全新的解法，并且能够拆解细项任务、准确的预估所需要的工期、时间、人力调度，并且高效的完成任务。
这个超能力，在一般行业的老师傅身上也有。你应该见过一些资深的水电师傅，甲级电匠。做工程时也有超强的超能力。并且能够拆解细项任务、准确的预估所需要的工期、时间、人力调度，并且高效的完成任务。
这个相同的通灵能力。其实就是编程思维。差别只是程式设计师能够将所有的任务，用程式语言连在一起，放在机器上，以千倍的速度跑起来。
只是，不管什麽行业，拥有这个能力的人。往往不是工业训练出来的。而是藉由大大小小的任务，累积粹练出来的。所以多半不懂怎麽“教”。
“程式”并不是一个黑盒子，也不是一段黑魔法¶
那麽。我们要怎麽学“编程思维”呢？
首先我们来谈谈程序员跟一般人对“程式”这件事的角度，其实有很大的不同。
第一个最大的差别。就是普通人觉得“程式”是一个很大的盒子。
但是在程序员的眼中，其实程式只是一大片的代码而已。
再来呢？程式并不是一个巨大的盒子。
更精确的来说。程式是一连串的小盒子组成的具体产线。
所以，实际上“程式”在程序员的代码库裡面，是多段代码片段形式的存在。
而，更让人惊异的地方来了。很多人认为网路公司，应该就是一个用代码库运作的地方。
实际上网路公司的运作更可能是这样的
网路公司裡面的流程，并不是全然自动化。甚至，我还遇过这样的情形。
之前我在开设比特币交易所的时候，比特币交易所每一个帐号背后都要 KYC ( Know your customer)，原本我们是用人工审核客户的证件。但是后来用户量实在增加得太快。于是我们去找到了一间公司，号称是电脑自动辨识证件真假，后面有 AI 人工智能的公司，一张证件辨识费用收费 1 元美金。
基于公司业务量真的吃不消，于是我们只好忍痛採用这种高效的自动服务。
但是，后来我们却发现这个服务，好像不太靠谱，有时候会被一些恶意客户，用一些低级手段骗过。照理来说电脑应该可以抓到这些低级错误才是。
后来我跟业界打听，才发现这间公司才不是什麽鬼人工智能公司。他们是做了一个程序化接口，但是后面实际审核的方式，是外包到印度用人工去审核。!@#$%^ 所以才会被用低级的手段骗过。
为什麽会出现这样的情形。有几个原因：
- 程式语言不是能够自动解决世间上 100% 的问题，所以某些关键问题，可能还是要手工判断解决执行
- 有时候某一些问题，用电脑解还是太贵。不如用人工执行。
- 有时候甚至是算法太难。以现在计算机科学的程度，程式设计师根本还不能做出演算法，但人眼一能就能判别。乾脆中间就换成人去执行。
所以，没有写过代码的人，往往会觉得他找一个程式设计师外包，应该能够实做一个黑盒子，完美解决他遇上的所有问题。如果解决不了就是这个程式设计师违约，或者是能力不行。
但事实上，程式的世界并不是这样运作。
输入、处理、输出¶
好。即便不能 100% 程式化。那麽我们如何将遇上的问题，至少拆成这样执行的小块呢？
2020 年我心血来潮。想来做一个更简单的编程课（直接就叫“不用写程式的程式课”），原本教材都写好了。但我不确定我写的教材适不适合大家用。
于是就发了一个问卷，问大家要解决什麽问题。结果问卷回收以后我惊呆了。大家想要解的问题，跟我想的完全不一样。自然我之前的教材都要作废了。
大家提出了一些想要解决的问题。
如：
- 各种学会缴费单收到后，自动去缴钱
- 印刷厂电话询价报价
- 药师收到处方签配好药提醒病人回来拿药
- 商务拜访，收到名片，后续跟进
- 跟客户提案、安排老师教学，
- 整理公司报帐单，分析预算花费
- 病人看诊问诊，判断分类，后续卫教追踪
- 旅游业客人报名，预定安排行程，通知出团
这些问题，不仅是我傻眼，读者看到这裡肯定也傻眼。这些问题程式都能解吗？
可以。
其实，经过整理，这一类问题其实都是一样的。
比如说药师场景。
印刷场景
报帐场景
而“输入、处理、输出”这一个动作，其实有个名字叫流程化
而我们认为的写程式，其实是
而一般人像工程师说，他想学写程式时，重点往往会放在自动化
但我认为一般人其实缺的是问题分解+流程化的思维
因为。如果你只是要提昇效率的话。只要问题能够被分解，并且流程化。其实光这麽做，就能节省成本。变得更更有效率。（比如说找工读生，替代掉昂贵的部份）
STEP 1: 标准化输入¶
那麽。我们又要如何将问题具体流程化呢？我认为第一个步骤，应该是将问题的输入输出的接口明确。
这是什麽意思呢？就是就是将各种问题，输入的形式明确出来。
比如：
- 各种学会缴费单收到后，自动去缴钱
- 印刷厂电话询价报价
- 药师收到处方签配好药提醒病人回来拿药
- 商务拜访，收到名片，后续跟进
- 跟客户提案、安排老师教学，
- 整理公司报帐单，分析预算花费
- 病人看诊问诊，判断分类，后续卫教追踪
- 旅游业客人报名，预定安排行程，通知出团
就能梳理出
接著我们再将这些输入标准化。以业界常见的形式，你可以将这些形式变成 Excel。
STEP 2: 资料库化¶
为什麽要将档案转成 Excel 呢？这是 Excel 是地表上最流行也最简单的资料库形式。不仅 Excel 本身就内建一些资料库功能。程式设计师也有一堆 Excel 转档成资料库的方法。
一旦将输入标准为资料库形式。那后续就可以批次处理需求。
一旦你将输入资料库化。那麽“处理”这一部份，资料库就能解决很多问题
STEP 3: 将资料库接到各种输出软体上¶
虽然我们有不同的输出需求。
但是因为业界有很多的现成 API。只要你有资料库，要批量做这件事情不是很难。
在这个过程中，你不用写程式。甚至找工读生取代都行。
如果你的流程，工读生都能做。那才表示程式能做。因为程式，就是用来取代工读生做的最后一道手续。
其实，当程序员在听你的需求时，他脑袋裡面，其实想的就是如何分解成这样的流程。
然后，程式设计师做的，就是将这个过程不断的再往下拆
最后，再将这一块一块盒子代码化。
将编程思维应用在生活上¶
我们又如何用这套思维，来拆解日常生活遇到的问题呢？
CASE 1: 将英文书翻译成中文书¶
一直以来，英文书的观点就是比中文书的观点稍微新颖一点，快一点。但是，无奈翻译一本书需要时间。看过打造超人大脑这本书的朋友，应该都知道我有一套黑科技，能够将刚出版的英文书翻成中文书。
那麽，这种黑科技思维是怎麽做到的。
我这裡就讲解一下大概的思路。其实也是输入 => 处理 => 输出的思维。
接著。我们再定义输入与输出的格式。
但是，我们手头上只找到一个称手的工具，叫做 Google 翻译，但是 Google 翻译的上限只能是 5000 字。
于是，我们可以再重新定义“什麽是英文书？”它可以是 20 篇英文文章。而“中文书”，也可以是 20 “英文文章”。
只要我们最后，再压成一本书，就行了。
那麽。我们又要如何取得英文书的 20 篇文章呢？
其实也是相同的原理。再往下一层拆输入 => 处理 => 输出 。
这个问题又可以被分解成三种不同的作法，看你的技术高低。
所以。这个问题可以是非常高科技解。
- 自己写破解程式，把文本抓出来，自动接到 Google 翻译上，然后程式再自动组起来变成一本中文书。
又或者可以非常低科技解：
- 买一本正板书，请工读生打字。并且贴到 Google 翻译上。再且工读生複制贴上变成一本书。
但是他们都解决了问题。关键在于怎麽去拆解这个问题，并且流程化。他们只是有速度与准确度上的不同。
如果原本你不懂写程式，你可能认为这是一个黑盒子。实际上，这个问题其实是可以拆成 6 个盒子以上的。端看你要让整个程序多自动多省力。
CASE 2: 批量产出高水准的财经文章¶
第二个例子。我将难度再提升一点。
我有间公司是作财报分析的。这间公司有个部门，是负责经营公司微信公众号的。一个公众号（你可以理解成 Facebook Page），一个公众号，要有人订阅，必需要有高质量的文章。
但是这个部门的产出进度很不如意，花了几个月时间没有做出什麽成绩。即使找来几个文案写手，品质仍然差强人意，内容不好，自然也得不到多少点阅率。大家很气馁，纷纷跟我抱怨这件事是不可能的任务。
结果我花了一两周，就用编程思维解决了这个问题，不仅如此，还得到翻倍的点阅数与订阅量。
原始命题：打造一个高品质的专业公众号（官方帐号），文章品质好，容易引起转发。
原先内容部门的想法是，打造好的公众号的先决条件是内容要好，文章结构要好。于是他们想招聘有财经背景的人来写公众号。但是实际执行后发现不可行，因为有财经背景的人，赚的钱远高于新媒体的工资，如果只找对方来写稿，根本请不起。
于是他们换了一个想法：找有写公众号经验的人来写财经文章。人是找到了，但是遇到更大的难题。因为熟悉新媒体的写公众号的写手学财经的速度太慢，就算能写出文章，内容往往也错误百出，更搔不到痛点。所以写出的文章也不能看。
后来同事把主意打到外稿身上。外面肯定有作者非常熟悉财务知识，写作速度又快。但是合作了一两篇之后，就觉得这桩买卖实在太亏本了不划算。更何况，就算不计稿费与点阅效益，外稿写手也不可能高产量天天供稿。
所以内容部门一直很苦恼，找不到适合的写手，又写不出能增加点阅率的好文章来。
STEP 1：重新定义KPI¶
接手这个问题后，我重新定义了这个问题，搞明白这个问题要达成什麽样的目标？然后发现目标
有两个：
- 文章要高品质。
- 文章要高产量。
拆解这个大问题，它本质上就是“品质”与“产量”问题。
不过我发现，产量的问题最严重。因为每天都要更新内容，于是内容组天天写文章，甚至是当天写，当天上稿。然而因为写作能力有限，光选题、写作就耗了一天，写出来的稿自然也就普普通通，难怪素质无法提升。
STEP 2 一次只解一个问题¶
我去观察了其他公众号，发现其他帐号并没有每天更新，多半是一周上两次稿。如果一周更新两次，事情就简单好办了，因为可以降低写文章的强度。
不过没有备稿的问题还是没解决。当天发的文章都还是当天写，自然无法要求品质。所以解决问题的第一个重点应该是要求有备稿，有备稿才能买到时间，好好打磨文章。
但是我们不能奢求一次解多个问题，所以先解决产量问题。
STEP 3 数字化 KPI¶
我计算了一下需要多少备稿量。如果单周双发的话，七倍的稿量应该会足够。要准备好14篇稿子，而公司裡有3个文案，一人写5篇，连续写一周（每个人在一週内写出五篇），应该就会有足够的稿量。
STEP 4 提升速度产出¶
理论上3个人，每个人写5篇，应该就能囤积够用的稿子。但实际上不是。这3个人都没有财经背景，一天光要产出一篇够水准的文章都有问题。
我发现，他们一天写不出一篇好文章的问题在于三个关键点：
- 选题（不知道选什麽题目）
- 财务知识（本身没有财务背景）
- 写作速度（有财务背景的写手太贵）
于是我将这三个问题逐一拆开解决。
首先是选题问题。我让同事搜集了大约40个有趣的题目，并且将题目分类。这样就确保了“选题问题”，保证题目都是大家想看的。
再来，小编本身没有财务背景，所以有行文上的困难。有财务背景的人，文笔却又不够好。
于是我将这两件事分开。每天下午两点半找熟悉财经的人，选三个题目深入解答授课。同事将课程录音后，转成文字稿之后，将内容写成文章。这样就能够快上许多。
果然经过这样拆解，文案组同事很快就产出了一堆文章。
不过下一个问题来了。虽然文案组能写出够专业的文章，但是下出来的标题不吸引人，结构也不够精采，更别说要让人转发。
于是这时候我转而去解决“提高品质”这个问题。
STEP 5 提升质量¶
一篇文章，要能够称的上是好文。有三大重点：
- 题目吸睛
- 内文好看
- 看完认同转发
但是公司内没有写热门文章的高手，让小编去上写作课，又缓不济急。
于是我想了一个妙招。上网找了三本书：一本专攻标题写作，一本专攻内容写作，一本专攻如何热门转发。把书拿给内容组同事看，并规定他们要用极速读书法写心得笔记。
他们一看完这三本书，下午刊出的文章品质就大大提升了。因为这些书不仅传授核心技巧，更有写作模版。
STEP 6：重新调整顺序¶
一般人解决事情，往往是对著问题蛮干。失败了就崩溃哭诉问题太难。
而程式设计思维是先将大问题拆分成具体的小问题，然后再将小问题分类，找出解决办法。
手动重组顺序，最后再将过程自动化。
STEP 7：变成新的内容工厂¶
照这个新流程，内容组顺利了累积了几十篇文章的原始材料。而我们进一步针对每一个运营模式，做出了不同的运作模版。以后要制造内容，只要挑选出适合的原始材料，贴上模版，就可以组成不同的产品。
CASE 3: 医师如何批量写卫教文章¶
在上我的程式课的时候，好几个医师也问了类似的问题。他们平常看诊非常累。但来的病人，都是类似的主诉，其实问几个问题，大概就知道病人的问题是什麽了。而且需要做的卫教也差不多。每天重複这个流程，医生都累了。
- 是不是有个简化流程，可以让病人输入主诉自动判断。
- 有没有更高效的方法整理卫教文章
我说这还不简单。其实也是类似的解法。
一般来说，看病的流程是这样的。
那麽。医生根本不用改变任何流程，他只要录整诊间一週的音。整理出最常见的主诉，然后写下最常见的症状，就可以整理成一张 checklist 了。
而整理卫教文章又更简单了。也只要录整诊间一週的音。医生也整理出最常见的主诉，然后整理最常见的卫教逐字稿，週末花一点时间改写，就是一张一章的卫教单了。
而这样都不用写一行程式。也不必另外额外佔用休息时间。需要的只是一套录音笔以及一套录音转写程式。
程式设计思维＝拆解＋重组¶
所以这样整理下来。你会发现资深程式设计师的思维与流程，其实是：
- 使用者要达成什麽目的？
- 拆解当中有多少个难题。
- 先解决掉可以拆的难题，不能拆的就绕路走过，以后再解。
- 不能拆的问题是否可以重新定义范围，数字KPI化变成有解的题目。
- 把分解出来的答案重新连结起来，组成一个新的自动顺序。
最后，反覆改良其中的流程，直到达到自动化。
为什麽资深设计师与资深工匠，都能闪电般合理的解答，并且可以准确评估、难度、时间。其实是因为他们在脑袋已经做过这个流程，无数次了。