Muratori Faults Clean Code Dogma as Virtual Calls Blind Compilers

Ryan Peterman

Dogmatic clean code rules ruin software performance because hiding concrete types behind virtual dispatch prevents compilers from inlining and auto-vectorizing code.

AI-assisted summary of "Clean Code", Horrible Performance | Casey Muratori — original source. Check the original for full context.

Source published: 2026-10-08

Key ideas

Casey Muratori explains that the primary performance cost of 'Clean Code' dogma is not the vtable dispatch itself, but how virtual boundaries prevent compilers from inlining, unrolling loops, and applying SIMD vectorization. (0:00)
Foundational software literature, including Clean Code and Refactoring, frequently dismisses performance trade-offs under the guise of avoiding premature optimization, leading to systemic architectural degradation. (5:00)
The rise of generative AI makes performance awareness essential, as developers must understand underlying machinery to properly direct AI coding agents away from bloated and inefficient architectural patterns. (5:00)
Acquiring baseline hardware and performance intuition requires minimal training that permanently equips developers to delay concrete optimizations safely without architecting themselves into dead ends. (10:21)

Detailed notes

## Background Published by Ryan Peterman on YouTube on October 7, 2026, this video features game developer and computing educator Casey Muratori. The excerpt is taken from a broader conversation exploring surprising discoveries from computer history, the root causes of bad software, and Muratori's career path.

## TL;DR Casey Muratori explains why dogmatic 'clean code' principles—specifically tiny functions hidden behind dynamic virtual dispatch—devastate compiled code performance by preventing compiler inlining, loop unrolling, and SIMD vectorization. He critiques influential literature like Clean Code and Refactoring for fostering a culture that treats performance as an afterthought under the guise of avoiding premature optimization. Instead of blindly applying rigid readability rules or leaving architecture to chance, Muratori argues that engineers and developers directing AI coding agents need basic hardware awareness so they can make conscious architectural trade-offs without painting codebases into unrecoverable corners.

## Atmosphere & style The exchange carries the grounded, thoughtful intensity of a pragmatic systems programmer deconstructing widely accepted software orthodoxy. Muratori speaks with clear-eyed conviction and technical precision, patiently distinguishing between sensible code hygiene and destructive architectural dogma without slipping into sensationalism. Peterman provides an engaged, reflective sounding board, prompting an illuminating discussion that feels like an indispensable reality check against modern software bloat.

## Bulletin - [00:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=0s) Casey Muratori explains that the primary performance cost of 'Clean Code' dogma is not the vtable dispatch itself, but how virtual boundaries prevent compilers from inlining, unrolling loops, and applying SIMD vectorization. - [05:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=300s) Foundational software literature, including Clean Code and Refactoring, frequently dismisses performance trade-offs under the guise of avoiding premature optimization, leading to systemic architectural degradation. - [05:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=300s) The rise of generative AI makes performance awareness essential, as developers must understand underlying machinery to properly direct AI coding agents away from bloated and inefficient architectural patterns. - [10:21](https://www.youtube.com/watch?v=czr1L3JocOI&t=621s) Acquiring baseline hardware and performance intuition requires minimal training that permanently equips developers to delay concrete optimizations safely without architecting themselves into dead ends.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=0s) The phrase 'clean code' lacks universal consensus; Muratori's critique focuses specifically on the dogmatic rules presented in Robert C. Martin's book Clean Code. - [00:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=0s) Mandating microscopic 4- to 5-line functions interacting through abstract base classes strips compiled languages like C++ of the type information needed for cross-boundary optimization. - [00:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=0s) Branch prediction can make virtual function calls relatively cheap, but the inability of the compiler to see concrete types causes massive optimization loss by blocking inlining and auto-vectorization. - [00:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=0s) Writing 30- to 50-line functions with concrete types known at compile time preserves high readability and maintainability without incurring severe optimization penalties. - [05:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=300s) Prominent engineering texts frequently misapply adages like 'premature optimization is the root of all evil' to rationalize omitting performance considerations entirely from software education. - [05:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=300s) Genuine engineering requires intentionally weighing trade-offs and accepting known performance compromises, rather than pretending execution efficiency can always be handled later. - [05:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=300s) Engineers using generative AI models must possess low-level performance literacy to avoid prompting or accepting generated code structured around inefficient patterns. - [09:01](https://www.youtube.com/watch?v=czr1L3JocOI&t=541s) Grasping basic distinctions such as network latency versus network throughput enables engineers to structure code for batching upfront rather than producing purely serial architectures. - [09:01](https://www.youtube.com/watch?v=czr1L3JocOI&t=541s) Cultivating an accurate mental model of how hardware operates is the highest-leverage skill for preventing architectural choices that require complete codebase rewrites. - [10:21](https://www.youtube.com/watch?v=czr1L3JocOI&t=621s) Performance training is a one-time learning investment that functions as an ongoing internal alarm bell whenever a proposed design lacks a viable path to efficiency. - [10:21](https://www.youtube.com/watch?v=czr1L3JocOI&t=621s) Maintaining a clear conceptual roadmap for future performance improvements allows developers to safely defer actual optimization work without painting themselves into a corner.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=0s) Deconstructing "Clean Code" and the Dynamic Dispatch Trap

