Episode

Don't Optimize What Shouldn't Exist

Podcast
*“Yesterday, I Went to Mars ♡”*
Published
Jun 23, 2026
Duration seconds
340
Processing state
not_requested
Canonical source
https://podcasters.spotify.com/pod/show/makotowillolympusmons/episodes/Dont-Optimize-What-Shouldnt-Exist-e3l5te0
Audio
https://anchor.fm/s/fcce555c/podcast/play/121877376/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-5-23%2Fcb0363a9-4c5d-a93b-6d62-d66f5addc109.mp3
JSON
/v1/public/podcasts/yesterday-i-went-to-mars-7106663/episodes/don-t-optimize-what-shouldn-t-exist
Markdown
/podcast/yesterday-i-went-to-mars-7106663/don-t-optimize-what-shouldn-t-exist.md

Actions

  • POST https://stenobird.com/v1/public/podcasts/yesterday-i-went-to-mars-7106663/episodes/don-t-optimize-what-shouldn-t-exist/transcription-requests
    Idempotently request low-priority transcript generation for this episode.
  • GET https://stenobird.com/podcast/yesterday-i-went-to-mars-7106663/don-t-optimize-what-shouldn-t-exist.md
    Read the agent-friendly Markdown representation of this episode resource.

Summary

This episode looks at Elon Musk's five-step engineering algorithm — question requirements, delete, simplify, optimize, speed up, automate — and why the order of those steps matters more than most people realize. The most striking detail is a sensor that had been sitting inside a Tesla Model 3 battery pack for no reason other than that someone had required it once, long ago. When traced back, the engineer who added it had left the company, and the problem it was meant to solve no longer existed. When removed, nothing broke. Step 2, deletion, gets particular attention: Musk's rule isn't to remove only what's clearly unnecessary, but to delete everything possible and add back only what breaks. The observation that "if you haven't added back at least 10 percent of what you removed, you haven't deleted enough" reframes caution itself as a form of inertia. There's also a thread running through the whole framework about where intelligent people tend to go wrong — not from laziness, but from skill. The better you are at optimization, the more efficiently you can improve something that should have been removed entirely. A quiet look at how a framework built for rockets and production lines opens onto something more personal — the question of how much of what we're trying to improve was never necessary to begin with.