{"version":"v1","site":{"name":"expectedwrong","url":"https://expectedwrong.com"},"links":{"collection":"https://expectedwrong.com/api/public/posts","rss":"https://expectedwrong.com/rss.xml","llms":"https://expectedwrong.com/llms.txt"},"post":{"slug":"podcast-made-the-code-better","title":"The Podcast Made the Code Better","subtitle":"Adding a constraint you didn't ask for will simplify things you weren't trying to simplify.","url":"https://expectedwrong.com/podcast-made-the-code-better","api_url":"https://expectedwrong.com/api/public/posts/podcast-made-the-code-better","published_at":1715256000,"published_at_iso":"2024-05-09T12:00:00.000Z","updated_at":1771541257,"updated_at_iso":"2026-02-19T22:47:37.000Z","tags":["meta","tooling","podcasting","simplicity"],"excerpt":"Adding a constraint you didn't ask for will simplify things you weren't trying to simplify.","meta_description":"Adding a constraint you didn't ask for will simplify things you weren't trying to simplify.","reading_time_minutes":1,"word_count":218,"engagement":{"signals":0,"counterpoints":0},"body_markdown":"Decided to podcast everything — every project, every decision, every thing I'm building — which immediately created a problem, which is that my podcast setup was not something you could casually record into.\n\nSo I simplified the podcast. Which forced me to think about what I was actually trying to say. Which forced me to think about what I was actually building. Which, somehow, made the code simpler.\n\nI did not see that coming.\n\nThere's probably a principle buried in here about how the act of explaining a thing to an audience — even a hypothetical one, even one that might be just you — creates pressure on the thing itself. If you can't explain what the code does in the time it takes to introduce a podcast episode, maybe the code is doing too much. Or doing it wrong. Or both.\n\nDescript is what I'm using to prep it all. It treats audio like a text document — you edit the transcript, the audio follows. It's either the most obvious idea anyone's ever had or a genuinely weird inversion of how you'd expect a recording tool to work, and I can't decide which.\n\nEither way, I now have simpler code and a podcast, which is two more things than I had before I tried to have either.\n","body_text":"Decided to podcast everything — every project, every decision, every thing I'm building — which immediately created a problem, which is that my podcast setup was not something you could casually record into. So I simplified the podcast. Which forced me to think about what I was actually trying to say. Which forced me to think about what I was actually building. Which, somehow, made the code simpler. I did not see that coming. There's probably a principle buried in here about how the act of explaining a thing to an audience — even a hypothetical one, even one that might be just you — creates pressure on the thing itself. If you can't explain what the code does in the time it takes to introduce a podcast episode, maybe the code is doing too much. Or doing it wrong. Or both. Descript is what I'm using to prep it all. It treats audio like a text document — you edit the transcript, the audio follows. It's either the most obvious idea anyone's ever had or a genuinely weird inversion of how you'd expect a recording tool to work, and I can't decide which. Either way, I now have simpler code and a podcast, which is two more things than I had before I tried to have either.","hindsight":{"verdict":"persists","note":"the 'explaining forces simplification' insight is timeless. developers who document and narrate their work consistently produce cleaner code. the podcast-as-debugging-tool observation was unusual and correct.","links":[],"at":1739980800,"at_iso":"2025-02-19T16:00:00.000Z"}}}