Jared interviews veteran programmer and author Russ Olsen about updating Eloquent Ruby for the last 15-ish years of Ruby evolution, from how he discovered Ruby while trying to teach his young son to code (anything but Java) to how Rails suddenly made Ruby mainstream and pushed him into writing. They unpack what “eloquent” Ruby means: solving problems with minimal fuss, staying concise but clear, and treating code as both a working machine and readable literature, plus why the book is structured from tiny examples up to larger systems to help experienced programmers learn Ruby fluently. Russ discusses newer language features like keyword arguments and pattern matching (fun, but not widely used yet), argues for a more tempered, cost-benefit approach to metaprogramming, and shares skepticism about optional static typing in Ruby (RBS/Sorbet) except at key boundaries in very large codebases. The episode closes on Russ’s “Technology as if People Mattered” philosophy and how Ruby’s community culture, often credited to Matz, reflects that human-centered mindset.

Links:

Eloquent Ruby, Second Edition (beta/book page)

Pragmatic Bookshelf beta catalog

Russ Olsen’s blog: “Technology As If People Mattered”

Russ Olsen (about page)

Overdrive by Russ Olsen

RBS (Ruby type signatures) on GitHub

Sorbet (Ruby type checker) docs

Ruby pattern matching documentation

TruffleRuby documentation (GraalVM Ruby)

Ruby Regexp documentation

Dead Code Episode: “Pickaxe Resurrection (with Noel Rappin)”

Dead Code Podcast Links:

Mastodon

X

Jared’s Links:

Mastodon

X

twitch.tv/jardonamron

Jared’s Newsletter & Website

Episode Transcript

Hosted on Acast. See acast.com/privacy for more information.

Jared interviews CS and cybersecurity grad student Daniel Fichtinger about “slopware” in open source. These are projects, often boosted by AI, that perform legitimacy with buzzwords, emoji feature lists, templates, donation links, and sweeping claims, while the underlying code is messy, over-scoped, or not actually delivering what the README promises. Daniel argues the issue is not simply “bad code” or “used AI,” but honesty, scope, and whether the maintainer can explain and maintain the work. Good projects make a strong first impression through humility, clear boundaries, and sometimes explicit limitations or alternatives. They reframe “gatekeeping” as community maintenance, a social contract of not wasting others’ time, using a gardening metaphor where slop spreads like weeds and harms beginners most by teaching bad patterns. Daniel describes stopslopware.net as a linkable educational response to repeated spammy posts and offers rehab steps: rewrite your README yourself, then incrementally replace AI-generated parts until you genuinely understand and can stand behind the whole project.

Links:

• stopslopware.net
• ficd.sh
• Daniel’s blog
• Lobsters
• The XY Problem
• Motherfucking Website
• Crafting Interpreters
• Codeberg

Dead Code Podcast Links:

Mastodon

X

Jared’s Links:

Mastodon

X

twitch.tv/jardonamron

Jared’s Newsletter & Website

Episode Transcript

Hosted on Acast. See acast.com/privacy for more information.

Jared talks with Stephen Margheim about a “missing” middle layer in modern design systems: reusable CSS affordances that sit between Tailwind utilities and full components. Stephen shares how building a no-JavaScript half-star rating input (radio buttons + labels + SVG + careful hover/layout CSS) reinforced his bias toward solving problems with the smallest toolset to avoid incidental complexity and to make solutions portable across frameworks. That philosophy leads to his critique that components are a poor vehicle for purely visual styles because they bundle structure, behavior, and aesthetics in ways that are hard to reuse—so instead, teams should name and standardize visual signals like “button” as composable classes that can apply to many semantic HTML elements. He explains how Tailwind can support this via custom utilities (@utility), tree-shaking, autocomplete, variants, and low-specificity defaults using :where(), and argues a four-layer approach—tokens → utilities → affordances → components—helps teams maintain design systems and progressively drop JavaScript as the web platform adds more native UI primitives (dialog, popover, details/name, etc.).

Links:

fractaledmind.com

Web Awesome

Font Awesome

Tailwind: Introducing Catalyst

Catalyst docs

shadcn/ui

daisyUI

Tailwind docs: Functions & directives

MDN: :where() selector

MDN: Popover API

MDN: CSS anchor positioning

MDN:

MDN: Invoker Commands API

MDN blog: Exclusive accordions with

web.dev: Interop 2026 proposals

Ruby on Rails

SQLite

Dead Code Podcast Links:

Mastodon

X

Jared’s Links:

Mastodon

X

twitch.tv/jardonamron

Jared’s Newsletter & Website

Episode Transcript

Hosted on Acast. See acast.com/privacy for more information.

In this episode, Jared is joined by Samir Talwar to talk about why “programming peaked” and how the developer experience has arguably regressed over the last 15 years—from losing powerful IDE refactoring workflows to the ways pull requests can turn into delayed integration. They dig into what teams lost when testing became “everyone’s job,” why reviews often get stuck in surface-level diff commentary, and how pairing (with rotation) can restore earlier feedback and shared context. They also get into infrastructure trade-offs: containers and Let’s Encrypt are huge wins, but Kubernetes and other “Google-scale defaults” can add heavyweight complexity for teams that don’t actually need it.