Ryan Peterman brings up an earlier point of discussion regarding the trade-off between writing performant code versus maintainable code, pointing specifically to Casey Muratori's well-known video titled `"Clean Code", Horrible Performance`. Ryan asks why Casey placed the phrase "clean code" in quotation marks and what he meant by that framing. Casey explains that terms like "clean code" or "object-oriented programming" are inherently slippery because they mean vastly different things depending on who you ask; it is virtually impossible to find two programmers who will agree on what is truly clean. The quotation marks were deliberate because he was targeting the specific dogmas laid out in Robert C. Martin's book *Clean Code*, rather than the abstract concept of clean, readable software.

The core ideology promoted in the book rests on specific rules: functions should be absurdly tiny—often four to five lines long—and code should interact almost entirely with abstract base classes through dynamic dispatch, deliberately remaining oblivious to concrete types. Casey points out that when applying this philosophy to compiled languages like C++, it becomes an absolute recipe for disaster. While a four-line function is completely harmless if the compiler can see it and inline it, forcing tiny functions behind virtual function calls blinds the compiler. The compiler cannot deduce concrete types at compile time or across module boundaries (absent aggressive link-time code generation), which prevents it from merging the code paths together.

```mermaid flowchart TD accTitle: Compiler Optimization vs Virtual Dispatch accDescr: Diagram illustrating how visible types enable compiler optimizations while virtual dispatch blocks them.

subgraph Direct["Concrete Types (Compile-Time Visible)"] A["Caller Function"] --> B["Known Function Body"] B --> C["Optimization Engine"] C --> D["Inlining & Merging"] C --> E["Loop Unrolling"] C --> F["SIMD / Vectorization"] end

subgraph Dynamic["Virtual Dispatch ('Clean Code' Rule)"] G["Caller Function"] --> H["Dynamic Dispatch / Vtable"] H --> I["Unknown Target Type"] I --> J["Compiler Blocked"] J --> K["No Inlining"] J --> L["Scalar Execution Only"] end ```

Casey clarifies a widespread misconception that arose from his video: the real performance catastrophe is not merely the CPU cycle cost of the virtual function call itself, which can actually be relatively cheap if branch prediction succeeds. The true disaster is the severe downstream optimization penalty. When a compiler cannot see through a virtual boundary, it cannot inline, cannot eliminate redundant overhead, cannot unroll loops, and cannot widen operations to utilize SIMD (vectorization). Casey stresses that he is not advocating against maintainability, but rather rejecting arbitrary and damaging dogma. Writing functions that are 30 to 50 lines long is perfectly maintainable, and keeping concrete types known at compile time does not make code difficult to read.

