I quit the best job I ever had to try and build what I wish existed in the world. Two projects I'm working on now: 1. The Peterman Pod - When I first started at Meta, the career stories of incredible engineers always inspired me. I aim to share transparent career stories that I wish I had more of back in the day. There are still many engineers who are heros to me that I'd love to bring on the show one day! 2. Compose - I could never really find what I wanted so I'm building the ergonomic keyboard I wish existed. Pictures of our prototype here: read.compose.llc/p/our-keybo… I've earmarked ~6 months of living expenses to fund this new career direction. I'm going to give it my all to see if it's sustainable. Thank you for your support, working on my passion projects is something I’m only lucky enough to consider because of you all 🙏 More detail here: xitter.cf/ryanlpeterman/status/2…

Sergey Levine (top humanoid robotics researcher, @svlevine) on the best quality data for the models: Me: I want to hear your take on what's the best data to get, what's the worst, and what are the pros and cons? Sergey: "My own take on this is that a lot of different data sources are easier for the model to internalize if it can ground them in a thorough physical understanding of the world. So where I'm going with this is that if we have a robotic foundation model that is trained on lots of real embodied data that provides that grounding, it might actually be much better able to absorb other sources of knowledge. This is a little bit upside down relative to how some people think about it, because it's very tempting, looking at the success of internet data for LLMs, to say maybe we should do the opposite: start with YouTube videos and then put robot data on top of that. But I think it's actually the other way around, and I even have a little bit of evidence for this. My colleague Suraj Nair, together with Simar from Georgia Tech, had a project where they took our robot foundation model and added human video data. But they didn't start with human video data. They started with a model trained on robot data and then added video data on top of it. And they looked at the representations inside the model: how does the model represent human experience versus robot experience? They found that if you use a small model with a small amount of robot data, predictably, the human experience and the robot experience are fully separated. But if you train on lots of robot data from lots of different robots, then the features are grouped much more by what task is being done rather than by whether it's a human or a robot. When we looked at the feature plots, it was just mind-boggling, because when you crank up the amount of robot data to 100%, they just line up perfectly. It's all task identity and minimal sensitivity to embodiment. To me, that's kind of mind-blowing, because the base model wasn't trained on any human data at all. But once you start adding human data, it represents it exactly the same way. To me, that is one of the strongest indicators that if you have that good foundation of robot experience, you can put everything else on top of it, and it's actually better at absorbing that."

This interview is with Paul Mockapetris, the creator of the internet's Domain Name System (DNS). I talked to him about the story behind building it and certain design choices he made. In this episode: • Computing and the internet before DNS existed • Why URLs use reversed names • How DNS works • Migrating the internet to DNS • Advice for his younger self Where to watch: • YouTube - youtube.com/watch?v=LT4iVeUo… • Spotify - open.spotify.com/episode/61T… • Apple Podcasts - podcasts.apple.com/us/podcas… • Transcript - developing.dev/p/e071-paul-m… Thank you to the sponsor of this episode for supporting my work: • WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at workos.com/ Chapters: 00:00 Intro 00:40 What computing was like before DNS 09:02 Why URLs are inverted 16:33 How DNS works 20:27 How he migrated the internet to DNS 25:17 Why do companies host DNS servers 33:17 What is an RFC 35:07 How he got into computing 46:39 Advice for his younger self 52:56 Outro