Links:

Samir Talwar (site)

“Programming Peaked” (Samir’s post)

Language Server Protocol (LSP)

Visual Studio Code

Vim

Continuous integration (Martin Fowler)

Extreme Programming (XP)

Pull requests (GitHub docs)

Kubernetes

Docker

Let’s Encrypt

Mastodon

Dead Code Podcast Links:

Mastodon

X

Jared’s Links:

Mastodon

X

twitch.tv/jardonamron

Jared’s Newsletter & Website

Episode Transcript

Hosted on Acast. See acast.com/privacy for more information.

Jared talks with Sabine Schmaltz, an OCaml Developer Advocate at Tarides, about how she went from learning Standard ML in a demanding university course to getting hired for an OCaml role despite only having written “Hello, World,” and what she’s building now: FeedMansion, a tool to improve multi-account social posting and make OCaml community content more engaging with better summaries/teasers. Sabine explains her pragmatic stack—an OCaml backend using the minimalist Dream framework, a SolidJS frontend, and OCaml-based static site generation with MLX (a JSX-like approach that gives type-checked HTML)—and notes that OCaml’s syntax can feel foreign, which is part of why projects like Reason/ReScript help. They dig into where the real friction is today: not OCaml itself, but managing LLM-assisted coding responsibly, dealing with tooling/documentation transitions (like keeping agents on Dune instead of older opam-first guidance), and handling cases where LLMs stumble—such as complex typed database queries—where she used OCaml’s PPX system to generate safer code. The conversation widens to community building via FUN OCaml (Berlin 2024, Warsaw 2025, planning 2026), what’s new in OCaml (multicore support and effect handlers), the value and risk of AI-generated open source contributions, and Sabine’s advice for introducing OCaml at work: start small, choose problems where OCaml shines (DSLs/codegen, reliable services), and help the ecosystem by open-sourcing missing building blocks like API clients.

Links:

Hindley–Milner type system

Standard ML

OCaml

ReScript

ReasonML / Reason

Tarides

X/Twitter: @sabine_s_

GitHub: @Sabine

Bluesky: @sabine.sh

Dream (OCaml web framework)

SolidJS

MLX (.mlx / JSX for OCaml)

TyXML

Opam

FUN OCaml

ICFP (International Conference on Functional Programming)

OCaml Workshop 2025

Semgrep

Dead Code Podcast Links:

Mastodon

X

Jared’s Links:

Mastodon

X

twitch.tv/jardonamron

Jared’s Newsletter & Website

Episode Transcript

Hosted on Acast. See acast.com/privacy for more information.

Jared interviews Steve Klabnik (Rust author and longtime OSS contributor) about JJ (Jujutsu), a newer version control system that can operate on Git repos via pluggable backends so you can adopt it locally without forcing teammates to switch, while getting a simpler, more flexible workflow. Steve explains JJ’s core shift: no staging/index—your working copy is effectively a mutable commit you shape as you work, making it easier to split, squash, and rewrite history without juggling Git’s extra layers and flags, and even “stash” becomes just more visible commits. He highlights JJ’s stable change IDs (so you can refer to work even as hashes change), its conflict model where rebases complete immediately and mark conflicted commits for later resolution (great for many parallel branches), and features like jj absorb (auto-placing review fixes into the right earlier commits) and jj undo (a full operation history that makes experimentation feel safe). Steve also teases work on a JJ-native collaboration/review product inspired by Gerrit-style patch workflows.

Links:

Jujutsu (jj) on GitHub

Jujutsu docs

Steve’s Jujutsu tutorial

“I see a future in jj” (Steve Klabnik)

East River Source Control (ERSC)

jj CLI reference

jj absorb

jj undo

Working with Gerrit (jj docs)

Git commit “trailers” / metadata

Git hooks

Git LFS

Perforce Helix Core

Sapling SCM

Mercurial

GitButler

The Rust Programming Language (“The Book”)

Steve Klabnik’s site

why the lucky stiff (Wikipedia)

Dead Code Podcast Links:

Mastodon

X

Jared’s Links:

Mastodon

X

twitch.tv/jardonamron

Jared’s Newsletter & Website

Episode Transcript

Hosted on Acast. See acast.com/privacy for more information.

In this episode, GitHub engineer Joel Hawksley breaks down the evolution of GitHub’s UI architecture—from Rails views to ViewComponent to React—and the tradeoffs behind each step. ViewComponent emerged as a practical, backwards-compatible way to eliminate duplicated UI logic in GitHub’s massive Rails monolith, ultimately supporting thousands of components and becoming a key driver of consistency and accessibility. Joel explains how hard UI correctness is compared to backend systems, how keyboard-only tests surfaced real accessibility regressions, and why ViewComponent v4 streamlines the project as it enters a stable, long-term support phase. He also discusses why GitHub increasingly leans on React for complex, app-like behavior: developer enthusiasm, design-system tooling, CSS encapsulation, and the need to manage frontend–backend sync at scale. The conversation closes with reflections on the realities of open-source maintenance and the importance of stability as ViewComponent’s future.

