Why performant code matters (but gets widely ignored), with Casey Muratori

**Gergely Orosz** (0:00)
Why do most devs not care about writing performance software? And should we?
Today's guest, Casey Muratori, spent the last decade arguing that we should. He also says that most software out there it runs 10 to 100 times slower than it needs to. Today we discuss why the focus on performance took a backseat across the industry and why Casey thinks the tide is finally turning, why you'll want to learn reading assembly if you're serious about high performance code and why it's less scary than it sounds, the saying premature optimization is the root of all evil, why Casey says that the majority people use it to avoid thinking about performance when they really should and many more. If you want to get better at writing faster software and become a better engineer while doing so, then this episode is for you. If you're one of the people who hit a like on this post by Ryan asking for this episode to be more about programming than about AI, this episode is also for you. This episode is presented by Antisys. If you work with agents, your job is no longer just writing code, it's also specifying and testing it.
Antisys is the most effective method of verifying agent code today. This episode is brought to you by Sentry. You probably already know what Sentry is because you're a developer. If not, just ask the dev and they'll tell you. I use Sentry to monitor the backend of the Pragmatic Engineer for any and all events and errors. Of course, Sentry doesn't only do errors, they also have logs, replays, spans, profiles, metrics and more, because they're all connected to the same trace. One new capability Sentry has I'm really liking is its ability to fix errors. Let me show you. Here's a list of errors on my admin backend. There's a recent error on Auth that I want to check out. Let's have Seer run an autofix for us. Seer is Sentry's AI debugging tool. First, it generates a root cause analysis.
It's finding some problem with HTTP versus HTTPS URLs. Cool. Now that we know what's going wrong, Seer can create a plan on how to go about fixing it. I could go and edit this plan, but I'm happy with it, so let's create the actual codefix.
Here's a codefix that Seer generated. Assuming it looks good, and in my case it does, let's drop the pull request. And boom, the PR is created, ready to merge. What I love about Autofix is how Sentry went from showing a list of errors inside my application to offering me a fast way to fix it and close the loop while I stay in charge of this bug fix the whole time. Debugging got a whole lot faster and a whole lot easier. Check out Sentry at sentry.io/pragmatic and start detecting errors, diagnosing their root causes and fixing issues and regressions today.
Alright, Casey, welcome to the podcast. It's so nice to have you here.

**Casey Muratori** (2:19)
Thank you so much. It's great to be here. Thank you for the invitation.

**Gergely Orosz** (2:22)
Now, I want to go back when we start to the beginning. How did you get into tech, programming, computers?

**Casey Muratori** (2:28)
Well, I guess computers, it's like very, very early on.
My dad was a programmer at Digital Equipment Corporation, which is a company that people will know if they studied computer history, but would not know if you just looked at the landscape today. They're completely gone, right? They got absorbed partly by Intel, partly by Compaq, I think.
They kind of got broken up. At that time, it was kind of a really big computer manufacturer. Computers like the PDP-11, that's a Digital Equipment Corporation computer. The VAX, things that you may have heard of in computer history.

**Gergely Orosz** (3:02)
These were these massive mainframes?

**Casey Muratori** (3:05)
Yeah. Mini computers as well, so smaller also sometimes than mainframes, like the next step down. So in general, that era, my dad was a programmer there. He would later end up at Intel because, like I said, parts got acquired. He never actually left his job. He just ended up at Intel through kind of digital's eventual demise. But as a result, we always had computers at home, even though at that time, that might have been a little bit odd.
I learned a program when I was seven, which would have been in 1982 or something like that. And so at that time, maybe you might have an Apple or Commodore kind of computer at home, like some kind of early computer. I don't remember the exact dates of those computers, but most people didn't. And it was only until a little bit later that you would. And you probably wouldn't have had a programmer in your household to teach you, more importantly, right?