Casey Muratori Blames Abstract Clean-Code Dogma for Software Bloat

Casey Muratori指责抽象的“整洁代码”教条导致软件臃肿 现代软件之所以陷入难以承受的臃肿，是因为开发者针对SOLID等抽象架构教条进行优化，而不是去衡量真实的硬件执行成本。 Casey Muratori探讨了软件退化的根本原因，指出当今的软件臃肿、性能迟缓以及构建流水线脆弱，并非源于算法层面的失误，而是基础设施与胶水代码的无节制膨胀。他将编程描绘为一个由内心“生成器”与“过滤器”主导的导航过程，并把早期因硬件限制严格而倒逼出精简设计的资源匮乏时代，与如今缺乏纠偏演化压力的现代开发环境进行了对比。该行业没有依靠物理约束，反而接纳了教条式的惯例以及像“整洁代码”和SOLID原则这种脱离实际计算机硬件的虚构审美指标。Muratori最终认为，劣质代码之所以长期存在，是因为软件工程摒弃了经验主义度量，他敦促开发者将实践重新锚定在执行速度、构建时间以及真实的开发者工作流等切实成本之上。 现代软件退化的特征表现为漫长的构建时间、打包在Docker容器中脆弱的依赖栈，以及执行微不足道任务却需占用数GB内存。 (1:00) 软件架构的核心败笔并非源于已有数学解决方案的算法复杂度，而是源于物理硬件内存限制消失后肆意蔓延的胶水代码与基础设施。 (6:40) 业界对“整洁代码”和SOLID等教条的广泛接纳属于非科学的教条仪式，因为这些概念完全缺乏可操作的定义，也与物理硬件没有任何可衡量的关联。 (23:08) 软件开发成本应当依据可衡量的经验维度来评估——包括硬件上的执行时间、上手培训延迟、代码修改成本以及沟通开销——而非主观的审美标准。 (29:44)

