Speaker unverified: belief

Transcript context

…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. I think that’s a skill set that is extremely important for people to learn. I see that in myself. That’s a constant struggle for myself when facing a code base, for example. But this applies generally in life, where somebody did a lot of work to do a thing, you should invest a huge amount of time and get really good at figuring out what they did, why they did it. Do a lot of print off debugging to understand what they did. It’s a much more efficient way to understand a problem deeply than to start from scratch. Even though there’s a constant temptation to start from scratch, because starting from scratch is fun. You do get the puzzle solved and all that kind of stuff. It’s just not going to be the right thing to do. Usually pain is the right thing to do, and it is for most people painful to understand other people’s code bases.…

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