After leaving Rails Core, Kasper Timm Hansen started building much smaller tools. Not bigger frameworks. Not complex systems. Small gems with very specific ideas behind them. He explains why those tiny projects can actually have more impact.

An entire CPU emulator. Written in CSS. Lyra explains how you can compile C code and run it without touching JavaScript at all.

What if the problem isn’t CSS… what if it’s how we think about CSS? Lyra talks about how treating it like a “not real language” limits what developers even try to build. That mindset leaves a lot of capability on the table.

A lot of the web runs on layers of JavaScript that don’t need to exist. Buttons. Hover states. Simple interactions. Lyra Rebane breaks down why CSS can handle more than most developers think and why that matters for performance.

Most developers think they understand CSS. But they’ve only seen a fraction of what it can do. Lyra Rebane shares how pushing the limits of CSS completely changed how she approaches programming and security.

CSS isn’t just for styling anymore. People are building games, logic, and entire systems with it. Lyra explains how a weird little corner of the internet turned CSS into something much bigger.

One of the hardest lessons many developers learn: Most people don’t care how the software is built. They care whether it works. Dave Copeland talks about the moment he realized businesses only care about outcomes, and how AI tools might push the industry in that direction.

If AI writes most of the code, what happens to the things devs obsess over? Architecture patterns. Dependency injection. Security blog posts. Conference talks. Dave Copeland wonders whether the conversation shifts from how software is written to whether the outcome works.

A lot of developers love programming for the same reason. You tell the computer what to do, and eventually it does exactly that. Dave Copeland explains why that feeling of control and discovery is what makes coding satisfying & why AI coding tools challenge that relationship.

For a long time, software engineering felt like one of the safest careers in tech. High demand. Endless jobs. Always more code to write. Dave Copeland talks about the strange moment when that assumption stopped feeling guaranteed.

The failure mode is simple: the “sensible” architecture can’t ship on the real timeline. Sean Goedecke explains why design handoffs collapse under constraints, and how incentives create complexity engineers maintain. If you’ve seen a diagram, then opened repo in despair, yep.

AI coding tools are forcing a lot of experienced devs to ask a hard question: What happens to the craft of programming if the machines start writing most of the code? Dave Copeland talks about the moment he realized the ground might be shifting under the entire profession.

You can build three “well-designed” subsystems and still end up with a disaster. Sean Goedecke talks about how smart engineers create Frankenstein codebases when they optimize locally instead of matching existing patterns. Great reminder that coherence is a feature.

In large codebases, “perfect design” matters less than consistency. Sean Goedecke argues that once a system is huge, nobody can keep it all in their head, so teams survive on patterns, prior art, and “looks like the other things.” It might annoy purists. It will save your team.

Most “design advice” is just vibes unless you’ve lived in the codebase. Sean Goedecke breaks down the gap between generic principles and real design decisions shaped by actual constraints. If “just refactor it” came from someone who’s never opened the repo, this one’s for you.

The best design conversations sound like: “pull up the file.” Sean Goedecke describes a GitHub offsite where the discussion was painfully code-specific, and that’s exactly why it worked. No philosophy, no framework worship, just the actual system and what it can handle.

Russ Olsen drops the thesis every doc writer and teacher needs tattooed on their brain: the subject of your work is the reader. The tool does not change. The human does. If you write docs, teach, or lead devs, this clip hits.

Russ Olsen gives a sharp, practical critique of gradual typing in Ruby. Not anti-types, not anti-safety, just brutally honest about the tradeoffs when the type system is optional, and the annotations start getting more complex than the code.

Russ Olsen has the most accurate take on the emotional experience of learning a new language: if it looks foreign enough, your brain labels it as wrong. Then you live with it, and suddenly it is normal. This clip is a perfect reminder to stay curious instead of defensive.

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.