- **Book guidelines criticized**: Strict mandates that functions should be 4–5 lines long and operate strictly on dynamic/opaque base classes without knowing concrete types. - **Root cause of slowness**: The inability of the compiler to inline code and see the full pipeline, which completely blocks dead code elimination, loop unrolling, and auto-vectorization (SIMD). - **Virtual call cost vs. optimization loss**: The vtable branch itself carries a small to moderate overhead depending on branch prediction, but the missed compiler optimization optimizations cost orders of magnitude more.

---

[05:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=300s) Balancing Trade-offs, Software Literature, and the AI Coding Era

Ryan recalls how, early in his college years, people routinely advised him to read *Clean Code*, and asks whether Casey would explicitly recommend software engineers steer clear of it. Casey responds that the book is more of a mixed bag; he agrees with standard baseline advice like giving variables clear, intuitive names. His primary frustration is that prominent software engineering literature routinely presents rules of thumb while totally ignoring the severe performance costs they incur. He observes a pervasive cultural tendency to pretend performance does not exist, frequently hiding behind misapplied adages like "premature optimization is the root of all evil" to justify leaving performance entirely out of the curriculum.

Casey notes that this evasive attitude is everywhere in foundational engineering literature—pointing out that Martin Fowler's influential book *Refactoring* essentially begins by brushing off performance concerns, assuming they will usually just sort themselves out. Casey rejects this worldview outright. Software development is fundamentally about trade-offs: making an informed decision where an engineer acknowledges, "This may be a serious performance problem for us, but I think that's okay because it won't harm the product," is genuine engineering. Blindly pretending that performance can simply be deferred until the very end is an entirely different, flawed methodology.

Casey argues that understanding these trade-offs has become even more critical in the era of generative AI. While he does not personally work with AI tooling, developers are now in the position of prompting and directing AI coding agents. If an engineer has no awareness of how code structure impacts execution speed, they cannot instruct models to avoid slow, bloated architectural patterns. When Ryan asks what lightweight, high-value performance principles developers should keep in mind, Casey states that the single most vital component is simply basic awareness—understanding the underlying machinery before making design decisions.

- **Industry literary blind spots**: Influential texts such as *Clean Code* and *Refactoring* often dismiss performance as a non-issue that can be solved later, blinding engineers to systemic architectural degradation. - **The true definition of engineering**: Consciously weighing trade-offs and accepting known performance hits when justified by business needs, rather than ignoring performance outright. - **Relevance in the AI era**: Directing AI models to write and refactor code requires a clear understanding of low-level performance implications, otherwise bad idioms will be generated at scale.

