High Signal Podcasts Evidence ledger
Method
Browse
← Back to evidence

Evidence receipt / uncertainty

Published · transcript-backed

Dwarkesh Patel: uncertainty

12 Jul 2023 Dwarkesh Podcast Andy Matuschak — The reason most learning tools fail

“Presumably you didn't have some sort of practice but since you were encountering these things day to day, that natural frequency and way in which problems came up, did you have a worse understanding of those problems then compared to now, knowing what you do and having the practices you do, you're able to comprehend now? I don't know if that question made sense.”

— Dwarkesh Patel

Source trail

Everything needed to verify it.

Speaker
Dwarkesh Patel
Attribution
Verified speaker
Claim type
uncertainty
Recorded
12 Jul 2023
Publisher
Dwarkesh Podcast

Transcript context

…Yeah. Okay. Let me ask you this. At Apple, you were in charge of a bunch of important flagship features on iOS and I'm guessing other things. Presumably you didn't have some sort of practice but since you were encountering these things day to day, that natural frequency and way in which problems came up, did you have a worse understanding of those problems then compared to now, knowing what you do and having the practices you do, you're able to comprehend now? I don't know if that question made sense. No, that's a great question. Here's a fun thing. I was much better at what I was doing then than I am at what I'm doing now. That's pretty funny. It was just totally different. Let's talk about this a little bit. This feels very, very juicy for me. Most of what I was doing was engineering. Some of it was very difficult engineering, but mostly engineering, and mostly on things that were fairly well understood. I wasn't trying to decide what should be done, sometimes I was from a technical perspective, but certainly rarely from a product perspective. It was rarely a relevant question for me. I was a somewhat design minded engineer and I did a bunch of engineering and design-ish things on tasks which were set out for me. By the time I joined Apple I had been programming for a really long time, 13 years maybe, and programming in Apple's ecosystem for probably two to three thirds of that time. So everything was just really familiar. It was mostly flow all the time, every day. I was just in it. I knew the stuff that I needed to know. I was very well practiced. And the space didn't change that much. Most engineers at Apple most of the time are not pushing the frontier of what is known, like trying to discover. They're doing very difficult technical work, mostly applying things that they already know and understand quite well to problems which are usually not always pretty well understood. Memory was essential to me doing that job well, but I had already built most of it by the time I got there. I'd already built just tons of stuff for Apple's platform. I had to learn a lot of stuff. I learned a ton of stuff about the internals of those systems. But because I already had such a rich understanding, both of Apple's platforms and of computer science and engineering in general, I had this really rich network for stuff to slot into. Learning stuff is easier when you have other stuff to connect to. It's a nice principle. Metacognitive load on me was lighter because others were figuring out what we should be doing. Just like by contrast, now I'm doing research, I'm trying to discover things that are not known. I'm trying to make things that didn't exist. The hard questions that I answer are mostly, what should be done or what should I do? And that question is not just a technical one of how I should implement this feature that needs to get built, but what intervention on a reader should be taken? That requires synthesizing lots of different unfamiliar literature.…

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

Search evidence