High Signal Podcasts Evidence ledger
Method
Browse
← Back to evidence

Evidence receipt / preference

Published · transcript-backed

Lex Fridman: preference

22 Mar 2025 Lex Fridman Podcast #461 – ThePrimeagen: Programming, AI, ADHD, Productivity, Addiction, and God

“As opposed to actually doing print off debugging on the space of languages, on the space of problems, because there’s a lot of wisdom and solved problems already in this code base.”

— Lex Fridman

Source trail

Everything needed to verify it.

Speaker
Lex Fridman
Attribution
Verified speaker
Claim type
preference
Recorded
22 Mar 2025
Publisher
Lex Fridman Podcast

Transcript context

…Well, I had the code so it’s like I can kind of blueprint what’s happening. I don’t understand the services or anything, but you can start guessing pretty quick as to what’s going wrong. Right. But then the print side of that helps you confirm your intuitions, test your intuitions and build up more and more information. And then you start to accumulate this bigger picture from that, what the edge cases are that break the system and not. I think that just that kind of situation is intimidating for a lot of engineers. They break down at that point. I think it really is a powerful thing to be able to come into a code base, that’s generally a skillset of very few of us start from scratch. And actually this is the fundamental problem of web development and in general where they’re like, I don’t know what’s going on. I’m going to write my own thing from scratch. As opposed to actually doing print off debugging on the space of languages, on the space of problems, because there’s a lot of wisdom and solved problems already in this code base. It’s a much more important skillset to understand, to learn from the mistakes and the wisdom of the past, of the ancestors that came before and build on them as opposed to throw it all out and start from scratch. This is something obviously you see a lot with a JavaScript framework that comes out and you won every single day. I have a very great story about that, that this is what I think has shaped me the most about my perspective of other devs. There’s this dev and he always just wrote things in just what I thought was such a bizarre and weird way, and this had to do with Falcor. So our data fetching library for Netflix, This would run on mobile. So I had to write in Objective-C. It had to run on television and it had to also run on web. So it ran on everything. And me and one other person were responsible for this thing working. And the request side where we’d have to de-dupe the information that we already have, the requests that were pending and the new data. So I had to figure all that out based on what someone’s requesting, and then just only optimally request the stuff that we don’t have. He wrote in such a goofy way and I’m thinking, man, this guy is just… What a goofball. So I delete it all and I start writing and I’m like, look at how much nicer this is. It’s looking so good. I’m like, Ooh, there’s that one edge case. Okay, I can see why he wrote it this one way. That’s not a big deal though. The rest of my code’s really great. By the end of it, I’m like, I literally almost line for line just reproduced what he already wrote. It’s slightly different towards my style, but I just wrote the same code. I’m like, I’m an idiot. I am the idiot in this situation because it was already a solved problem. I just didn’t take the time to learn what he did. Instead, I relearned what he did by rewriting the entire thing.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.

Search evidence