Links:

Joel Hawksley’s Website

ViewComponent Website

ViewComponent GitHub Repo

Primer ViewComponents

Primer ViewComponents Repo

Phlex Website

Phlex GitHub Repo

Herb GitHub Repo

ReActionView GitHub Repo

WCAG Accessibility Standards

Rails Strict Locals Documentation

Dead Code Podcast Links:

Mastodon

X

Jared’s Links:

Mastodon

X

twitch.tv/jardonamron

Jared’s Newsletter & Website

Episode Transcript

Hosted on Acast. See acast.com/privacy for more information.

In this Dead Code episode, Jared and ReScript contributor Josh Vlk explain why ReScript is a strongly typed, sound language for web development that compiles to JavaScript, offers first-class React support, and favors a “one right way” approach (built-in formatter, no linters) over TypeScript’s configurable sprawl. They trace its evolution from Reason/BuckleScript to today’s standalone ReScript, with v12 shedding legacy OCaml baggage, adding a rewritten Rust compiler for major speed, native monorepo support, zero-cost JS bindings, and automated upgrade fixes. The pair highlight how variant types and exhaustive pattern matching naturally model complex business logic and make refactors safe and fast, often resulting in less code and fewer bugs. Adoption can be incremental—drop a rescript.json, compile alongside TS/JS, and start with a small component or state reducer. Jared closes by urging developers to try it, noting ReScript’s consistency may also make it especially friendly for AI-assisted coding.

Links:

ReScript

TypeScript

ReasonML

BuckleScript

OCaml

Rust

“ReScript Has Come a Long Way — Maybe It’s Time to Switch from TypeScript” by Josh Vlk

“Domain Driven Design Made Functional” by Scott Wlaschin (F# / functional programming concepts)

ReScript Forums

ReScript Docs

ReScript Packages on npm – Community bindings and libraries

Josh Vlk on Bluesky

Josh’s website

Dead Code Podcast Links:

Mastodon

X

Jared’s Links:

Mastodon

X

twitch.tv/jardonamron

Jared’s Newsletter & Website

Episode Transcript

Hosted on Acast. See acast.com/privacy for more information.

In this episode, Dave Copeland discusses Brut, his Ruby web framework built atop Sinatra that prioritizes “simple over easy” design principles. Brut replaces traditional MVC with pages, forms, and handlers, uses Flex for HTML generation, Sequel for database access, and lightweight tools like BrutCSS and BrutJS for styling and interactivity, emphasizing direct alignment with web standards. It eliminates free-form parameter hashes by injecting structured objects, mirrors HTML for form validations, and defaults to a strict, Postgres-only setup with non-nullable fields, required foreign keys, and built-in observability through OpenTelemetry and a strict Content Security Policy. Dave and Jared also discuss modern browser-based CSRF protections, the philosophy behind Brut’s defaults, and how Dave aims to refine it toward a 1.0 release with real-world apps and clear migration paths for Rails developers, positioning Brut as a lightweight, standards-aligned alternative within the Ruby ecosystem.

Links:

Brut

Sinatra

Hanami

Sequel

Tachyons

Tailwind CSS

OpenTelemetry

PostgreSQL

MDN Web Docs

Elektron Digitakt

Ableton Live

ActiveRecord

CoffeeScript

Content Security Policy (CSP)

Rich Hickey – “Simple Made Easy” talk

Burg.rb

Dead Code Podcast Links:

Mastodon

X

Jared’s Links:

Mastodon

X

twitch.tv/jardonamron

Jared’s Newsletter & Website

Episode Transcript

Hosted on Acast. See acast.com/privacy for more information.

Jared talks with Adam Tornhill, founder of CodeScene, about the psychology of programming and how understanding human cognitive limits leads to better software. Adam explains that since working memory can only juggle a few items at once, developers must rely on chunking and good abstractions to manage complexity. His Code Health metric, based on detecting “ugliness” like long functions and low cohesion, shows that healthy code enables teams to deliver features up to ten times faster with far fewer defects. They discuss how God classes become coordination bottlenecks, how behavioral code analysis reveals hotspots where improvement matters most, and why learning different programming paradigms sharpens thinking. Adam emphasizes that writing readable, well-named, modular code benefits both humans and AI tools—because clarity, consistency, and thoughtful naming make code easier to understand, maintain, and extend.

Links:

CodeScene

Your Code as a Crime Scene

Working Memory

God Class / God Object

Domain-Specific Languages (DSLs)

Dead Code Podcast Links:

Mastodon

X

Jared’s Links:

Mastodon

X

twitch.tv/jardonamron

Jared’s Newsletter & Website

Episode Transcript

Hosted on Acast. See acast.com/privacy for more information.