## Background 本内容由 Casey Muratori 的频道 Molly Rocket 于 2021 年 11 月 2 日在 YouTube 上发布。视频源自 Casey 受邀为 Web3 基础设施公司 Infura（infura.io）举办的一场技术直播讲座录播，旨在解答该团队面临的代码库失控、运行迟缓与性能低下等行业普遍痛点。 ## TL;DR Casey Muratori 深入剖析了现代软件工程中“烂代码”泛滥的根本成因。他指出问题并不出在算法本身，而是将算法串联起来的“黏合代码”和基础设施由于缺乏严苛的硬件物理约束而彻底失控。现代开发者的大脑认知过滤器被 SOLID、“整洁代码”（Clean Code）等缺乏物理度量的虚构教条所绑架，脱离了真实机器的运行成本与实际开发消耗。他主张行业必须重返现实，以执行效率（Execution）、编写、调试等可量化的“WARMED”物理指标来取代空洞玄学，终结当代代码库无限膨胀与低效的恶性循环。 ## Atmosphere & style 整场讲座风格犀利、坦诚且极具颠覆性，Casey 带着一种工程师特有的实用主义清醒，毫不留情地刺破主流编程圈的理论泡沫。他借助航海探险、蛮荒求生以及戏谑的缩写对照（WARMED 对抗 SOLID），将抽象的认知科学与系统架构讲得通俗生动又发人深省。观众在观看时既能感受到他对现代软件行业臃肿现状的深切痛心，也能被他那种呼唤回归物理本质、用数据与事实说话的严谨工程精神所感染。 ## Bulletin - [06:40](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=400s) Casey Muratori 认为现代软件生态普遍陷入代码膨胀与性能低下的泥潭，其核心症结不在于算法本身，而在于缺乏约束、肆意膨胀的胶水代码与系统基础设施。 - [18:47](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1127s) 早期极端严苛的硬件环境曾逼迫开发者形成对物理机器的高度敬畏与严谨的脑内代码过滤器，而现代无限充裕的算力反倒剥夺了这种天然的淬炼机制。 - [24:10](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1450s) 以 SOLID 为代表的‘整洁代码’教条因完全脱离 CPU 物理现实且缺乏量化验证数据，沦为了未经验证的玄学仪式，误导了新一代开发者的工程直觉。 - [29:44](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1784s) 软件工程亟需重返现实，以执行效率（Execution）为核心，全面量化编写、共识、阅读、修改与调试等实际开发开销，终结未经检验的设计教条。 ## Key takeaways - [01:00](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=60s) 当代软件生态呈现严重衰败迹象：依赖层级无限蔓延、构建动辄耗时数小时（如 TensorFlow），简单的 2D 交互就能吃掉数吉字节内存，付出高昂复杂度代价后可靠性却并未提高。 - [03:50](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=230s) ‘烂代码’不能以商业成败或个人编码乐趣来评判，而应以软件工程能够交付给客户与社会的‘潜在上限’作为度量尺度。 - [06:40](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=400s) 计算机科学在算法层面的理论与教学高度成熟，真正的崩溃发生于负责拼装算法的‘胶水代码’以及承载算法的基础设施管理上。 - [09:31](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=571s) 程序员的代码生成与筛选机制类似于人脑中的‘生成器与过滤器’；随着经验积累，大脑会大幅收窄解空间，仅在极少数高度固化的代码模式中进行选择。 - [13:51](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=831s) 软件开发是一场充满未知的航海探险而非按图索骥的土木建筑；烂代码的根源在于团队在浓雾中迷航，拉出极其臃肿迂回的路线并最终停泊在劣质终点。 - [18:47](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1127s) 过去仅有 64KB 内存的严苛环境具备天然淘汰机制，任何低劣代码都会导致程序无法运行；而现代充裕的算力与存储消解了硬性约束，使低质代码得以勉强苟活。 - [20:38](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1238s) 业界充斥着对‘整洁代码’（Clean Code）的盲目宣扬，但行业从未给出过一个能够通过工具客观断定与量化的严谨定义。 - [24:10](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1450s) SOLID 原则不对应任何 CPU 物理层面的事实，只是纯粹的脑中臆想，且从未有量化数据证明遵守它能切实缩短研发耗时或降低缺陷率。 - [29:44](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1784s) 评估软件必须回归真实成本框架（ARM-ED / WARM-ED）：涵盖编写、共识、阅读、修改、调试开销，而最核心的是最终用户计算机上耗费的执行成本（Execution）。 - [29:44](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1784s) 行业经常对用户界面进行无休止的 A/B 测试，却从未对自身标榜的软件架构设计原则进行过任何基于硬性指标的 A/B 验证。 - [32:21](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1941s) 盲目推崇‘代码复用’就像在荒野中借用迷航前人留下的营地，直接将不合格的库与框架当作地基，导致后人一开始就陷入更深的泥潭。 - [36:19](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=2179s) 摆脱劣质代码的关键在于彻底抛弃空洞教条，将可量化的物理指标（如执行时间、构建用时、代码上手周期）重新作为评估和传授软件工程的第一准则。 ## Detailed walkthrough ### [00:01](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1s) 演讲背景与破题：“烂代码”从何而来？ Casey Muratori 在视频开篇先为自己参与的 Kickstarter 图书众筹项目《Meow the Infinite》（第二册）做了一个简短的宣传收尾。随后他切入正题，说明本次视频是一场受邀前往 Web3 基础设施公司 Infura（infura.io）所作的内部技术讲座。此前他曾向对方收集希望探讨的技术选题，发现大家反馈上来的诸多痛点本质上都指向同一个核心现象：代码库正变得彻底失控——体积庞大、运行缓慢、性能严重低下。 针对这一系列行业普遍存在的困境，Casey 决定以通俗、宏观的视角来回答一个根本性问题：“烂代码到底是从哪里来的？”该分享整体分为两部分，本期为演讲正片，下一期则是问答互动环节。 ```mermaid flowchart LR accTitle: 从开发者普遍痛点到核心议题推导 accDescr: 描述代码库失控、性能低下等行业普遍痛点如何汇聚为本讲座的核心问题 subgraph Symptoms["行业普遍痛点"] A["代码库无限膨胀"] B["运行与构建极度迟缓"] C["性能低下与严重浪费"] end subgraph CoreQuestion["核心议题"] D["烂代码从何而来？<br/>(Where Does Bad Code Come From?)"] end Symptoms --> D ``` --- ### [01:00](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=60s) 当代软件现状：膨胀、脆弱与行业性衰败 Casey 深刻指出，只要你拥有长期的编程经验，或者作为一个置身事外的客观观察者去审视当前的软件行业，就会发现如今的软件生态已经病入膏肓。代码量呈现出爆炸式增长，即使是功能极其简单的程序，其代码量动辄也是数十万甚至数百万行。 软件的构建系统变得无比脆弱且繁复，甚至不得不将整个构建环境封装到 Docker 容器等工具中，仅仅是为了祈求这些项目在未来还能继续跑起来。工程中充斥着错综复杂、近乎疯狂的依赖链路：系统包管理器去安装编程语言，语言再安装自己的包管理器，接着下载一层层的第三方包，各包内部又各自解压安装自己的下游依赖。好不容易配置齐备，编译过程却漫长到令人发指——以 TensorFlow 这类广受欢迎的项目为例，在算力如此强劲的现代计算机上，有时完整构建一次竟需要耗费数小时。 不仅构建痛苦，最终交付到用户手中的软件质量也极其低劣： - **无处不在的卡顿与等待**：软件动辄在加载或进行网络通信时彻底失去响应，让用户无事可做。 - **与硬件性能严重脱节的运行速度**：在现代顶级硬件上跑着理应极快的基础操作，体验却依然肉眼可见地缓慢。 - **触目惊心的资源占用**：简简单单的软件生成一两百兆字节（MB）的可执行文件已屡见不鲜，甚至连滚动浏览 2D 图片这种基础界面交互，其工作内存占用都能轻松飙到数个吉字节（GB）。 - **并未改善的软件可靠性**：付出如此巨大的复杂度与资源代价后，软件并未变得更加可靠，反而依旧漏洞百出。 Casey Muratori 犀利地总结道：“It's still totally buggy and it has all the same problems if not more problems than it has always had before it sort of jumped this level of sort of kind of complexity and and kind of in general this this overall overriding sort of sense of decay that seems to be seeping in to whatever we call the software industry currently.” --- ### [03:50](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=230s) 重新界定“烂代码”：不关乎商业与趣味，关乎工程潜力 要深入探讨问题根源，就必须对“烂代码”做出明确的定义与价值判断。Casey 澄清，他所讨论的“坏”并不是指商业上赚不赚钱。在当前的软件商业环境下，市场竞争极度不充分，软件所能渗透的新领域依然极其广阔，整个行业仍处于发展的早期红利阶段。消费者和企业往往只能在极其有限的几个低质选项中挑选，根本没有真正的市场压力去倒逼高品质工程的出现。 Casey 直言，写出高质量代码固然可能带来巨大的竞争优势，但目前绝非企业生存的刚性壁垒，所以他绝不会从“不写好代码公司就会破产”或“关乎职业饭碗”的角度来做道德绑架；同时，他也不想从“程序员写代码快不快乐”来评判——即便有人戴着 VR 头显、胡乱拼凑一堆框架玩得不亦乐乎，那也无可厚非。 Casey 明确强调，当他谈论“烂代码”时，真正关心的尺度是软件工程的“潜在上限”： “All I'm trying to talk about when we talk about bad code is like what's our potential like like what could we be doing engineering-wise versus where we currently are are we performing up to that potential at all or are we actually kind of falling pretty far behind where we could be if we looked at what we could be delivering to our customers and to society if we took things more seriously right?” --- ### [06:40](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=400s) 算法不是元凶，失控的是“黏合代码”与基础设施 在寻找烂代码的真正元凶时，Casey 提出了一个核心分野：必须将“算法”（Algorithms）与“黏合代码”（Glue Code）明确区分开来。他认为软件工程界在算法层面上做得并不差： - 计算机科学界对大 O 复杂度符号、复杂性类别进行了深入透彻的理论探索（尽管 P=NP 等世纪难题尚未解决）。 - 业界对哈希表（Hash Tables）的性能分析、堆（Heap）的数学性质、各种排序算法的应用场景与优缺点，都有着高度理智且成体系的教育与工程认知。 因此，导致当代软件体验崩塌的罪魁祸首绝非开发者选错了某种排序算法。真正的病灶在于把各类算法串联、拼装在一起的“胶水代码”，以及承载这些算法的软件基础设施管理。我们正在疯狂写出无法理喻的黏合逻辑，整个架构体系彻底失控。 Casey 回顾历史指出，在早期的硬件环境下，这种失控从物理上就是不被允许的——当计算机的 RAM 仅有 64 KB 时，胶水代码和基础设施根本没有无限膨胀的客观物理空间，极其严苛的硬件约束充当了代码膨胀的天然制动阀。然而在现代计算环境中，硬件约束彻底解除，而行业却从未建立起任何替代性的工程自律或架构约束机制。为了解释为什么行业无法建立起这种替代机制，Casey 表示接下来必须深入剖析人们究竟是如何在计算机上学会制造软件的。 Casey Muratori 在分析核心症结时明确指出：“Usually what we're talking about is the mess of the rest of the code we are having a problem writing all the code that glues these algorithms together right like when we're talking about what we're actually going to do here the problem that we actually have is not so much that like we couldn't sit down and figure out what the proper algorithm is here for this the problem seems to be more that we can't figure out how to connect these things or how to manage the infrastructure into which these algorithms are placed that seems to just not work right it seems to be like that is what's going off the rails.” ### [09:31](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=571s) 人脑中的“生成器”与“过滤器”：程序员是如何养成的 没有人生来就知道如何编写计算机程序。Casey Muratori 回忆起自己很小的时候坐在父亲的键盘前，所做的仅仅是胡乱敲击出一堆毫无意义的乱码。对于刚接触电脑的幼童而言，键盘输入纯粹是垃圾字符。然而不久之后，大脑开始自我训练，逐渐意识到只有特定的字母组合与合法的语法结构才能让编程语言产生预期的结果。这就是为什么我们称它们为“语言”——它们具备真正的语法、词法以及严密的结构规范。 在神经与认知层面，人脑在这一学习过程中构建了某种协同机制：“一个生成器和一个过滤器”（a generator and a filter）。生成器负责构想该语言合法语法允许的各种代码片段，而过滤器则拥有评估指标，能够剔除那些无用、多余或无法向目标推进的废弃路径。Muratori 指出，这种机制与人工智能研究中的训练过程极为相似：必须先训练生成器在目标输出域中产生有效结构，再依靠过滤机制引导系统逼近目标。随着开发者技能的提升，这种抽象层级逐步攀升——程序员学会了利用函数和调用外部库，在大脑更高维度的层级上进行生成与过滤。 这种训练也导致了一种显著的收敛现象。无论水平高低，资深程序员的代码通常表现出高度的规律性与规整性。在生理层面上，这意味着大脑的过滤器已经大幅收紧，将该语言语法允许的海量合法可能性中的绝大多数彻底裁减剔除，仅在一小部分极其狭窄的代码范式中进行选择。当人们刚学会打字编程时，任何合法的语法都可能被敲出来；但随着时间推移，程序员实际上“丧失”了敲出某些奇怪结构的能力——并非不能强迫自己写，而是大脑的直觉早已将其排除在视野之外。公众往往将这一狭窄的子集视作经验丰富、产出优质代码的标志，但不可否认的是，庞大的解空间在此过程中被永久剥离了。 ```mermaid flowchart LR accTitle: Brain Code Generation and Filtering Process accDescr: Diagram showing how input characters become trained into a dual generator and filter system in a programmer's brain. subgraph InputStage["认知演进阶段"] A["幼童胡乱敲键<br/>(无序字符)"] --> B["理解语法规则<br/>(语言词法/语法)"] end subgraph BrainEngine["脑内双重机制"] B --> C["生成器 Generator<br/>(构建合法代码)"] C --> D["过滤器 Filter<br/>(按指标评估淘汰)"] end subgraph OutputStage["长期经验固化"] D --> E["高阶抽象构件<br/>(函数/代码库)"] E --> F["高度规律化输出<br/>(极度收窄的可能空间)"] end ``` ### [13:51](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=831s) 软件开发不是盖大楼，而是没有地图的探险航行 为了理解这一内在机制在实际工作中是如何运作的，Muratori 提出了“航海探险”（exploration）的隐喻。在开启一个代码库时，生成器与过滤器更像是一个依靠航位推测法（dead reckoning）摸索前进的航海家。开发者无法像建筑工程师那样预先绘制好一切： > “它不像建筑学；它不像那些我们先完成大量求解、然后直接往里填东西的领域——UML 图支持者曾试图这样做，但开发似乎从不是这么一回事。” 在实际编码中，前方并没有绘制好的地图，开发者更像是在未知地域中摸索：有时必须根据当前反馈调头回退，有时是在开辟无人涉足的崭新航线，有时则是在重走一条较为熟悉的航道，并试图凭借过往经验稍作优化。这一过程的结果往往不可预测——有时航行顺风顺水，抵达令人心驰神往的新大陆；而有时项目彻底崩溃，情况恶劣到只能弃船逃生，正如 Muratori 风趣调侃的那样：“丢掉船只，能带多少粮食就带多少，徒步穿过冰山，祈祷在大家全部冻死饿死之前能碰到另一个人。” 探险路线的曲折程度直接映射了开发流程的顺畅与否。如果推进路线笔直清晰，说明开发顺利高效；若中途经历大量弯路与反复回溯，则代表着极其艰难的研发过程。而最终停泊的地点，便对应着交付软件的最终质量。在软件开发中，开发者在起航时通常无法精确预测最终产品的全貌，它就像一个只能在特定点位取值评估的黑盒函数：当从南美航向非洲时，你只有在真正撞上陆地、向当地人确认“这里是非洲吗”并得到肯定答复时，才能确定自己抵达了陆地；甚至在靠岸之后，你原本瞄准的是南非，却可能发现自己阴差阳错登上了埃及的海岸。 ### [17:52](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1072s) 烂代码的根源：团队在迷航中彻底失控 当这种探险隐喻投射到“劣质代码”（bad code）的现状时，其背后的病灶便暴露无遗。劣质代码的产生，本质上是因为研发过程在迷雾中遭遇了灾难性的迷航： - **资源与路径的大幅浪费**：团队并非在进行有目的的探索，而是在代码空间中漫无目的地迂回游荡，耗费了不可承受的时间与精力，拉出了一条极其臃肿拖沓的路线。 - **终点与目标的极度偏离**：当漫长的开发终于迎来某种形式的“靠岸”时，产出物的质量往往极其糟糕，与最初立项时的构想和需求相去甚远。 - **困境中的无力感与不可捉摸性**：无论是在项目研发的中期还是收尾阶段，工程师们常常会产生一种强烈的迷茫感——清晰意识到“我们彻底迷路了”，却面对眼前的泥潭束手无策，完全不知道究竟该采取什么行动才能突破当前的僵局。 ### [18:47](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1127s) 编程中的迷失感与大脑“过滤器”的失调 当程序员写代码时，常常会遇到一种极度挫败的境况：写出来的代码总是不如人意，本以为能推动项目进展的做法不仅毫无用处，反而把自己推向倒退，代码似乎永远不会变好。讲者 Casey Muratori 指出，这种状态就像在迷雾中彻底迷失了方向。要理解为什么软件开发流程会走向崩盘，Muratori 认为根源必须归咎于我们如何在脑海中构建那个导航与过滤机制——即指导我们“下一步该写什么代码”的思维过滤器。不论是从软件工程体制还是从个人培养层面来看，当今行业在构建这套核心认知机制上“做得极其糟糕”。 对比早期的计算环境，过去的硬件极其严苛：一台电脑只有 64KB 内存，搭载的 6802 处理器几乎做不了什么事，从磁盘读取数据需要耗费极其漫长的时间。在那种极端匮乏的物理限制下，任何一个能让程序跑通的人，在开发过程中都必须对机器的每一处动作保持高度警惕与自觉。当时写出的代码只要有哪怕一丁点粗糙或拙劣，整个系统就会彻底无法运行。正如 Muratori 所比喻的：“这有点像探险家在北极接受训练；凡是那些不够优秀或学得不够快的，全都死掉了。”那种环境逼迫程序员形成精准、扎实的直觉；而当今无限充裕的硬件资源，却剥夺了这种天然的淘汰和淬炼机制。 - 过去严苛的环境迫使程序员高度自知：稍有瑕疵的代码直接导致程序无法工作，从而天然筛选出高效代码。 - 现代计算平台由于内存与算力几乎无限，缺乏自然淘汰粗劣代码的机制，导致程序员的大脑过滤器无法建立在真实的物理约束之上。 ```mermaid flowchart TD accTitle: 严苛环境与现代充裕环境的开发思维对比 accDescr: 对比早期硬件限制逼出的物理自觉，与现代资源过剩引发的伪规范依赖 subgraph Past["早期严苛环境（如 64KB 内存 / 6802 处理器）"] A["物理资源极度匮乏"] --> B["低容错率：微小瑕疵即导致崩溃"] B --> C["严苛的自然淘汰与反馈"] C --> D["建立以机器现实为核心的认知过滤器"] end subgraph Modern["现代充裕环境"] E["算力与存储近乎无限"] --> F["不良代码依然可以勉强运行"] F --> G["缺乏来自硬件的硬性制约"] G --> H["依赖抽象教条（如 SOLID、代码整洁）"] end ``` ### [20:38](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1238s) 现代开发直觉的输入源与“整洁代码”的伪概念 如今，极少数人依然完全依靠个人在原生环境中的摸索来构建直觉，这类人往往很少制造当今泛滥的劣质代码，但绝大多数现代程序员的思维过滤器是由外部环境塑造的。现代人从大学课堂、代码审查（Code Review）、导师指导、主管的绩效考评、技术讲座，以及 Stack Overflow 上被顶得最高的回答中获取反馈并调整认知。Muratori 明确表示，问题并不出在算法教学上——如果有人想在网上查找排序算法，很容易找到科学严谨的资料和渐进符号复杂度（Big-O notation）分析。 真正的危机出在算法之外的所有系统架构与基础设施代码上。这一领域缺乏严密的数学度量，取而代之的是充斥整个行业的空洞辞藻，最典型的就是所谓的“整洁代码”（Clean Code）。行业内铺天盖地地教导程序员如何让代码变“干净”，却从未有人能给“整洁代码”下一个清晰、可量化的客观定义。业界不存在任何一个工具或程序，只要跑一下就能明确输出“是整洁代码”或“不是整洁代码”。取而代之的，是一套只要按部就班执行、就被断言代码会变“干净”的操作规程。 > “在算法或类似领域，我们做得并不差……我真正讨论的是另一种风格的代码：除了算法本身之外的所有东西，是所有的基础设施，是所有那些没有被以相同方式研究的其他东西，我们对它们甚至没有阶数渐进符号。” —— Casey Muratori ### [24:10](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1450s) SOLID 原则：缺乏现实度量的纯脑中仪式 这种伪规范最典型的代表就是被奉为圭臬的 SOLID 原则。Muratori 尖锐地剖析道，SOLID 中的任何一条原则，在真实的计算机世界里都找不到对应的实体定义；它们根本不是 CPU 内部发生的事情，而是完全存在于程序员脑海中的臆造概念。这些假想的指标被硬生生植入程序员的思维过滤器中，用来规训程序员哪些代码可以写、哪些代码绝不能写。为了证明并非空穴来风，Muratori 指出，就在他为演讲准备 Stack Overflow 幻灯片截图的当天，Stack Overflow 官方博客的头条赫然就在向所有寻求技术答案的开发者灌输这套东西。 像 SOLID 这样标榜“整洁”的方法论，拥有一个共同且致命的缺陷：它们拒绝衡量任何真实的物理指标。人们盲目遵循里氏替换原则（Liskov Substitution Principle），假定只要遵守它，开发时间就会缩短、流程就会顺畅、Bug 就会减少，但全世界没有任何人拿出过经得起度量的实际数据来支持这一结论。在 Muratori 看来，这已经蜕变成了一种宗教式的仪式：“这就非常像是……我们在吃东西之前要先给食物做祈祷祝圣一样。”仪式或许能给推行者带来心理慰藉，但它与人们真正关心的工程结果毫无因果绑定。 > “如果我们在脑中生成和过滤代码时所锚定的目标是 SOLID，那么根据定义，你锚定的就绝不是真实的计算机。” —— Casey Muratori - SOLID 等设计原则不映射到任何 CPU 的可测物理事实，纯粹是人为制造的抽象思维枷锁。 - 没有证据或基准测试证明遵循 SOLID 能够直接缩短开发周期或减少缺陷率。 - 整个体系从未包含自我纠错机制：SOLID 从不会告诉开发者“如果你发现它没能节省开发时间，就立刻停止使用它”。 ### [28:17](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1697s) 摆脱空洞教条：以真实指标为导向的“WARMED”反思 Muratori 警告，将思维模型建立在虚妄的教条上具有巨大的危害，因为计算机是真实运转的物理设备。如果程序员的思考重心全被抽象缩写词占据，代码运行所依托的硬件设备就被彻底排除在视野之外；与此同时，开发者也不会去记录和衡量自己的真实开发工时。既然空洞的原则既不关心机器性能，也不关心实际生产力，它就无法指导真正的工程实践。 为了反讽这种对缩写词的盲目崇拜，同时揭示一个健康的思维过滤器真正应该关注什么，Muratori 现场提出了一个拼写为“WARMED”的对照概念（与 SOLID 针锋相对）。他强调自己并不倡导大家去死记另一个无聊的缩写，而是希望借此形成强烈的反差：如果一定要给程序员的大脑过滤器灌输核心准则，那这些准则必须且只能由程序员真正需要关心的、可测量的硬性工程指标来构成，而非悬浮在空中的代码美学玄学。 > “SOLID 通篇没有任何一处提到过：‘顺便说一句，这些其实都只是为了节省开发时间，所以如果你发现自己并没有省下时间，就别再这么干了’；从来没人这么说过。” —— Casey Muratori ### [29:44](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1784s) 软件成本的真实构成：构建 ARM-ED / WARM-ED 评估框架 如果像 SOLID 原则这样的编程教条真是一个好主意，人们原本应该能够依据日常开发中真正要做的事情对其进行高效评估。在日常工程实践中，开发者真正在做的事可以归结为几个核心维度：编写代码（Writing）、就代码达成共识（Agreeing，如果涉及多人协作；或者用 Argue/争论更贴切，因为程序员极少意见一致）、阅读代码（Reading，不仅因为大家通常没写过所有代码，而且哪怕是自己写的也难免遗忘）、修改代码（Modifying）、在硬件上执行代码（Executing），以及对代码进行排错调试（Debugging）。 ```mermaid flowchart TD accTitle: 软件开发全生命周期成本框架 accDescr: 展示执行成本与五项开发成本共同组成的软件全成本结构 subgraph UserCost["最终用户承担的成本 (最关键)"] E["E - 执行成本 (Execution)<br/>硬件算力消耗与等待时间"] end subgraph DevCost["开发团队承担的成本 (研发周期)"] W["W - 编写 (Writing)"] A["A - 共识/争论 (Agreeing/Argue)"] R["R - 阅读 (Reading)"] M["M - 修改 (Modifying)"] D["D - 调试 (Debugging)"] end DevCost -->|"交期延误、修Bug变慢、加功能受阻"| Impact["间接损害最终用户价值"] E -->|"直接浪费用户时间与设备资源"| Impact ``` 上述每一项都是不折不扣的“成本”。其中，代码的执行成本（Execution）是最重要的一项开销，即程序在最终用户的计算机上运行时所耗费的计算资源。最终用户是付钱给软件团队的人，如果因为交付了劣质低效的代码而导致执行成本居高不下，就是在白白浪费用户的时间。其余维度的开销则属于开发时间成本，它们同样会深远影响客户：如果团队迟迟无法完工，或者修复一个缺陷要拖延极久，亦或新增一个功能举步维艰，客户都会直接承受损失。优化软件的核心逻辑绝不能顾此失彼，而是要设法将这些成本综合降至最低，并根据业务偏好为各项指标设定合理的权重。 - 行业现状极度荒谬：整个软件行业会对用户进行无穷无尽的 A/B 测试，却从未对自身标榜的软件设计原则进行过任何带量化指标的 A/B 测试。 - 协作与开发成本完全可以被度量，例如：统计团队在 GitHub 上针对某个 Issue 必须来回沟通多少次才能真正修复问题、开了多少场沟通会议，或者编写特定功能模块具体花费了多少工时。 - 演说者强调：“Execution is a cost of the actual computation. It's the most important cost, the E, right? How much does it cost to execute this thing on the end user's computer? They're the people who are ostensibly paying us, and we are wasting their time if that cost is very high because we've shipped them something lousy, right?” --- ### [32:21](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=1941s) 迷失的探险家：工具错配与虚构地图的思维困局 探究糟糕代码的根源，可以用探险家来作比喻：程序员就如同出发前往某个模糊目的地的探险家，他们被告知或者自己选定了一个目标，但在如何抵达目的地这件事上却缺乏真实的认知。在这一背景下，整个行业并没有给他们指北针，而是塞给他们一套完全匪夷所思的工具——比如递给他们一把铁锤或一把卷尺，然后告诉他们：“启程吧，这是给你的铁锤。”更要命的是，现实中的人如果拿到无用的铁锤至少还会随手扔掉，但编程教育却欺骗他们这把铁锤是至关重要的导航工具，逼得开发者不得不把铁锤举向太阳，试图靠它来分辨方位。他们根本不知道行业给予的工具不仅无法测量真实世界的任何指标，而且与要解决的问题完全风马牛不相及。 与此同时，开发者整天都在围绕一张根本不存在的“虚构地图”高谈阔论。大家热火朝天地争辩像“里氏替换原则”（Liskov Substitution Principle）这类概念，仿佛它真和实际编程有什么必然联系一样。不可否认，它或许与某些语言中某些人凭空假想的理论有一丁点关系，但它在现实物理世界中完全是虚构的，如同《指环王》里的中土大陆。托尔金的小说固然精彩，但如果一个人打算从南美洲航行到非洲，在脑子里琢磨魔多（Mordor）位于地图的哪个方位对现实导航毫无助益。行业让新入行的程序员从一开始就用一套与实际目标脱节的思维模型去过滤现实，没有任何客观度量指标把他们拉回现实，因此当他们写出荒谬绝伦、失控膨胀的代码时，根本没有什么可意外的。 ```mermaid flowchart LR accTitle: 软件生态中迷航起点的恶性传导 accDescr: 展现从迷茫的前人构建生态到新一代开发者彻底迷失的传导路径 subgraph Past["前人 (早已迷失)"] L1["不合格的库 / 语言 / 框架"] end subgraph Present["当下新人 (错误起跑线)"] Base["奉为圭臬的 Base Camp<br/>(盲目的代码复用)"] Lost["在未知的丛林中起步<br/>(缺乏真实度量标准)"] end subgraph Consequence["后果"] Bloat["百万行代码、龟速且多Bug<br/>(误认为系统天生该这么复杂)"] end L1 --> Base Base --> Lost Lost --> Bloat ``` - 现代程序员如果从未在资源极度受限的环境中磨砺过，就会产生一种虚无的无力感，误以为软件天生就该有上百万行代码、天生就该奇慢无比且漏洞百出，根本无法想象精简高效的形态。 - 行业大力鼓吹的“代码复用”，在探险比喻中无异于在荒野里直接借用前人搭建的营地（Base Camp）；然而前人原本就处于迷航状态，后人直接把这些由不懂真实运作机制的人写成的库、语言甚至平台生态作为新起点，导致后人一开始就迷失在蛮荒腹地，比从港口重新出发还要艰难百倍。 - 演说者针对软件概念的虚妄性总结道：“You have a mental model that's been tuned for things that have nothing to do with the actual stuff you're trying to solve.” --- ### [36:19](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=2179s) 重返真实世界：用可验证的物理度量终结“整洁代码”神话 要终结劣质代码的泛滥，软件行业必须彻底扭转交流范式，把目光拉回到真实世界。无论是技术会议上的演讲，还是探讨编程语言的语法结构，都必须拿事实说话：究竟哪种方案能确凿地降低某项具体成本？行业不能再停留在未经检验的臆断上，而必须引入能够真正反映现实的度量工具。任何时候，如果行业把一个未经检验的起点当作标准强加给工程师，都会在未来的软件演化中埋下巨大的隐患。 所谓重返现实，就是要彻底摒弃空洞的说辞。行业绝不能继续空谈“什么是整洁代码（Clean Code）”，而是必须拿出硬性的客观指标：新的写法是否在保证等价执行效率的前提下减少了代码行数？绝不能为了少写几行代码而牺牲运行时性能；同样，如果宣称某段代码更易读，绝不能是靠开发者之间主观讨论出来的，而必须进行量化验证——例如以往新员工入职需要耗费一整天才能读懂并上手这块模块，重构之后是否真正缩短到了两个小时？软件性能必须从一开始就作为底层基石纳入评估体系，演说者甚至直言：“SOLID 这个缩写词如果里面不包含一个代表性能的 P（变成 P-SOLID 之类），它从一开始就不应该被允许存在。” - 算法领域之所以能取得长足发展并更易验证，正是因为算法拥有严谨的形式化语言和可以直接测试的客观依据；而非算法层面的软件工程代码之所以看似不可捉摸，只是因为行业长期拒绝正视可以度量的客观事实。 - 演说者举出令人深思的反面案例：像 TensorFlow 这样的软件，如今往往需要耗费四个小时才能编译完成，而它底层所做的事情根本没有复杂到需要如此漫长的构建时间，这种荒唐局面的蔓延正是由于行业长期放弃了对真实开销的监测。 - 演说者重申不要被空洞口号所蒙蔽：“When I talk about things like that, what I'm saying is don't just say stuff, right? Don't just talk about 'this is clean code' — actually measure, have something we can measure.” ### [39:57](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=2397s) 糟糕代码的根本成因：与真实指标的断联 Casey Muratori 总结指出，当前软件开发界灌输给工程师的思考“过滤机制”，直接催生了那些庞大且低效的代码库。他情绪强烈地呼吁业界必须采取行动、彻底纠偏：“We need to start like actually nailing those down and saying no, don't teach people to do these things anymore; they're producing obviously bad results that we can measure because it takes four hours to build, right? We can tell.” 漫长的编译构建时间等直观指标，已经明确证实了这些教条方法的破产。 回顾“坏代码从何而来”的核心论题，Casey 坦言自己没有更具玄学色彩或更神奇的解释。在他看来，坏代码的诞生完全归结于一个极其简单的致命失误：“And that is we have stopped measuring and talking about what we actually want, and we are almost exclusively talking about or measuring things that are largely fictional; they don't directly connect back.” 当开发者停止讨论和衡量真实产出，转而将注意力投向与实际效果毫无直接关联的虚幻教条时，恶性循环便开始了。 这种脱节对新一代开发者造成了严重的误导。后来的年轻程序员只接触到了诸如 SOLID 这样的设计原则，完全不知道在这之前本应优先关注哪些真正重要的物理与业务考量。Casey 强调，SOLID 本质上不过是某个人提出的几条粗浅经验法则（rules of thumb），绝不应该被当作第一顺位的教学内容；正确的教学应当永远将评估真实指标（real metrics）放在首位。 ```mermaid flowchart TD accTitle: 坏代码滋生机制 accDescr: 展示了从脱离真实指标到盲目追随教条，进而导致新一代程序员误入歧途并产出坏代码的恶性循环。 subgraph Problem["认知偏差"] A["忽视真实指标<br/>(构建时间 / 运行性能 / 资源开销)"] --> B["盲从虚构教条<br/>(将 SOLID 等经验法则绝对化)"] end subgraph Consequence["代际恶性循环"] B --> C["新一代开发者<br/>(只知教条，不知根本诉求)"] C --> D["产生低效膨胀的坏代码库<br/>(例如：长达4小时的编译时间)"] end ``` - **真实衡量标准**：诸如“编译时间长达数小时”等客观可衡量的指标，足以证明现行架构方法论的失败。 - **SOLID 原则的定位**：仅仅是某种随意的经验法则，绝不能代替对真实系统指标的度量与评估。 - **教学顺序倒错**：编程教育中忽视了对真实指标的量化评估，反而将抽象设计模式当作入门真理传授给下一代。 --- ### [41:26](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=2486s) 结语、Kickstarter 宣传与后续问答预告 Casey 宣布正课到此结束，并提醒观众查看视频简介中置顶的 Kickstarter 众筹链接。当时该图画小说（graphic novel）的宣传活动仅剩最后几天，预计视频发布后大约 5 天就会正式收官，他热情邀请有兴趣的观众支持并领取实体书。 关于后续内容，Casey 透露还将发布一个专门的 Q&A 视频。在当时的演讲现场，他回答了来自受邀企业员工的大量提问。出于保护现场提问员工隐私的考虑，他没有直接剪辑原声和现场画面，而是将每个问题整理在提示卡上进行总结，随后由他本人逐一给出详尽解答。他称赞现场提出的问题非常有水平，因此值得专门制作一期视频与大家分享。最后，他以一贯轻松幽默的风格与大家道别：“Until then, have fun programming everyone and I'll see you on the internet.” - **众筹项目**：视频下方提供了相关图画小说的 Kickstarter 链接，在该视频发布时众筹仅剩约 5 天结束。 - **隐私处理与 Q&A 形式**：后续问答视频中，企业提问者的影像和原声被隐去，由 Casey 将问题提炼到卡片上后亲自解答。 - **下一期发布时间**：Q&A 补充视频将在次日作为第二部分发布。 ## Notable quotes > [39:57](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=2397s) And that is we have stopped measuring and talking about what we actually want, and we are almost exclusively talking about or measuring things that are largely fictional; they don't directly connect back. — Casey Muratori > [36:19](https://www.youtube.com/watch?v=7YpFGkG-u1w&t=2179s) Don't just talk about 'this is clean code' — actually measure, have something we can measure. — Casey Muratori ## Mentioned Casey Muratori, Molly Rocket, Infura, Meow the Infinite, Kickstarter, Docker, TensorFlow, Stack Overflow, SOLID, WARMED, ARM-ED, Liskov Substitution Principle, Clean Code, GitHub, The Lord of the Rings ## Video description https://www.kickstarter.com/projects/annarettberg/meow-the-infinite-book-two Q&A: https://youtu.be/cOcaj_cRBvE Rebroadcast of an invited live lecture I gave to infura.io on https://www.twitch.tv/molly_rocket. The original had bad audio for the first few minutes, so I re-recorded and spliced it in for this corrected version. Otherwise, it is the same as the original live stream. [Source](https://www.youtube.com/watch?v=7YpFGkG-u1w)