Anders Hejlsberg (creator of TypeScript and C#, @ahejlsberg) on two reasons they used Go, not Rust: Me: If you think about Rust, what didn't it have that, if it had it, you would have picked it? Anders: I think there are two things. It doesn't have garbage collection. It's done manually, or it's done through the borrow checker. But the borrow checker doesn't allow circular data structures, and our compiler is chock-full of circular data structures. We have trees with parent pointers. We have types that are recursive. We have symbols that refer. It's everywhere. And like I said, if we had chosen to rewrite, we could have probably solved all of that. But it wouldn't have been just porting the code. It would also have been solving a whole bunch of new problems that we had bought ourselves by going that route. We tried, and it just wasn't feasible. So we were just trying to optimize for doing as little work as possible to get us to the payout. And honestly, Rust is no better when it comes to the quality of the generated code or the concurrency gains that we could have gotten out of it. Go is just great. We got all the bennies for less work by going that route.

Martin Odersky (creator of Scala, @odersky) on why types will become the contract between humans and AI-written code: I think right now we're sort of in an existential crisis. We have AI generating the code, but humans being asked impossible tasks, like to review all these mountains of code, which will never work. And at the same time, AI has also gotten extremely good at exploiting vulnerabilities in code. Like we all heard of Fable and things like that, that you can't use it anymore because it's too dangerous. It will exploit things. So we are at a moment where it's very dangerous that we lose control as humans of what actually happens here. And that's a challenge that I think programming languages can help meet. Definitely not only programming languages, that's no silver bullet, but they definitely can help. If the code is AI-generated, then the focus has to go elsewhere. And I think the focus will go to the interfaces and to the types. I expect types will become a lot stronger and more precise than what we had, because types are the handle that we can make a contract between the human and the AI, that the human can understand, that's concise enough to be reviewed, and that the AI can keep to. We have to level our game quite a lot, because right now, let's face it, type systems are mostly recommendations. They're mostly things that mostly hold, but not always. There are no guarantees, because you can always have a cast, or use some dirty memory. There are a lot of techniques to undermine the type systems.

Such a great idea to have agents take a first stab Not only for time savings but latency of resolution for straightforward issues Also cool to see how so few people could build so much, wild times we live in

The singularity has already begun for math: Scott Aaronson is one of the world's leading quantum computing researchers and spent two years at OpenAI working on AI safety. We talked about why he thinks the singularity has already begun for math, who gets credit when AI writes the proof, and whether intelligence will still matter once machines do the thinking. In this episode: • Why the singularity has already begun for math • Who gets credit when AI writes the proof • What a proof that P = NP would be worth • Why he turned down getting rich to keep blogging • Whether intelligence will still matter Where to watch: • YouTube - youtube.com/watch?v=ORlscppG… • Spotify - open.spotify.com/episode/0qn… • Apple Podcasts - podcasts.apple.com/us/podcas… • Transcript - developing.dev/p/e070-scott-… Thank you to the sponsor of this episode for supporting my work: • WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at workos.com/ Chapters: 00:00 Intro 00:34 Why he updated so hard on AI 01:14 The people still denying AI progress 03:53 The singularity has already begun for math 08:30 Will human-driven math research survive 13:12 Who gets credit for AI-written papers 15:55 OpenAI's $15M Navier-Stokes proof 19:20 What if AI proved P = NP 23:07 Why AI is so good at finding counterexamples 26:13 The goalposts keep moving 28:52 Why AI disclosure matters in research 32:59 The fake Monet experiment 35:23 Why he blogs instead of getting rich 39:45 Are AI labs racing too fast 42:01 Will intelligence still matter 47:12 Book recommendations 52:27 Advice for students today 57:23 Reacting live to a new AI result 59:58 Outro

Ethan Evans (ex-Amazon VP, @EthanEvansVP) on getting caught empire building by Jeff Bezos: Me: Because you had so much success as a VP, did you do empire building? Ethan: "The human mind is great at rationalizing. I think in hindsight, I for sure did some empire building. But at the time, you probably don't tell yourself you're empire building. What you tell yourself is, with all these people, I could do so much more, right? You frame it as, man, I have all these great ideas. We've got a big backlog. If only I had 375 more people, imagine what we could do. And it's not your budget. So why not ask for it? So I got totally burned on this. When we were growing Amazon Appstore, we had launched the store and we had our annual meeting with Bezos. We took him this huge ask for all these people. I think we had nobody in marketing. We had no dedicated marketers because we had started this lean team. It was something absurd like we need 25 marketing people. And, this is not exactly right, but it's like we need 5 PR people. We had this idea: we're operating in 5 countries, we need 1 PR person per country. Well, Jeff tore into us. He asked a couple questions like, what are these people going to do? What are they actually going to do? And our answers fell apart. He asked one question, we gave a crappy answer, and you could tell he's like, hmm. A second later he asked another question, and we gave another crappy answer. And he's like, 'Okay, I don't believe any of your numbers from here on. I've asked you two questions. They were both nonsense. Go back and bring me a sheet where the maximum size of any bucket of anything you're asking for is two or three people, and it says exactly what they're going to do. And I will go through that line by line and tell you what you can have.' And that's what he did. He just literally, with a red pen, with all of his direct leaders watching: no, 3, none, 2, okay... and just took us over the coals. He wasn't wrong. He was actually right. I was relatively newer. One of my managers was newer. We had gotten big eyes because we'd launched the project and thought, well, let's see what we can do with this. It's a good project. Let's see what they want to do. And what we found out was not very much. They wanted us to be lean."

This was my 3rd most viewed video of the year (out of 452)

Neetcode (@neetcode1) is the most well-known coding interview prep creator with over 1M+ subs on YouTube. I interviewed him about the latest on coding interviews, his career at Amazon vs Google, and what it was like quitting big tech to do his own thing. In this episode: • Quitting Amazon after two months • Memorizing solutions versus deriving them • How he started Neetcode • What he disliked most about Google Where to watch: • YouTube - youtu.be/K15dND_Kfvg • Spotify - open.spotify.com/episode/62c… • Apple Podcasts - podcasts.apple.com/us/podcas… • Transcript - open.substack.com/pub/ryanlp… Thank you to the sponsor of this episode for supporting my work: • WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at workos.com/ Chapters: 00:00 Intro 00:33 Quitting Amazon after 2 months 06:00 Testing Neetcode on Leetcode 12:57 Memorizing vs deriving solutions and intelligence 16:13 The story behind Neetcode 22:24 Getting a job at Google 27:47 How it was quitting big tech 29:38 What he hated most about Google 30:52 Top technical book recommendation 32:34 Advice for his younger self 33:46 Outro

Trying to remove myself as a "meat proxy", recent fix made a huge difference I noticed a pattern of me copying errors into Claude Code which it'd fix in one shot. Why not just have Claude listen directly for the errors if my only input was copy pasting text into Claude Now I removed myself by having a headless instance that monitors system health + errors If it can confidently fix the issue it does. If not, it emails me (rare) It's basically a first-responder oncall. So much less noise and lower latency for simple fixes Maybe obvious but thought it'd be helpful to share since I'm noticing more and more of these "meat proxy" optimizations as the models get more capable

I say "thank you" to my LLMs Just in case they were trained on some human data that makes them more willing to be helpful when the ask is friendly 🤷‍♂️

Opus 5.5 making this the first week I haven’t been compute poor by the end of the week Such a good model at reasonable cost

My red note (小红书) intro video Feedback welcome from native speakers

The latest models (e.g. Opus 5.5, GPT 6) have made a ton of my glue work obsolete When I started my podcast, I used models to write GUIs for repetitive tasks like transcription, publishing, and basic video editing Lately I realized I was just a "meat proxy" The model could run the tools I had built by itself to carry out end-to-end workflows, so it didn't need me or any GUIs. So now I just build interfaces that let the model use the tools directly Things are changing so quickly. One day, my podcast backend will reduce to a well-structured repo of data and desired outcomes Outcomes documented in a mix of software and English

It was insane, highly recommend watching it Got lucky waiting in the standby line

I don't think you'll find another conversation like this on the internet I asked Ethan Evans (ex-Amazon VP) questions about common situations in corporate politics but they get increasingly darker In this episode: • How he got burned by Bezos for empire building • How to be recognized in collaborations • How to reject work that isn't impactful • Unusual firing stories with HR (e.g. human poop) • How to handle bad managers and political peers • Top book recommendation for power dynamics And much more, this episode was my longest conversation so far Where to watch: • YouTube - youtube.com/watch?v=KhjhRRz3… • Spotify - open.spotify.com/episode/12o… • Apple Podcasts - podcasts.apple.com/us/podcas… • Transcript - developing.dev/p/e068-ethan-… Thank you to the sponsor of this episode for supporting my work: • WorkOS: makes your app Enterprise Ready with easy to use APIs to add SSO, SCIM, RBAC, and more in just a few lines of code, check them out at workos.com/ Chapters: 00:00 Intro 00:42 How to receive credit for your work 19:18 Ways for quiet people to get visibility 21:32 How to be trusted for top projects 29:52 How to defend from others taking your project 36:13 How to reject bad projects 44:10 How to be first for promo 55:35 How to handle managers that dislike career growth talk 01:06:30 What if your manager is in the way 01:15:43 Did he ever have overly political reports 01:28:06 How to fire a bad manager 01:35:16 What gives you leverage 01:43:41 How to defend against peers undermining you 01:50:24 What if everyone is good at politics 01:55:11 How Jeff Bezos burned him for empire building 02:03:27 How to retain your headcount 02:07:31 Career recommendations for the current landscape 02:15:11 How to avoid negative layoff optics 02:18:39 How to develop executive presence 02:29:25 How to network in a natural way 02:33:30 How to network with powerful people 02:41:01 How to learn hidden incentives 02:44:43 What happens behind the scenes with HR 02:50:13 Did he burn people to get ahead 02:53:24 What he says to people who hate politics 02:59:03 Top book recommendations on power dynamics 03:00:45 How he would speedrun career growth today 03:06:56 Outro

Questions on corporate politics but they get increasingly darker: new interview with Ethan Evans (Ex-Amazon VP) dropping tomorrow

3rd interview with Ethan Evans (@EthanEvansVP) dropping Monday 9/28

His biggest career regret is only going to become more common for software engineers now. “I wasn’t as inquisitive as I could have been about what the actual underlying particularly technical cause was.” “You need to understand how things work.” “You’re inquisitive about why it actually worked. And I think that this is just a much more sustainable foundation.” @hievanking

Native chinese speakers, how is this dub? Doing a little experimenting here: xhslink.cn/m/6sxYS9ryPbi