Russ Olsen explains why people glaze over when you teach features in the abstract and why seeing one real use case in real code flips the switch. If you have ever learned something only after watching it used “in the wild,” this clip is for you.

Ruby can be fast, elegant, and still crystal clear. Russ Olsen nails why “works” is not the same as “readable,” and why the best code pulls double duty as both a machine and a message to the next human.

If you cannot explain what you shipped, you do not really own it. Daniel Fichtinger has practical advice for fixing that.

If you care about healthy beginner spaces, listen to Daniel Fichtinger on why slop spreads so fast.

Ever click a “new project” link and immediately feel skeptical? Daniel Fichtinger breaks down what that instinct is catching, and why it matters.

Daniel Fichtinger on the real slopware tell: it is not “used AI,” it is the gap between promises and reality.

Need a quick gut-check for whether an open source project is worth your time? Daniel Fichtinger shares the trust signals that actually matter.

Stephen Margheim outlines a middle path between Tailwind class soup and component sprawl. He shows how to compose higher-level styling in Tailwind while keeping tree shaking, autocomplete, and flexibility, so teams ship faster without a pile of one-off classes.

Stephen Margheim explains a modern CSS trick that makes defaults behave like defaults. He digs into the specifics of zero-style, which keeps overrides predictable and composable, especially in real design systems.

Stephen Margheim uses a door handle metaphor to explain design systems. Good UI signals how it’s meant to be used without labels or hacks. Margheim connects that idea to affordances and how naming that middle layer improves consistency.

Stephen Margheim makes a brutal point. Components are a bad delivery mechanism for “just styles.” If you’ve ever tried to borrow a component kit’s look and found it welded to structure and behavior, Margheim explains why that pain is baked in and what to do instead.

Stephen Margheim built a star rating UI with no JavaScript that still submits like a real form input. Most star widgets are pretty theater until the backend needs an actual value. He breaks down half-star ratings using plain HTML & modern CSS, without the hidden input duct tape.

Kubernetes, cloud services, functions, frameworks: the benefits are obvious…until you’ve lived with them for a year. Samir Talwar breaks down the hidden costs teams don’t account for (and why so many companies are building like they have billions of users).

This episode has one of the best explanations we’ve heard of what great testers actually do and why so many teams miss the point when they eliminate the role.

If your team’s “modern process” routinely turns into waiting around for reviews, you’re going to like this segment. Samir Talwar challenges the default PR workflow and makes the case that we’ve normalized delayed shipping as if it’s a feature.

There’s a specific kind of sadness that comes from realizing your daily workflow is starting to feel like 1970 again. Samir Talwar talks about the regression from structure-aware refactors to manual text wrangling, and why it’s making programming worse.

Everyone’s using AI for “refactors” now, but this convo asks a sharper question: why celebrate a workaround for what our tools already knew? Samir Talwar digs into what we lost as editors got slower and workflows got dumber. If you’ve felt the drag, this will hit.

HTMX is not “anti-JS.” It’s “stop making the browser suffer.” If you’ve ever watched a simple UI become a 400-file front-end, this one will hit. shows.acast.com/dead-code/e...

AI crawlers want your content. Heydon wants them to eat garbage. A hilarious and practical episode about “poisoning” your own site to waste scraper resources. shows.acast.com/dead-code/e...

Building in OCaml doesn’t have to be a purity test. Sabine breaks down a pragmatic stack (OCaml + a mainstream frontend) and why that choice matters in the LLM era.

Most “communication problems” in engineering are actually alignment problems. Rebecca Murphey breaks down why writing matters, how to make it useful, and how it changes your org. shows.acast.com/dead-code/e...

Dependency injection is great…until it becomes a Rube Goldberg machine. This episode is a reality check on “clever” architecture and how it quietly turns into dead code. shows.acast.com/dead-code/e...

We get into the uncomfortable part of AI + open source: giant drive-by PRs, maintainers as the long-term memory of a codebase, and why “the model says it works” is not a review strategy. If you maintain anything or contribute to anything, this section alone is worth the listen.

A lot of engineering “best practices” are just fear in a trench coat. A great conversation about testing, feedback loops, and what we do when we don’t trust our own systems. shows.acast.com/dead-code/e...

You can “just parse JSON” right into a security incident. This episode is a tour of serialization, sharp edges, and the kind of bugs that show up at 2am. shows.acast.com/dead-code/e...

Sabine Schmaltz makes a great point: runway isn’t just money, it’s energy. The ecosystem you build in can protect that, or drain it fast.