[09:01](https://www.youtube.com/watch?v=czr1L3JocOI&t=541s) Hardware Awareness and Architectural Decisions

Understanding the performance characteristics of the underlying hardware—including what a network looks like if one is involved—comes down to basic awareness more than anything else. As Casey Muratori explains, "a little bit of awareness can go a very long way." For example, simply grasping the fundamental difference between network latency and network throughput allows a developer to make upfront decisions to structure code so that operations are batched properly. Without that foundational concept, a team can get very far into a project only to realize that every part of their design operates serially, cannot be accelerated over a network at all, and is never going to run reasonably.

Because of this, the lowest-hanging fruit for any programmer is simply getting some basic education in performance: learning how a machine actually works, what makes it fast or slow, and what it struggles with versus what it handles easily. Keeping that mental model in the back of your head makes you very unlikely to make the kinds of architectural decisions that will be hard to undo later.

```mermaid flowchart TD accTitle: Impact of Hardware Awareness on Architecture accDescr: Compares how understanding versus ignoring hardware realities like network latency versus throughput affects software design and rework. subgraph Aware["With Performance Awareness"] A1["Understand latency vs. throughput"] --> A2["Structure code to batch operations"] A2 --> A3["Clear path to optimize later"] end subgraph Unaware["Without Performance Awareness"] U1["Ignore network characteristics"] --> U2["Design purely serial operations"] U2 --> U3["Cannot accelerate over network"] U3 --> U4["Forced to scrap and rewrite"] end ```

[10:21](https://www.youtube.com/watch?v=czr1L3JocOI&t=621s) The Permanent Value of Performance Training

Acquiring this foundational knowledge is by far the "highest-impact, lowest-cost thing you can do" because you only have to do the training once. Once you understand how to think about performance, that intuition stays with you forever. It acts as a constant internal alarm bell whenever you are designing a system, prompting you to pause and think, "I don't see the path towards this running well," which serves as your cue to stop and rethink how decisions are being made.

Importantly, having this intuition does not mean you have to optimize everything immediately. As long as you can clearly see the path for how the system will eventually be optimized, you can safely delay most actual optimization work. By making the right upfront architectural tradeoffs with that path in mind, you avoid painting yourself into a corner where your only remaining option is to scrap the entire codebase and rewrite it from scratch.

## Notable quotes > [05:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=300s) premature optimization is the root of all evil — Casey Muratori

> [05:00](https://www.youtube.com/watch?v=czr1L3JocOI&t=300s) This may be a serious performance problem for us, but I think that's okay because it won't harm the product, — Casey Muratori

> [09:01](https://www.youtube.com/watch?v=czr1L3JocOI&t=541s) a little bit of awareness can go a very long way. — Casey Muratori

> [10:21](https://www.youtube.com/watch?v=czr1L3JocOI&t=621s) highest-impact, lowest-cost thing you can do — Casey Muratori

> [10:21](https://www.youtube.com/watch?v=czr1L3JocOI&t=621s) I don't see the path towards this running well, — Casey Muratori

## Mentioned Ryan Peterman, Casey Muratori, "Clean Code", Horrible Performance, Robert C. Martin, Clean Code, C++, SIMD, Martin Fowler, Refactoring

## Video description Casey Muratori is a video game developer and programming creator also known for his talks about the history of software and computing. We talked about surprising parts he found while digging through computer history, where bad code comes from, and his career story.

Watch the full conversation: https://www.youtube.com/watch?v=jHLbL1Eg4gM

[Source](https://www.youtube.com/watch?v=czr1L3JocOI)

中文简报

Muratori批Clean Code教条：虚函数调用屏蔽编译器优化教条式的Clean Code规则破坏了软件性能，因为将具体类型隐藏在虚分派之后会阻碍编译器进行内联和自动向量化。 Casey Muratori解释了教条式的“Clean Code”原则——特别是隐藏在动态虚分派后的小型函数——为何会严重破坏编译代码的性能，因为它们阻碍了编译器的内联、循环展开以及SIMD向量化。他批评了《Clean Code》和《重构》等颇具影响力的文献，指责其借口“避免过早优化”而助长了一种将性能视为事后考虑的文化。Muratori认为，无论是工程师还是指导AI编程智能体的开发者，都不应盲目套用刻板的可读性规则或任由架构随意发展，而是需要具备基本的硬件意识，以便在不让代码库陷入不可挽回绝境的前提下，做出自觉的架构权衡。 Casey Muratori解释称，“Clean Code”教条的主要性能代价并非虚表分派本身，而是虚边界阻碍了编译器进行内联、展开循环以及应用SIMD向量化。 (0:00) 包括《Clean Code》和《重构》在内的基础软件文献，常常借口避免过早优化而忽视性能权衡，从而导致系统性的架构恶化。 (5:00) 生成式AI的兴起让性能意识变得至关重要，因为开发者必须理解底层机制，才能妥善引导AI编程智能体避开臃肿且低效的架构模式。 (5:00) 获取基础硬件和性能直觉只需极少的训练，便能使开发者终身具备安全推迟具体优化的能力，而不至于在架构设计上陷入死胡同。 (10:21)

Reading summary

Software engineer Casey Muratori argues that dogmatic clean code paradigms—particularly extreme function decomposition and excessive dynamic dispatch—severely degrade performance by disabling critical compiler optimizations, urging developers to replace rigid rules with basic hardware awareness. Compiler Penalties of Dogmatic Dynamic Dispatch (0:00) Muratori targets specific tenets advanced in Robert C. Martin's book Clean Code, particularly the insistence that functions should be restricted to four or five lines and interface almost exclusively through abstract base classes. In compiled languages such as C++, forcing execution through virtual function calls prevents the compiler from discerning concrete types at compile time. This architectural boundary blinds the compiler across module borders, disallowing the merging of code paths even if individual short functions would otherwise be trivial to inline. While developers often assume the primary penalty of dynamic dispatch is the CPU overhead of vtable lookups and branch prediction, Muratori explains that the downstream compiler loss is far more damaging. When an interface obscures the underlying types, the compiler cannot perform inlining, dead code elimination, loop unrolling, or auto-vectorization using SIMD instructions. Writing readable, maintainable software does not mandate four-line routines; keeping concrete types visible and allowing functions to run 30 to 50 lines preserves compiler optimization pipelines without harming clarity. Blind Spots in Engineering Literature and AI Tooling (5:00) Foundational engineering literature frequently treats performance as a trivial concern that automatically resolves itself. Muratori notes that books like Clean Code and Martin Fowler's Refactoring tend to dismiss efficiency considerations, often leaning on misapplied adages like 'premature optimization is the root of all evil.' Muratori counters that genuine engineering relies on conscious trade-offs: deliberately accepting a known performance cost to achieve a product objective constitutes engineering, whereas pretending performance can be indefinitely deferred is an architectural failure. This lack of architectural awareness poses compounding risks in the era of generative AI. Although Muratori does not use AI coding tools directly, he highlights that engineers are increasingly responsible for prompting and steering automated agents. Developers who lack a foundational grasp of execution speed and code structure cannot direct AI systems to avoid inefficient, bloated patterns, leading to the rapid scaling of anti-patterns. Hardware Mental Models in System Design (9:01) Effective system architecture depends on lightweight mental models of the underlying machinery rather than exhaustive micro-optimization. Muratori emphasizes that simple conceptual distinctions, such as understanding the difference between network latency and throughput, dictate whether a system succeeds or fails. A developer with this foundational context will design systems to batch requests early on, whereas an unaware team may build deeply nested serial dependencies that can never be adequately accelerated across a network. Securing Long-Term Optimization Paths (10:21) Performance education delivers high architectural returns because foundational principles only need to be learned once to provide permanent intuition. This intuition functions as an internal diagnostic tool during design, warning an engineer when a proposed structure lacks a realistic path to running efficiently. Muratori clarifies that maintaining this awareness does not require immediate, aggressive optimization across an entire codebase; rather, it ensures that initial architectural trade-offs do not paint the team into a corner that ultimately requires scraping and rewriting the software. Muratori concludes that high-performance programming does not require optimizing every routine in advance, but rather maintaining a clear mechanical model of the machine so that designs remain open to downstream optimization instead of being blocked by structural dogma.

Source quotes

[5:00] Casey Muratori: premature optimization is the root of all evil [5:00] Casey Muratori: This may be a serious performance problem for us, but I think that's okay because it won't harm the product, [9:01] Casey Muratori: a little bit of awareness can go a very long way. [10:21] Casey Muratori: highest-impact, lowest-cost thing you can do [10:21] Casey Muratori: I don't see the path towards this running well,

Original transcript

[0:00] Earlier we talked about the the [0:01] trade-off between, I guess, performance [0:04] code and maintainable code. And I saw [0:08] you had this one video said, you know, [0:10] in quotes, clean code horrible [0:13] performance. Now, [0:15] I feel like this is on the same topic. [0:17] What's your your take there on, you [0:20] know, because you also put clean code in [0:23] quotes. What does that mean? [0:24] >> So, it's a it's a pretty fairly subtle [0:26] topic, right? Uh and that's why the the [0:28] quotes are there because um the first [0:30] thing that I you have to point out is [0:32] that clean code is clean code, [0:35] object-oriented programming, a lot of [0:37] these phrases, they mean different [0:39] things to different people. And so, if [0:41] you're going to say that you're, you [0:42] know, this code is clean, it's pretty [0:45] hard to find two programmers who will [0:48] agree on exactly whether it is or not, [0:51] right? Like like they all have like [0:52] different ideas about what is clean and [0:54] what is not, right? [0:56] So, the reason I put that in quotes is I [0:58] was talking about a very specific thing, [0:59] which is like literally like the book [1:01] Clean Code, like the thing where there's [1:03] like here are the things that we would [1:04] recommend that you do, right? [1:06] So, in that particular case, what I was [1:08] talking about is there's a certain set [1:10] of ideas that is advocated in Clean Code [1:14] as like these are the things you should [1:15] do, and they are like you should have [1:19] everything should be kind of um [1:22] I guess I would say [1:23] dynamic dispatch, or at least you [1:25] shouldn't code shouldn't know the types [1:27] it's operating on, right? Saying it's [1:29] dynamic dispatch is maybe it depends on [1:31] the language whether that's going to be [1:32] true or not, but when I write code, I [1:34] don't know what types I have. It's just [1:36] I don't know, like some base classes is [1:38] what I'm operating on, and they could be [1:39] anything, right? That's thing one. Thing [1:41] two is functions should be very small. [1:43] Uh in fact, the the numbers are kind of [1:46] weird. They're like four lines or five [1:48] line Like when you go look at the actual [1:49] things that are claimed in some of the [1:51] this literature, it's it's really [1:52] strange. You're just like, "Gosh, that's [1:54] very small, right?" [1:56] Um [1:58] and I go through some of those things [1:59] and I say, "Look, if we were to actually [2:01] follow these, [2:03] we get into a really bad state because a [2:05] lot of the languages that people are [2:07] going to be using to implement this [2:08] stuff, like C++ for example, um which [2:11] even would be a fairly good case in a [2:13] lot of cases at least it's a compiled [2:14] language and so on. [2:17] In a a lot of cases, these things are [2:19] kind of a recipe for disaster. [2:21] If you're [2:22] if you're handing out types where you [2:24] can't know the type at compile time or [2:26] you can't know the type uh or it's or [2:28] it's, you know, going to be in a [2:29] different module, so it, you know, [2:30] unless you have like a really aggressive [2:32] link time code generation, it's not [2:33] going to be likely that you could figure [2:34] this out. And you're saying all the [2:35] functions should be very small and of [2:37] course they're going to be virtual [2:38] because they're on these sort of types [2:39] that you don't know what they are. [2:41] This creates a really uh toxic [2:44] combination for the compiler. [2:46] Normally, [2:48] you can have I mean, you can have small [2:51] functions if you want them only four [2:52] lines long. If the compiler can know [2:54] that it can just inline that, right? If [2:56] it can see clearly what you're doing and [2:58] it can just merge those things in, we [2:59] don't have a problem. If they're behind [3:01] a virtual function, so it doesn't know, [3:03] like it can't guarantee that it is that [3:06] type, [3:07] um it can't do that. [3:09] And so, when you talk about all this [3:11] stuff, what you're what you're giving [3:12] up, people I think also because the [3:14] video I mean, the video was a very short [3:16] video, it's part of like a series. [3:18] I think people sometimes get the wrong [3:19] idea that I think that virtual function [3:21] calls cost a lot. They do cost [3:23] something, but, you know, depending on [3:25] how you want to look at it, they [3:25] actually don't cost that much [3:27] uh because, you know, it depends on [3:29] whether it's predicted correctly or not, [3:31] but in general, like the cost of virtual [3:33] function is less than you would think a [3:34] lot of times. [3:36] The actual reason that it slows things [3:37] down is because the compiler cannot [3:39] merge the code together, right? It can't [3:41] inline stuff and remove and reduce the [3:43] waste. Like, that's the actual problem. [3:46] So, if you just want to call a virtual [3:47] function, yeah, it it if it was a [3:49] really, really uh hardcore optimization [3:52] scenario, then you don't want anything [3:54] probably calling a virtual function in [3:56] general cuz there is some cost to that. [3:58] Just calling a function has cost. [4:00] But that wasn't the really bad part of [4:02] it, right? So it's that plus there's an [4:05] additional thing which is that it can't [4:07] unroll and go wide on things. If the [4:09] compiler can see everything you're [4:10] doing, it can use SIMD, it can like [4:13] widen loops to operate on multiple [4:14] things at once, it can unroll those [4:16] loops. There's all these things it can [4:17] do. If it's got these virtual functions, [4:18] it's just like [4:20] that's it. I don't know I I can't make [4:22] decisions about that. I have no idea [4:23] what this thing on the other end is [4:24] doing, right? [4:25] So uh that was kind of my point on that [4:28] and uh again, I it's not meant to be uh [4:31] assailing the idea that your code should [4:33] be easy to read or easy to maintain. [4:35] It's just more like these guidelines [4:37] seem really bad and also I don't think [4:39] we need them for code to be [4:41] maintainable. I I don't have trouble [4:43] maintaining functions that are 30 lines [4:44] long or 50 lines long. I don't find that [4:46] five is a magic number or something or [4:48] that it has to be really short. Uh and [4:49] also I find that it's usually pretty [4:51] easy to write code where I know what the [4:52] types are. Um that those can be [4:54] determined at compile time. Like I don't [4:56] think that results in code that's [4:58] particularly hard to read. [5:00] >> When I was in college, very in very [5:03] early, I remember people recommend that [5:05] book. So oh, you should read Clean Code. [5:08] So my understanding that you wouldn't [5:09] recommend people who are software [5:11] engineers to read that. [5:14] >> I guess the way I would categorize it is [5:15] a mixed bag. So I would I wouldn't [5:17] actually say that I disagree with all of [5:19] all of the things in the book, though. I [5:21] mean, some of the things are things that [5:22] I definitely do myself. Like giving um [5:26] variables like easy to understand names [5:29] uh is something that I think would be [5:31] and then that's in that book. Uh [5:33] is good advice, right? And so kind of [5:36] more I wouldn't I wouldn't necessarily [5:38] say do or don't read a book. What I [5:40] would say is like I think there's some [5:41] things in this book that don't that [5:43] aren't addressed properly. Like I don't [5:46] think you want to tell people these [5:47] rules of thumb and not tell them about [5:49] these other problems that was exactly [5:51] what I was uh pointing out there. [5:53] And so, usually it's more that. It's [5:55] like [5:58] I find that oftentimes there is this [6:01] tendency [6:03] um I guess I'll say to pretend [6:06] that [6:07] we don't have to talk about performance [6:10] and we can just say like, "In fact, [6:11] premature optimization is the root of [6:12] all evil." Bringing it back to there. I [6:15] feel like there's this uh temptation and [6:18] very prevalent practice of sort of [6:20] taking that idea to mean we don't have [6:23] to talk about performance when we're [6:25] teaching people things at all. [6:26] Or like when you write the book Clean [6:28] Code, you don't have to talk about [6:29] performance at all. You can just include [6:30] a thing that's basically like, "Hey, um [6:34] you know, [6:35] there's performance issues, but most of [6:37] the time it's not a problem." or [6:38] something like that, which is, you know, [6:39] or if you look at uh [6:41] Refactoring, the book Refactoring, very [6:43] popular. It literally says exactly that [6:45] in like the opening thing. It's like, [6:46] "You know, there there might be [6:47] performance concerns, but you know, [6:49] they're usually okay." or something, [6:50] right? And it's like, that is not true. [6:53] I just think that's fundamentally not [6:54] true. I think these books should include [6:57] detailed discussions of the actual [6:59] performance problems that you are very [7:01] likely to hit if you take some of their [7:03] advice um because it's not that it means [7:06] you can't do those things, [7:09] but [7:10] I'll quote you back to you, it's about [7:12] trade-offs. [7:13] There is always a trade-off that you're [7:15] making. [7:16] And sometimes, if you understand the [7:18] trade-off, you will make it. You'll say, [7:21] "Mm, I know this is going to cost This [7:23] may be a serious performance problem for [7:25] us, but I think that's okay." [7:27] Like, I think it's not like our [7:28] performance won't suffer to the point [7:30] where it's a problem for the product. I [7:32] understand what that's is. [7:35] There's a huge difference between that [7:37] and just going like, "Uh we don't worry [7:39] about performance till the end." Right? [7:40] Like, there's it's completely different, [7:41] right? Those are two different [7:42] engineering approaches. [7:44] Uh and so what I try to do is encourage [7:47] people [7:48] to put that analysis back in. Understand [7:51] the performance tradeoffs you're making. [7:52] Understand how much it might cost in the [7:55] future to like make these fixes. [7:58] And I [7:59] I don't really do any AI stuff, but my [8:02] sort of feeling is [8:03] more so now than ever I feel like that's [8:05] got to be pretty important because [8:07] you're instructing these AIs to do what [8:09] they're going to do. [8:11] And I feel like it would be a bad idea [8:14] to not know about performance tradeoffs [8:17] because especially if an AI is going to [8:20] be doing your bidding and structuring [8:21] the code the way you want to structure [8:23] it or doing whatever. [8:24] It seems like a very straightforward [8:25] part of the process to include [8:27] performance stuff in those instructions, [8:29] right? Like that would be a natural [8:31] thing that we would want to understand [8:32] and do, right? So I feel like [8:35] really I've been just trying to get that [8:37] more into the conversation. [8:39] Uh and I feel like it's it's as relevant [8:41] now as it ever was and arguably maybe [8:43] more so. I don't know, but I could be [8:44] wrong about that. [8:46] >> What are some things that are in your [8:48] mind that are those high-value [8:51] performance things to consider that [8:53] don't cost a whole lot to think about? [8:55] >> So to me awareness is the number one [8:58] thing, right? Understanding roughly the [9:01] performance characteristics of the [9:03] hardware that you're working on, which [9:05] includes things like, you know, if [9:06] there's a network, like what does that [9:07] look like and so on. [9:10] Um it's really about awareness more than [9:12] anything else because a little bit of [9:15] awareness can go a very long way. [9:19] If you understand the basic concept that [9:22] like, you know, a that network latency [9:25] versus network throughput are different [9:27] things, [9:28] you can make upfront decisions about [9:29] structuring code such that you batch [9:31] things properly, uh and so on and so [9:34] forth. If you don't understand those [9:35] things, you could get very far down a [9:37] project only to realize that everything [9:40] you designed and all the way it works is [9:42] all very serial and really just cannot [9:44] be accelerated over a network at all. [9:45] Like it's never going to run uh [9:47] reasonably or something like this, [9:48] right? [9:50] Uh and so I think the the lowest-hanging [9:53] fruit is just to get some education in [9:55] performance. Like get some education in [9:59] how to think about the way a machine [10:02] works and what makes it faster or slow, [10:04] what it struggles with and what it [10:05] doesn't. [10:06] And just to keep that in the back of [10:07] your head. Because at the end of the [10:10] day, if you have that knowledge, I think [10:12] you're very unlikely to make the kinds [10:14] of architectural decisions that will be [10:17] hard to undo later, right? [10:20] Um [10:21] and so that's really that's really the [10:22] majority of it, I think. And that is by [10:25] far the highest-impact, lowest-cost [10:28] thing you can do is just do that [10:29] training once. Cuz once you have it, [10:31] it's with you forever. Once you [10:32] understand how to think about [10:34] performance, [10:35] it can always be there and at any time, [10:39] you can sort of have that alarm bell of [10:40] like, "Hmm, this I don't see, you know, [10:44] you're always kind of looking like I [10:45] don't see the path towards this running [10:47] well." [10:48] And then so that's that your key to stop [10:50] and go like, "Uh maybe we need to [10:51] rethink like how we were making some of [10:53] these decisions." [10:54] As long as you can see that path, you're [10:57] pretty you can you can delay most like [11:00] optimization work. As long as you can [11:02] see the path, like here is how we will [11:04] optimize this, you're in pretty good [11:06] shape because um [11:09] if you're making those tradeoffs [11:10] correctly, you're not going to paint [11:12] yourself into a corner where there's [11:14] nothing that you can do other than scrap [11:16] and rewrite.