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: x.lingyaoai.com/ryanlpeterman/status/2…

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 - piped.video/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

The m5 studio upgrade has arrived!! Had Codex chop up the footage into an ASMR unboxing video in one shot

Philip Su grew quickly to a Distinguished Engineer at Facebook and OpenAI. We talked about the psychology behind peaking in a tech career and the pressure at the highest levels. In this episode: • Not wanting IC9 and requesting demotion • How motivation changed across his career • Fulfillment and motivation after FIRE • Why sustaining IC9 was difficult Where to watch: • YouTube - piped.video/watch?v=RMo04pSS… • Spotify - open.spotify.com/episode/3Uf… • Apple Podcasts - podcasts.apple.com/us/podcas… • Transcript - developing.dev/p/openai-and-… Thank you to the sponsors 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/ • Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev/ Chapters: 00:00 Intro 00:37 Growth past IC9 05:39 Motivation changes over his career 11:36 Asking to not be promoted 17:33 What made it hard to sustain IC9 performance 22:22 What motivated him outside of promos 26:21 Is career advice useless 29:34 Motivation after you've hit FIRE 36:08 Meaning and fulfillment 38:17 Top book recommendation 40:14 What he would change 43:24 Outro

Career update after quitting my job at Meta and spending 6 months of my savings to work on my passion projects

I quit the best job I ever had to try and build what I wish existed in the world and here's how it went:

$200 max Claude and $200 pro Codex subscriptions both run out around halfway through the week for me The recent computer use improvements have drastically improved the surface area of useful work they can do Considering getting a 3rd subscription...

My keyboard Kickstarter update below after using the first sample off the assembly line for the last 2 weeks It's surreal having something go from idea to physical product, thank you for your support 🙏 Also, notes on how we'll polish it and next steps: read.compose.llc/p/first-sam…

My goal was to record a conversation completely free of "AI doomer" takes as a timeline cleanser. For this episode, I interviewed Casey Muratori (@cmuratori) who is a video game developer and programming creator also known for his talks about the history of computing. In this episode: • Surprising findings in computer history • Where bad code comes from • The only unbreakable law in software engineering • His career in the video game industry • Why you should read technical papers Where to watch: • YouTube - piped.video/jHLbL1Eg4gM • Spotify - open.spotify.com/episode/4yw… • Apple Podcasts - podcasts.apple.com/us/podcas… • Transcript - developing.dev/p/casey-murat… Thank you to the sponsors of this episode for supporting my work: • Jira by Atlassian: Get more work done with your favorite agents and models all in one place, check them out at jira.dev/ • 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 01:08 Digging into computer science history 04:08 What shocked him 16:23 Dijkstra was depressed 26:17 The personal side of goto considered harmful 35:09 The anatomy of a 35 year mistake 50:12 Clean code horrible performance 58:33 How to write high performance code 01:01:18 Where bad code comes from 01:06:37 Why design docs before code is a bad idea 01:09:20 The only unbreakable law in software engineering 01:15:57 How he got into programming 01:21:16 Why he didnt work in big tech 01:30:44 Should you work at a startup early on 01:34:52 What video game engineering is like 01:39:57 Why preventing recursion is reasonable 01:43:24 Is vibe coding bad for the industry 01:50:17 Technical reading recommendation 01:54:27 Advice for his younger self 01:56:54 Outro

Asking Codex computer use to prompt Claude to continue after limit reset so I can sleep

Weekend AI project: Bathroom dashboard • Weather, UV index today • Health data from Google Health • Social media metrics for work • Calendar events for the day This was a one shot for GPT6 once I enabled "wireless debugging" on the tablet

Many people doubting the Kindle’s refresh rate and my typing speed Used Fable 5.1 to build a custom typing test to demonstrate both Latency isn’t an issue

I asked Fable 5.1 to summarize how it did this in a concise technical writeup. Here's what it did: Goal: Use a Compose Keyboard with a jailbroken Kindle Scribe to edit Markdown on a Mac mini through kterm and SSH. 1. Connect over BLE. The firmware used Amazon's ACE userspace stack, with a classic-only public interface. We cross-compiled a GATT client using kindlebt and ACE libraries to access BLE directly. Connections still timed out: ACE used a public address type for the keyboard's random address. An LD_PRELOAD shim in btmanagerd tracked its advertising address and corrected outgoing HCI connection commands. 2. Complete pairing. The Kindle generated a six-digit passkey but provided no keyboard-pairing UI. We captured the btPairNumericPinToDisplay event and entered the code on the Compose Keyboard, completing authenticated pairing. 3. Persist the bond. Restarting btmanagerd immediately after pairing discarded unsaved keys. Allowing the stack to save its encryption and identity keys to bt_config.conf preserved the bond across reboots. 4. Capture input. The stock input path did not handle BLE HID reports. The shim extracted keyboard notifications from decrypted ATT traffic and forwarded them through a FIFO to an injector. 5. Deliver input to kterm. Xorg did not pick up the uinput virtual keyboard. We switched to XTEST injection, restored kterm's focus before injecting events, and handled X protocol errors without exiting. Launching kterm in the foreground from a tap-scriptlet prevented launch and home-screen redraw issues. 6. Stabilize the pipeline. We removed competing FIFO readers, opened the reader with O_RDWR to avoid startup deadlock, and checked traces when a measurement tool incorrectly reported lost keystrokes. The launcher starts the pipeline, opens kterm in landscape, and connects to the Mac using SSH key authentication. A helper re-arms background BLE connection requests every 15 seconds; stored identity keys support reconnection when the keyboard wakes. The changes are reversible. Note: this writeup was AI generated but I figured it'd still be helpful since a bunch of people were asking. You can probably feed this into your LLM and ask it to follow a similar plan. It churned on this for ~3-4 hours until it got everything working.