[39:57] Casey Muratori: And that is we have stopped measuring and talking about what we actually want, and we are almost exclusively talking about or measuring things that are largely fictional; they don't directly connect back. [36:19] Casey Muratori: Don't just talk about 'this is clean code' — actually measure, have something we can measure.

[39:57] Casey Muratori: bad code just comes from that one simple failure, and that is we have stopped measuring and talking about what we actually want and we are almost exclusively talking about or measuring things that are largely fictional. [27:24] Casey Muratori: If what I'm targeting is SOLID, I'm by definition not targeting the actual computer, right?

[0:01] hey everybody casemirotori here we are [0:03] at the end of our kickstarter [0:05] promotional videos this is the last one [0:06] it's a two-parter if you haven't checked [0:09] out the kickstarter already please do [0:10] it's for a graphic novel meow the [0:12] infinite it's awesome we'd love to send [0:13] you a book or two please check it out [0:15] when you get a chance [0:16] this video is an invited lecture that i [0:19] gave to a company called infuria.io [0:22] and i submitted like a thing saying [0:24] please give me topics that that you'd [0:26] like me to cover and one of the things [0:28] that i saw in a lot of the topics that [0:30] came back was sort of this underlying [0:32] concept of like code kind of getting out [0:34] of control like being you know to huge [0:36] code bases and slow and underperforming [0:38] and so on [0:39] and so this was my attempt to give sort [0:41] of a general audience answer to the [0:44] question [0:46] where does bad code come from like where [0:48] do these problems come from [0:50] this is a two-parter the first part is [0:52] the lecture the second part will be the [0:53] q a so i hope you enjoy it and i'll be [0:56] back afterwards to talk about part two [1:00] where does bad code come from [1:03] we kind of know that it's everywhere [1:05] right now like [1:07] there's a sense if you have experienced [1:09] programming for a long time or if you [1:11] just in general look at the way things [1:13] are going from a [1:15] removed sort of more objective observer [1:18] standpoint you can see that there seems [1:20] to be a lot wrong with software today [1:23] and [1:24] first of all there's way too much code a [1:26] lot of the times even fairly simple [1:29] pieces of software now are like hundreds [1:32] of thousands of lines of code millions [1:34] of lines of code and so on uh they're [1:36] typically built in these [1:38] very very fragile build systems [1:41] oftentimes so complicated that they end [1:43] up having to be wrapped inside things [1:45] like docker containers or things like [1:46] this even to just try and get them to [1:49] keep running into the future because [1:51] they have so many crazy dependencies and [1:53] there's really no way to guarantee that [1:55] all the things will remain working or [1:56] will remain in lockstep as they move [1:58] forward [1:59] um when you actually do have everything [2:01] installed properly on your machine and [2:03] when you've finished having a package [2:05] manager install the language which [2:07] installs some package manager which then [2:08] goes and gets the packages which unpack [2:10] which install their own packages blah [2:12] blah after you manage to get all of that [2:14] going and you actually can run a build [2:15] the builds take forever sometimes things [2:18] like tensorflow or stuff like this that [2:20] a lot of people use that are very [2:22] popular projects seem to take hours to [2:24] build sometimes which is absolutely [2:27] incredible if you think about how much [2:29] power computers have today that the [2:30] things could take that long to build [2:32] when the actual software comes out the [2:34] other end the quality is not very high [2:36] there's a lot of sitting around waiting [2:38] for it to do things like load or [2:40] communicate with a network and it really [2:43] kind of just stalls while that's [2:44] happening and doesn't really let you do [2:45] very much [2:47] it's slow when it actually does things [2:49] things that probably should be much [2:50] faster on today's hardware are not [2:52] they're still quite slow [2:54] um it takes a ton of space as well so [2:57] not only do these programs now take up [2:59] huge amounts of space you have like 100 [3:01] 200 megabyte executables which is insane [3:04] and their working footprints are like [3:06] many gigabytes of memory even for doing [3:08] things that seem very simple like just [3:10] scrolling some 2d images or things that [3:12] are very basic nonetheless are taking [3:14] tremendous amounts of storage tremendous [3:16] amounts of memory it's just kind of very [3:18] odd that that would be going on and [3:21] finally it's not like software got [3:23] tremendously more reliable or something [3:25] else happened it's still totally buggy [3:28] and it has all the same problems if not [3:29] more problems than it has always had [3:32] before it sort of jumped uh this level [3:35] of sort of kind of complexity and and [3:38] kind of in general this this overall uh [3:41] overriding sort of sense of decay that [3:43] seems to be seeping in [3:45] to whatever we call the software [3:47] industry currently [3:50] and so [3:51] thinking about this if we want to [3:53] actually try and talk about where bad [3:56] code comes from we have to start making [3:57] some judgment calls about what do we [3:59] mean when we say bad code anyway i can [4:01] talk about all those things and and [4:03] complain about stuff but if i don't [4:05] really have some kind of a more specific [4:07] understanding of what it really is that [4:09] i'm talking about [4:10] it's not going to be possible for us to [4:12] like get anywhere we can't really get [4:14] anywhere fixing the problem we're just [4:16] sort of saying that the problem exists [4:17] which is great but we do have to then [4:19] figure out how are we going to move [4:21] forward so i'm going to make a little [4:23] bit of a judgment call here and say when [4:25] i'm talking about bad code or what we [4:27] should be concerned about with bad code [4:29] it doesn't really have much to do with [4:30] money if you're talking about wanting to [4:33] make money i don't think the current [4:35] environment anyway at least for the time [4:37] being [4:38] really cares that much about the quality [4:40] of your code i think there's so little [4:42] competition in the software space right [4:44] now because there's so much software to [4:46] write we're still relatively early in [4:49] the evolution of software there's still [4:52] so many places you can take software too [4:55] that there isn't a lot of market [4:57] pressure to ship high quality stuff a [5:00] lot of times consumers [5:02] or whoever your customers are are [5:04] choosing between a very small field of [5:06] options so being someone who ships a [5:09] quality product while it may be a [5:11] tremendous competitive advantage if you [5:13] do it [5:14] will not exactly be a requirement [5:17] competitively because other people are [5:19] not shipping quality software so you [5:21] really don't need this to make money yet [5:24] you might in the future but i'm not [5:25] gonna try and make an argument that you [5:27] need to do this uh for your financial [5:29] well-being of your company or your [5:30] career whatever or anything like that [5:32] and i'm also not claiming that people [5:34] aren't having fun or anything like that [5:36] they might not be it may be that current [5:38] software practices are really not fun [5:39] for them but it could be that you know [5:41] you just drop on your vr goggles and you [5:44] you download a bunch of frameworks and [5:46] you get them all called together [5:46] eventually and you just play around with [5:48] it and you had fun and it was okay right [5:49] who knows right so i'm not going to [5:51] claim either of those two things because [5:53] i don't think [5:54] there's really any need to go down that [5:56] route because all i'm trying to talk [5:57] about when we talk about bad code is [5:59] like [6:00] what's our potential like like what [6:02] could we be doing what could we be doing [6:05] engineering-wise [6:07] versus where we currently are are we [6:08] performing up to that potential at all [6:11] or are we actually kind of falling [6:13] pretty far behind [6:15] where we could be if we looked at what [6:17] we could be delivering to our customers [6:20] and to society if we took things more [6:23] seriously right so i don't think we have [6:25] to do this [6:26] it's just if you care about quality [6:29] what are we talking about here so that's [6:30] what i mean when i say bad code i say [6:32] we're looking at something that seems [6:33] like boy we should be able to do a lot [6:36] better than this [6:37] why aren't we right [6:40] now it's important to distinguish [6:41] between two things [6:43] i actually think [6:45] as an industry we haven't done that [6:47] poorly on algorithms [6:49] algorithms are actually understood in [6:52] some pretty profound ways i think the [6:54] people who have done all the work [6:56] figuring out like order notation and [6:58] what the complexity classes of things [7:00] are and you know they haven't proved [7:02] whether p equals np yet or whatever [7:04] but at the end of the day [7:06] there's a lot of stuff we know like we [7:08] know how to analyze hash tables and how [7:10] to think about them we know [7:12] uh like what the properties are of a [7:14] heap or what different sorting [7:16] algorithms will do like we have a lot of [7:18] ways of thinking about algorithms and [7:21] furthermore a lot of the advice you see [7:23] about algorithms may not be awful like [7:25] it's possible that in general you can [7:29] experience algorithms in a pretty sane [7:31] way you can be taught algorithms in the [7:33] same way [7:34] you can think about them the same way [7:35] that's actually i don't think all that [7:37] unusual so if i was to put a pin you [7:40] know if i was trying to point a finger [7:42] and say this is the place that i think [7:45] that we're going wrong [7:47] algorithms and like the actual specific [7:49] idea of specifically how some piece of a [7:52] program is going to work algorithmically [7:55] it just doesn't seem like what we're [7:57] really talking about when we're talking [7:59] about the bulk of bad code as we [8:01] perceive it or bad software as we [8:03] perceive it it's usually not like what [8:05] sorting you know algorithm did you [8:07] choose [8:09] usually what we're talking about is the [8:10] mess of the rest of the code we are [8:13] having a problem writing all the code [8:16] that glues these algorithms together [8:18] right like when we're talking about what [8:19] we're actually going to do here the [8:21] problem that we actually have is not so [8:23] much that like we couldn't sit down and [8:26] figure out what the proper algorithm is [8:29] here for this the problem seems to be [8:31] more that we can't figure out how to [8:33] connect these things or how to manage [8:35] the infrastructure into which these [8:38] algorithms are placed that seems to just [8:41] not work right it seems to be like that [8:43] is what's going off the rails [8:45] and so the question is how did we get [8:47] there [8:48] in the old days that really couldn't be [8:50] the case because there were hard [8:52] constraints on what you could ship when [8:54] a computer only has 64k of ram in it [8:57] right [8:58] there's no way for that glue code to [9:00] spiral out of control there's no way for [9:02] the infrastructure to be all that big to [9:05] begin with so there is a natural limit [9:08] on what could actually happen there and [9:10] it seemed to be working [9:12] to that effect nowadays we don't have [9:14] that [9:15] and it seems like we have never [9:17] developed any replacement for it [9:19] so the question is like [9:21] why and in order to understand why we [9:23] haven't developed a replacement for it [9:25] i'm going to have to talk a little bit [9:26] about how you actually learn to make [9:28] stuff like on a computer [9:31] and i realize it's going to sound very [9:32] trite maybe to people who are listening [9:34] to this who aren't programmers it won't [9:36] but to people who are programmers this [9:38] is gonna sound uh a little bit silly [9:40] right but please [9:42] think about it actually think about this [9:45] for a second because if you actually [9:47] think about it for a second you'll [9:48] realize that we all take it for granted [9:51] right we all take for granted that this [9:53] is going on and nobody talks about it [9:55] but we kind of need to right [9:58] so nobody's born knowing how to program [10:00] a computer right and and i know this [10:02] better than anybody because i learned a [10:04] program at a very early age but before i [10:06] could learn to program i actually [10:08] literally sat i was a little tiny child [10:11] i sat at a keyboard right that my [10:14] parents had my dad had i would just type [10:17] i would type gibberish into the computer [10:19] right and if you think about it like you [10:22] first learn to just input characters or [10:24] something into a computer and if you're [10:26] young enough they're literally just [10:28] garbage [10:29] but soon what you're doing is your brain [10:32] right is training itself up [10:35] to learn that only certain combinations [10:37] of letters right only certain syntax [10:41] will produce a result if you're using a [10:43] programming language this is why we call [10:45] them languages right they have grammar [10:46] they have syntax all this sort of stuff [10:48] right [10:49] and so something in your brain [10:52] and we're not advanced enough [10:54] technologically to know like what's [10:55] actually going on exactly but something [10:57] in your brain [10:58] is creating [11:00] a filter and a generator [11:03] something that's able to produce valid [11:05] syntax for a particular language [11:08] and also able to like you know throw out [11:12] ones of those that it wouldn't want or [11:14] wouldn't need or that don't get closer [11:16] to something right [11:18] it's got a metric [11:19] and so if you think about this in terms [11:21] of like ai research or something like [11:23] that right [11:24] there's a training process you have to [11:26] train up some generator to generate [11:29] things that are valid in the output [11:30] domain and then you need some kind of [11:33] filtering process that's going to take [11:35] and get you closer to whatever it is [11:37] that you're trying to achieve with that [11:39] generative process right and so this [11:42] builds and builds over time when you're [11:44] a programmer right it builds over time [11:46] and in your head you start to learn that [11:48] you can make new parts of this right [11:51] like functions and things like that or [11:53] get new ones from libraries and you're [11:55] starting to think at like a higher level [11:56] so that generator is now generating [11:58] things higher up and again filtering [12:00] things higher up [12:02] and then finally you look at experienced [12:04] programmers people in printer a long [12:05] time not necessarily good or bad just [12:07] experienced [12:08] their code just be very regularized [12:11] right so that filter has dialed in quite [12:14] a bit right they're throwing out a lot [12:18] of possible options that would be legal [12:20] in the language they're programming at [12:21] and only selecting from a very very [12:25] narrow set so that generator filter [12:27] process is producing highly regularized [12:30] very predictable things at that point [12:33] which we don't know what that means [12:35] right and we can't understand it at a [12:37] deep under like you know uh [12:40] physiological level [12:41] but what we do know is it means a huge [12:44] possibility space has been carved off [12:47] of that system [12:49] we all know that when we first learned [12:51] to type in babel like you know just the [12:53] literal syntax of the language [12:55] anything was possible right [12:58] you just type anything in that was legal [12:59] in the language and you could type it in [13:01] right [13:02] and over time you lose the ability to [13:05] type certain things in [13:07] and it's not like you couldn't force [13:09] yourself to [13:10] it's just you don't right [13:12] so you've tuned the generator and the [13:14] filter in your brain to just do a [13:15] certain narrow subset of things [13:18] and what we think when we think of [13:20] experienced programmer is that that was [13:22] good that was a good process now they're [13:25] producing like good code or something [13:27] right [13:29] i know it sounded silly hopefully though [13:31] when we get to the end there you're not [13:33] too disagreeing with me about the fact [13:35] that something like this must be going [13:37] on in our brains [13:38] so our brains have learned this filter [13:40] process this thing that's going on and [13:42] we all have a slightly different one [13:44] right [13:46] but anyone who's been programming for [13:47] any appreciation of time has formed this [13:49] somehow [13:51] now i like to think of this as a [13:53] metaphor uh in my brain i always kind of [13:55] think of it this way [13:56] because i don't really know how to think [13:57] about it and the way i think about it is [13:59] exploration right [14:01] i started out in my co-bases in some [14:04] sense and i think of that generator [14:06] process as sort of being like almost [14:08] like a navigator right like at any point [14:10] in time when i'm going to figure out [14:12] like what i'm going to do in the code [14:14] i'm sort of like thinking like it's like [14:15] dead reckoning a little bit it's like [14:17] well i think the answer is probably this [14:18] way i'm gonna try some things sometimes [14:20] i backtrack right [14:22] um and i'm i'm trying to navigate and [14:24] over time i'm trying to get to a [14:26] destination that i believe is somewhere [14:27] but i don't know exactly where it is [14:29] right and maybe you've had this feeling [14:31] as well like this kind of feeling like [14:32] you know it's it's sort of a journey [14:34] right it's not it's not like things the [14:36] metaphors people normally use don't [14:38] actually apply that well it's not like [14:40] architecture right it's not like other [14:43] things where we do a lot of solving [14:45] first and then just kind of [14:47] put it in there uml diagram people have [14:50] tried right but it doesn't seem to [14:52] really go that way it feels more like a [14:54] journey where we're not really sure [14:56] about the end result and we're trying to [14:58] get there right and maybe the better [15:00] programmers are kind of better at making [15:01] that journey and the newer programmers [15:03] who have a lot to learn that you know [15:05] it's worse right but it feels that way [15:07] to me it feels more like that [15:09] and we don't have maps right we're [15:12] navigators that don't know the lay of [15:14] the land so we're constantly trying to [15:16] like kind of figure out [15:18] as we go that's how i normally think [15:20] about it and i think about like you know [15:22] when we're you know setting off on these [15:24] things and looking for things they could [15:26] be very like uncharted we could be [15:27] trying to go somewhere that like no [15:28] one's ever gone before [15:30] or we might be just trying to do [15:31] something we do know pretty well and we [15:33] kind of understand the route but we [15:35] might do a little bit differently this [15:36] time because we know how the route went [15:38] last time and we think we could improve [15:39] it things like that right [15:41] now sometimes this works great we end up [15:44] in a place that we you know it's [15:46] fantastic it's everything we dreamed of [15:48] when we thought we were going to go [15:49] there [15:50] other times we just like forget it this [15:52] thing ain't shipping [15:53] ditch the boat take as much food as you [15:55] can walk across the iceberg and let's [15:58] hope uh that like we encounter another [16:01] human being before we all die right [16:03] so you know it it [16:05] it has sort of the same analogies in a [16:07] way the way it ends is similar to the [16:09] way uh journeys end in the real world [16:11] too sometimes [16:13] now the path we took to get there i kind [16:14] of alluded to this [16:16] has implications uh we can think of that [16:18] as how the development process went so [16:20] you know if if this went really straight [16:22] and clean um you know we were just like [16:25] okay that was great that was easy right [16:27] if it was sort of like really messy and [16:29] kind of all the way around like you know [16:31] sort of uh [16:33] really circuitous or we had to backtrack [16:35] a ton of times you know maybe that was a [16:36] rougher development process [16:39] okay [16:40] the place we end up [16:42] is kind of how i think of like what [16:43] we've achieved right it's like the [16:45] quality like like i did this journey i [16:47] ended up somewhere and you know when i [16:50] get there i know you know this is kind [16:52] of why it's a navigational process with [16:54] software it's like i don't necessarily [16:56] know exactly what the thing will be at [16:58] the end sometimes i don't even really [17:00] know at all what the thing will be at [17:01] the end but i will know like when i get [17:03] there or when i get close enough to it [17:05] right and that's why it's a very [17:06] navigational process because much like a [17:09] kind of function where you can only [17:10] evaluate it at points and you can't [17:12] predict really what it's going to be [17:14] very well [17:15] we just kind of only know did we you [17:17] know if we're setting from if we're [17:19] trying to go from south america to [17:20] africa right [17:22] we will probably know when we hit land [17:24] but before then we may not really know [17:26] how it's going but we will know when we [17:28] get there and when we talk to the people [17:29] there we'll be like is this africa and [17:31] they'll be like yes right or something [17:33] right so we'll kind of know when we get [17:34] there but we won't necessarily know and [17:36] even when we actually get there we might [17:37] not know where we are exactly in that [17:40] area either like maybe we were aiming [17:42] for uh south africa and we end up in you [17:44] know up in egypt somehow or something [17:46] like this right so i kind of think of it [17:48] as this where we end up is sort of the [17:50] quality of the result [17:52] so what we're sort of seeing when we [17:54] talk about the bad code situation right [17:58] is in these processes i feel like we're [18:00] just getting horribly lost like we're [18:02] just kind of not only are we just like [18:04] kind of aimlessly creating these huge [18:06] routes through things that are very [18:08] wasteful and take way too much time and [18:09] all these other sorts of things but also [18:12] when we end up somewhere it doesn't [18:14] really seem to be very good like it [18:15] seems like we're kind of nowhere near [18:17] where we wanted to be right [18:20] and it feels this way sometimes too this [18:22] is another reason i like this analogy [18:23] someone's in the middle of a development [18:24] process or even at the end you're just [18:25] like oh man we totally lost our way like [18:27] like we can't even really see how we [18:29] would get there and furthermore another [18:31] reason that i like this analogy is [18:33] because it feels this way in the moment [18:35] too sometimes sometimes you're like i [18:37] just don't know [18:38] what we would do [18:40] to get past this like very it's like [18:43] it's very like intangible in that way [18:45] you can't quite put your finger on why [18:47] the code isn't coming out or what you [18:49] should do you're doing things that you [18:51] thought [18:52] right should get you further and they're [18:55] not or they're just knocking you back or [18:57] it just doesn't seem coming better it's [18:58] very like it feels like being lost in a [19:00] lot of ways [19:03] okay so in order to understand [19:06] why that [19:08] sort of [19:09] process might be going wrong [19:12] i want to put the blame [19:15] because i have an opinion about what is [19:17] to blame for this process going wrong [19:20] i just want to put the blame [19:22] on how we construct [19:25] that navigational process that filter [19:27] process in the brain of like navigating [19:29] what we're going to do [19:31] as we go code both institutionally and [19:33] individually how we do that [19:37] building up that part of brains i think [19:40] we're now doing a horrible job [19:42] in the old days the lack of resources [19:45] the 64k of the machine the fact that it [19:48] was a 6802 processor which could barely [19:50] do anything the fact that loads from [19:52] disc took you know eons [19:55] meant that that development of that [19:58] process in anyone's brain who could ever [20:00] get a program to work at all [20:02] they had already gone through the [20:04] process of actually being very aware [20:07] of what they were doing [20:09] everything they did [20:11] would either succeed or fail at all [20:14] based on whether the software was any [20:17] good right because even a slight bit of [20:20] being bad meant you couldn't get the [20:22] thing to work at all in such harsh [20:24] environments right it's sort of like if [20:27] the explorers were trained in the arctic [20:29] right [20:31] then all of them died who who weren't [20:34] really good or didn't learn really fast [20:36] right [20:38] so how are we doing this process now [20:40] well you know to a certain extent some [20:42] people are still doing it individually [20:44] and that tends to also be [20:47] highly coincident with people who maybe [20:50] aren't causing [20:51] quite so much of the uh the bad code [20:53] explosion but you know probably everyone [20:56] to a certain extent does work [20:57] individually and that's just you [20:59] naturally experiencing things there [21:01] isn't like an external force kind of [21:02] pushing at you there you're just playing [21:05] around and learning on your own [21:07] but the vast majority of these uh the [21:10] tuning that happens in those processes [21:11] now doesn't come from that because again [21:14] the resources are almost limitless there [21:16] and there isn't much of a weeding out [21:18] process that can really happen it's not [21:20] like on an old home computer that was [21:22] really difficult to use where you would [21:24] have to get good automatically because [21:26] otherwise you'd never be able to do it [21:27] or you just quit and go do something [21:29] else [21:30] so a lot of times where things come from [21:32] is like classes universities things like [21:34] that um it might come from like code [21:37] reviews or like mentors like there's a [21:39] programmer who ostensibly knows [21:40] something [21:41] and they're going to tell you that thing [21:42] or tell you what to do [21:44] um you know maybe your boss is really [21:46] mad and you get a bad performance review [21:48] or maybe he's really happy you need a [21:49] good one so you're calibrating based on [21:52] you know that was good that was bad i [21:53] don't know [21:55] you're gonna go read stack overflow [21:57] something like this right uh and you're [21:59] gonna look at what people said in there [22:02] you know what are the answers that are [22:03] voted up that's kind of like learning [22:05] what you know supposedly you're supposed [22:06] to do you go to lectures this lecture [22:08] for example right you're gonna listen to [22:10] someone talk and you know they maybe [22:11] they change your mind or maybe just [22:13] accept what they say maybe you're [22:14] critical of what they say i don't know [22:15] but you know you get some input that way [22:17] and it affects what's going on in here [22:19] and again [22:21] when i look at this i don't think we're [22:23] doing a terrible job when it comes to [22:25] like algorithms or stuff like that if [22:27] someone goes online and tries to search [22:30] for how to sort something [22:32] i don't necessarily think that they're [22:34] going to find like really bad [22:36] information all the time i don't think [22:38] that's going to happen you're probably [22:40] going to be able to find the resources [22:41] you need to learn how that sort of thing [22:44] works [22:46] so what i'm really talking about [22:48] is i'm talking about that other [22:50] style of code right the other the part [22:53] that's not the algorithm exactly itself [22:55] it's everything else it's all of the [22:57] infrastructure it's all that other stuff [23:00] that isn't really studied in the same [23:02] kind of way right we don't have order [23:04] notation for it or anything like that [23:08] and [23:09] pervasively like all throughout [23:11] everywhere in the industry what you will [23:13] see [23:14] is things that are sort of vague [23:17] statements [23:18] about the quality of that code [23:20] like it's clean right we're gonna we're [23:24] really washing the code like it's very [23:26] clean code if you do these things the [23:28] code will be clean right [23:30] this sort of thing [23:32] and what we see is people are taught [23:34] things [23:35] that are ostensibly going to make their [23:37] code clean [23:39] now they're never really taught [23:41] what clean code is [23:44] because nobody has a definition for [23:46] clean code [23:48] what they have is a series of things [23:50] you're supposed to do [23:52] in order to make the code clean [23:55] right like in other words we don't have [23:57] a thing that's like a program you run [24:00] that says yes clean code no not [24:02] right [24:04] what we have is things you're supposed [24:06] to do and then the code is clean that's [24:09] all we know [24:10] so you see acronyms like solid [24:12] this is taught a lot right [24:16] and if you look at the things on there [24:18] none of them [24:20] have any real world definition they're [24:23] not things that happen inside a computer [24:26] they're things that happen entirely in [24:29] your head [24:30] they are things that affect [24:32] what code you think you are allowed to [24:35] write that filter [24:37] is being trained [24:39] to use these metrics [24:41] which are largely fictional they're [24:44] imaginary metrics we came up with they [24:46] don't correspond to a [24:48] hard measurable fact of a cpu right so [24:51] we made them up [24:53] you're being trained not to write code [24:56] that would violate these or to write [24:58] code that would like evince these right [25:02] now lest you think i'm joking when i say [25:04] that this is something that people are [25:06] taught to do because some people are [25:07] like what are you talking about no one [25:08] teaches that well [25:09] literally when i went to go grab the [25:10] screenshot for stack overflow when i was [25:13] like uh gonna put a slide for that well [25:16] this was their blog right [25:18] so literally the day i happen to grab [25:21] the screenshot their blog is telling [25:23] people to do this on stack overflow the [25:26] place where people go to get programming [25:28] answers right [25:31] so [25:32] what these things [25:34] all have in common because solid's not [25:36] the only one there's plenty of other [25:38] things like this where we teach [25:40] clean code or try to convince people to [25:42] write clean code [25:44] what they all share is one very [25:47] important very bad characteristic and [25:49] that is they do not attempt to measure [25:52] anything [25:54] there is no measurement of anything [25:58] that we would actually care about [26:01] it's simply implied [26:03] that things we actually care about would [26:06] happen [26:08] if you follow these things [26:10] right [26:12] if you take your code [26:14] and you make sure [26:15] that it obeys the list off substitution [26:17] principle for all like classes that [26:19] could be substituted or something [26:22] nobody has any argument anywhere that [26:24] i've ever seen that suggests that that [26:27] actually improves some real world metric [26:30] that we've measured [26:32] the assumption [26:34] is that if you do that your development [26:37] process will take less time or be [26:38] smoother or have less bugs or something [26:41] the code will be cleaner it's just an [26:43] abstract statement [26:46] that if you do these things the code [26:48] will be cleaner and somehow [26:50] that will affect something you can [26:52] actually measure but we're never going [26:53] to say what that something actually is [26:55] or try to quantify it [26:58] now [26:59] i mean seriously look at these things [27:01] right is any of those teaching somebody [27:04] to actually think about a real effect [27:08] no [27:09] they're teaching people something [27:11] they're supposed to do [27:12] which is taking that filter and [27:14] modifying it [27:15] but it's not actually giving it any [27:18] actual guidance about like a metric or [27:20] something they're trying to accomplish [27:22] it's just wrote [27:24] now to me that's just like a ritual [27:28] right [27:29] if you're literally just saying like you [27:32] do these sets of things and the code is [27:34] clean it's very much like oh you know [27:36] like like we're gonna bless the food [27:38] before we eat it right [27:40] and these might make you feel better [27:43] and you may want to do them [27:46] but at the end of the day [27:48] they are not directly tethered to [27:51] anything we actually care about [27:54] rituals [27:55] may have served a purpose once or they [27:57] may never have served a purpose [27:59] and when we do them today what we're [28:01] largely doing is just doing them because [28:03] someone told us to do them they claimed [28:05] that by doing them we would get some [28:07] outcome but we're never really told [28:10] how those rituals were supposed to [28:12] really accomplish that we're just [28:14] supposed to assume that they do [28:17] now this is troublesome because [28:19] computers are actual things [28:21] the model in your mind of what i'm [28:24] targeting when i'm trying to make my [28:26] code and i'm trying to do that filter [28:28] that process the generator filter [28:30] process in my brain [28:33] if what i'm targeting [28:35] is solid [28:37] i'm by definition not targeting the [28:39] actual computer [28:41] right [28:42] the thing that i'm supposed to be [28:43] worrying about which is a computer that [28:45] runs this code is nowhere to be found in [28:48] that acronym right it's not there [28:50] anywhere [28:52] furthermore i'm not measuring my [28:54] development time solid nowhere in it [28:57] says hey by the way [28:59] actually these are all just supposed to [29:01] save development time so if you end up [29:02] seeing that you're not saving [29:03] development time stop doing it right [29:05] nobody says that [29:08] right [29:11] so i don't want to give you a new [29:13] acronym [29:14] because i don't think it's very useful [29:17] but to underscore the difference between [29:20] that acronym and what i would have [29:21] expected to see the trite acronym be [29:25] i would expect it to be something like [29:26] this i even arranged it in a way you can [29:28] say warmed just like solid [29:32] and what this is is just say look [29:34] if we're gonna teach something that goes [29:36] up in the filter [29:37] what it should be [29:38] is the actual things that programmers [29:41] need to care about [29:44] and then if something like solid was [29:46] actually a good idea [29:47] you would be able to evaluate that very [29:50] effectively by caring about things we [29:52] actually do and to me those things are [29:55] writing the code [29:57] agreeing on code if we have to have more [30:00] than one person [30:02] reading code because not only did we not [30:04] write all the code usually but even if [30:06] we did we might forget what we wrote so [30:07] we have to be able to read it we're [30:08] still to modify the code the code has to [30:11] execute on hardware [30:13] and then we have to be able to debug it [30:14] right [30:17] now if you look at these things maybe [30:18] you would say argue is better because [30:20] like coders don't agree on stuff they [30:23] argue about stuff right but either way [30:25] whichever one you want to think of it [30:27] it's still the same acronym so you know [30:29] i made sure that would work [30:31] now each of these things is a cost right [30:34] that's what i'm talking about each of [30:35] those things is a cost [30:37] execution is a cost of the actual [30:40] computation it's the most important cost [30:42] the e right how much does it cost to [30:45] execute this thing on the end user's [30:46] computer they're the people who are [30:48] ostensibly paying us and we are wasting [30:50] their time if that cost is very high [30:53] because we've shipped them something [30:54] lousy right [30:55] the rest of the cost or development time [30:58] right and those affect the customer [31:00] because if we never get the code done or [31:03] if it takes us too long to fix problems [31:05] in the code or if it takes us too long [31:06] to add features that affects the [31:08] customer too so all of those things are [31:10] costs that we ostensibly care about and [31:12] while i would say maybe execution should [31:14] be prioritized they're all important [31:16] right you can't just focus on one of the [31:17] exclusion of the others so what you're [31:19] trying to do is figure out a way to [31:21] minimize all those costs and you kind of [31:23] want to minimize as many of them as you [31:24] can with maybe different weights on them [31:26] depending on what you care about most [31:28] but that's what you're doing [31:31] so again pretty simple right [31:34] i've never seen anything like this [31:37] you don't go to conferences and have [31:38] people say like look this is what we [31:40] should be caring about [31:41] let's try to evaluate things on these [31:43] any you know people maybe throw up their [31:45] hands and say well you can't possibly [31:47] measure these things yes you can [31:49] i mean it's very easy to measure how [31:52] many github back and forths people have [31:55] before they actually fix an issue [31:57] it's easy to measure how many meetings [31:59] you're having it's easy to measure how [32:01] long it took you to write this piece of [32:02] code right [32:04] we are an industry that does [32:06] an infinite amount of a b testing on our [32:08] users and yet somehow we don't seem to [32:11] think it's very important to actually do [32:14] like a b testing with any kind of [32:15] metrics on any of the stuff we claim [32:17] we're supposed to be doing right [32:21] so let's try to bring it back to [32:24] bad code where does it come from [32:28] well i tried to give you the analogy [32:30] programmers are explorers they're [32:32] starting from somewhere [32:34] and they have a vague destination in [32:35] mind that they've been told to get to or [32:37] that they picked [32:38] and they have to get there but they [32:40] don't have any real knowledge of where [32:42] it is [32:44] well in this analogy what we've done [32:46] with all the stuff i just said [32:48] is effectively instead of giving this [32:49] something like a compass we just give [32:51] them tools that don't make any sense [32:53] we're even like a hammer and a tape [32:54] measure or something like that right and [32:56] we're like here you go set off on this [32:58] journey here's a hammer [33:01] now the worst part about it is it's not [33:03] even as bad as giving someone a hammer [33:04] because the real world person would know [33:05] that the hammer was useless to throw it [33:06] away [33:07] we've told them that this hammer [33:09] is critical for navigation so they're [33:12] like trying to like hold it up to the [33:14] sun or something and figure out like [33:15] which directs they're going they have no [33:17] idea that we've given them tools that [33:19] are not even relevant to the problem [33:21] that they're solving they're not [33:22] actually tools that measure anything [33:25] they're just arbitrary we just gave them [33:27] to them and and said here you go right [33:31] similarly we spent all our time talking [33:33] about a map that doesn't exist [33:35] we're talking about things like liskoff [33:37] substitution principle as if that has [33:39] something to do with programming [33:41] now it has something to do with certain [33:43] ideas in certain languages that someone [33:45] hypothetically thought might be [33:47] important [33:48] but it's entirely fictional it's like [33:51] middle earth right [33:53] your lord of the rings might be a great [33:54] story [33:55] but if you actually need to get from [33:57] south uh south america to africa [34:00] it's not gonna help you to be thinking [34:01] about like where mortar is on a map [34:03] right [34:04] you have a mental model that's been [34:06] tuned for things that have nothing to do [34:09] with the actual stuff you're trying to [34:10] solve [34:12] so we shouldn't be surprised when like [34:14] new programmers [34:15] come up and they just do ridiculous [34:17] stuff and these things will not control [34:20] because [34:21] they had no metrics they had nothing to [34:23] tether them back [34:24] to what they were actually trying to [34:26] accomplish we basically made their [34:28] entire filter process be about things [34:30] that are different from the actual [34:32] things we want to achieve [34:34] what else would we expect [34:36] right [34:39] so i think in modern day [34:42] when you've gone up through that system [34:44] and you didn't have the luxury [34:46] or the hardship depending how you want [34:47] to look at it [34:49] of having to do programming in a [34:51] constrained environment [34:53] you end up thinking that things are [34:55] completely insurmountable you're like [34:57] you're like i don't know how we would [34:59] ever do [35:00] this program any differently than what [35:02] we're doing right it's got to be a [35:04] million lines of code and super slow and [35:07] buggy and well like like this is just [35:08] how it's done [35:10] you can't even envision what the other [35:12] thing is because you haven't ever been [35:14] given the tools to get there right and [35:16] furthermore you're going to do you're [35:18] going to have been taught a lot [35:20] that code reuse is good [35:22] well the problem is the code that you're [35:24] going to be reusing right [35:26] i mean that's like in the narrative the [35:27] analogy of navigation that's like base [35:29] camp right it's like starting out at a [35:32] camp that someone else made [35:34] well the problem is they were lost too [35:36] they had no idea where they are so [35:38] you're typically taking a library made [35:40] by somebody who didn't really know what [35:42] they were doing and that's your new [35:44] starting point right [35:45] so people who failed to get to a [35:48] destination that we wanted to go to [35:50] are now also the jumping off point and [35:53] this gets worse than libraries whole [35:55] languages [35:56] whole platform ecosystems are this way [36:00] so we're literally starting our [36:02] navigators off [36:04] already lost in the wilderness with no [36:06] chance of ever getting to the to the [36:08] actual place making it way harder than [36:10] it would have been if we just started [36:11] back in port originally right [36:14] but they don't know that [36:16] because we've never been measuring any [36:17] of this [36:19] so can this be fixed [36:21] i mean sure i think it could obviously [36:23] be fixed because we have examples in the [36:25] past of programmers being trained up not [36:27] to do these things right [36:30] and so i think the first thing we need [36:31] to do is like start talking about the [36:33] real world [36:35] whenever we're talking about something [36:38] conferences [36:39] programming language constructs all [36:40] these things [36:42] we should be talking about how it [36:45] actually affects the results [36:48] what construct a real argument for how a [36:51] number goes down in the cost category [36:54] right [36:56] we should be giving people tools like [36:59] the one i suggested that actually [37:02] measure something we care about not [37:03] something we just assume that we care [37:06] about because [37:09] that will lock it in right [37:11] all of these things are very much like [37:14] the sort of navigation base camp analogy [37:16] any time we start someone off from a [37:18] place that we haven't verified is [37:21] actually really good [37:22] we create a huge problem for all the [37:24] things they will do in the future right [37:28] and [37:29] when i [37:30] talk about things like that [37:32] what i'm saying is don't just say stuff [37:36] right don't just talk about [37:38] this is clean code [37:41] actually measure [37:42] have something we can measure [37:45] this produced less lines of code for the [37:47] same equivalent execution right [37:51] not it's less lines of code because if [37:53] it's less lines of code but it runs [37:55] worse that didn't help anybody this is [37:57] less lines of code it's easier for [37:59] people to read why not because we talked [38:02] about it and decided it was easier to [38:04] read [38:05] but because we actually checked when a [38:07] new person comes to the company they are [38:09] now able to read the code faster [38:12] it used to take a day for them to like [38:14] read this [38:15] part and come up to speed on it now it [38:17] takes two hours right [38:19] we can measure this stuff it's real [38:21] world stuff [38:23] right [38:24] and of course [38:25] start actually putting measuring the [38:28] performance of things people actually [38:30] knowing what the performance of [38:31] something should be [38:32] that should have been fundamental the [38:34] whole time right [38:36] the acronym solid should never be [38:39] allowed to exist [38:40] if it doesn't have like [38:43] p solid like performance right like [38:46] there should have been something about [38:47] how do any of these things that you're [38:49] doing affect the actual run time of the [38:52] program [38:54] so [38:56] again [38:58] this is just my take on it a lot of [39:00] these things are very difficult to prove [39:02] or disprove because we don't have [39:04] formalisms for them the way we do for [39:06] things like algorithms one of the [39:07] reasons algorithms are probably better [39:10] in terms of how far they've developed is [39:12] because we can test them more concretely [39:15] we have a language to talk about them [39:17] but i don't fundamentally think these [39:19] problems of the code that's not the [39:22] algorithm [39:23] are as impenetrable as we're making them [39:25] out to be [39:27] we just need to actually focus on [39:31] something we can point to something we [39:33] can measure [39:35] why does tensorflow take four hours to [39:38] build [39:39] or whatever it takes [39:40] nowadays why [39:43] that should not be happening [39:45] it does not do anything that complicated [39:48] right [39:49] so how did we get there [39:51] we can measure that we know what's going [39:53] on [39:54] and we know the kinds of things the [39:57] kinds of filter processes that we've [39:59] been putting in people's heads result [40:01] in code bases like that [40:03] we need to start [40:05] like actually nailing those down and [40:07] saying no [40:08] don't teach people to do these things [40:10] anymore they're producing obviously bad [40:13] results that we can measure because [40:17] it takes for our hearts to build right [40:19] we can tell [40:22] so [40:23] hopefully that gives a little bit of [40:25] perspective on how i think about where [40:27] bad code comes from [40:30] i wish i had an answer that was more [40:32] magical [40:33] but at the end of the day i really think [40:35] that bad code just comes from that one [40:39] simple failure [40:40] and that is we have stopped measuring [40:43] and talking about [40:45] what we actually want [40:47] and we are almost exclusively talking [40:49] about or measuring things that are [40:52] largely fictional [40:54] they don't [40:55] directly connect back [40:57] and once you make that jump [41:00] the next generation never knows about [41:03] the earlier part right they only see [41:05] solid [41:06] they don't know [41:08] that there's all these other things they [41:09] should actually have been thinking about [41:11] and solid was just someone's random idea [41:14] about maybe some good rules of thumb [41:18] but you'd never teach that as your first [41:20] thing right you'd always teach the [41:23] evaluation of real metrics first [41:26] that was the end of the lecture i hope [41:28] you enjoyed it uh like i said please [41:30] check out our kickstarter links in the [41:32] description below we'd love to send you [41:34] a graphic novel or two if you get a [41:35] chance we only have a few days left [41:37] because this is the end of our whole [41:38] promotional thing and the kickstarter [41:40] wraps up in like five days i think from [41:42] when this video will be posted so please [41:44] check it out if you get a chance there [41:45] will be one more video it's the q a for [41:48] this so after the lecture i took [41:51] questions uh from the actual employees [41:54] of the company uh to whom i was [41:56] presenting so i didn't want to put them [41:59] into the actual video so what it will [42:02] actually be is like i will summarize the [42:03] question like on a card and then i'll [42:05] answer it so you can see my actual [42:07] answers but without the actual people [42:09] who asked the questions but there were [42:10] some good questions so i wanted to [42:12] provide those as well so i'll be back [42:13] here uh for part two tomorrow until then [42:16] have fun programming everyone and i'll [42:18] see you on the internet