OCaml has great content. Like, actually great content. Sabine's building a tool to stop community links from being posted like dead fish—no context, no teaser, no reason to care. If you’ve ever tried to grow a technical community & felt the friction, you’ll want this convo.

Some people learn a language because they planned to. Sabine Schmaltz got pulled into OCaml because a job post nudged her into a whole ecosystem and she ran with it. This episode is a reminder that “I’m new to this” is not a disqualifier if your fundamentals & curiosity are real.

jj has early-Rust energy: confusing, then it clicks, then you don’t want to go back. Steve Klabnik explains why adoption is easier when you can take it for a spin without getting your whole team on board.

The best feature isn’t flashy. It’s safety. Steve Klabnik talks about why jj makes it easy to experiment, recover fast, and stop fearing “one wrong command.”

Fear not the rebase. Steve Klabnik explains jj's “keep going, resolve later” approach to conflicts which saves time and let's you deal with what matters, when it matters.

Clean, review-friendly history shouldn’t require five different rituals and incantations. Steve Klabnik breaks down how jj makes common Git workflows feel simpler and more natural.

Version control can get better without forcing your whole team to switch tools. Steve Klabnik explains why jj is clicking for Git power users and Git skeptics.

We talk a lot about the beauty of open source. We don’t talk enough about the fragility. There's human factors, the burnout, the life cycles that end quietly. Joel Hawksley's perspective here is brutally true and rarely said out loud.

The real reason companies choose React? It’s not just tech. It’s people. Culture. Hiring. Sustainability. Joel Hawksley gives the most honest breakdown we’ve heard of how those decisions actually get made inside big engineering orgs.

Accessibility isn’t a checkbox. It’s leverage. Joel Hawksley shares how accessibility work at GitHub became the engine behind cleaner UI, smarter abstractions, and better architecture. If you care about scaling UI in the real world, this part hits hard.

You might’ve tried it years ago. You might’ve bounced off ReasonML. But everything you thought was hard about ReScript? It’s gone. Josh Vlk explains why 2025 is the year to revisit one of the most underrated languages on the web.

GitHub didn’t adopt ViewComponent because it was flashy. They adopted it for fit. It fit into a massive Rails monolith, a legacy team, and into years of product history. Joel Hawksley breaks down how you ship architectural change in a company where you can’t just “rewrite it.”

Ever look at the frontend wars & think, “We’re all arguing about the wrong things”? Joel Hawksley joined us to dig into the deeper ideas behind UI architecture — the ones that outlive frameworks, trends, & hot takes. One of the most grounded, clarifying conversations we’ve had.

ReScript doesn’t just help you write better code—it changes how you think about it. Josh Vlk joined Dead Code to talk about how it pushes developers toward cleaner logic, safer state management, and refactoring without fear.

Forget the old names. No more OCaml baggage, no ReasonML confusion, no Belt.Array2 nightmares. ReScript has finally stepped into its own—and it’s smoother, faster, and way more familiar than you think.

This was a thoughtful interview about an ML with great dev experience on the JS ecosystem, which is a compelling combination. I found a nice 3rd party writeup of its current state: lobste.rs/c/pqdn4v

In JavaScript, there are a hundred ways to solve the same problem. In ReScript, there’s one—and it actually makes your life easier. Josh Vlk explains why enforced consistency might just be the future of clean code.

JavaScript’s grown-up sibling just entered the chat. Strongly typed, zero config, and built for people who want their code to just work. Josh Vlk joined Jared to explain why ReScript isn’t just another TypeScript flavor—it’s a full rethink of how we build for the web.

“Sometimes you need null database columns — but only if you’ve thought through why.” David Bryant Copeland talks about building frameworks that guide developers toward better decisions by default.

What’s the bane of David Bryant Copeland’s existence in Rails? Those endless params hashes. In this clip, he explains how Brut gets rid of them for good.

“Rails is easy… but it’s not simple.” David Bryant Copeland unpacks why simple code often takes more effort — and why he designed Brut around that philosophy.

Sometimes fewer knobs make better music. David Bryant Copeland shares why he loves the limitations of his DAWless Looptober setup — and how constraints fuel creativity.

Rails makes it easy to build fast. But do you ever feel like you’re learning everything twice? David Bryant Copeland breaks down why abstractions can get in the way of real understanding.

The hardest problem in computer science? Naming things. Adam Tornhill explains why *good names* don’t just help humans, they also help your AI assistants write and reason better code.