iiinova — where your digital self keeps evolving

Kerri Miller built Keela to stay out of engineers' way, and she kept receipts to show it was worth it. Removing dead code at GitLab now saves about $150,000 a year in CI costs. It also cut the app's overall compute complexity score by around 2.5%.

100

Dead Code @deadcode.website · 29/09/2026

Most big codebases have a layer where someone changed everything at once. Kerri Miller compares it to the K-T boundary in the fossil record. Those sweeping commits touch hundreds of files and break git blame. Keela takes the slower route and blocks new dead code as it comes in.

100

Dead Code @deadcode.website · 23/09/2026

Some of your throwaway code is going to become permanent, and Noah Silvera thinks that can be fine. What decides whether it ever gets replaced is naming. Code nobody can follow does not get rewritten. It sits there because everyone is too scared to touch it.

100

Dead Code @deadcode.website · 23/09/2026

"Some bottlenecks just can't be widened no matter what Sam Altman says." Noah Silvera did hand an AI agent a feature on deadline and it worked. It came back messy but correct enough to ship. She credits knowing the requirements well enough to write precise verification criteria.

200

Dead Code @deadcode.website · 18/09/2026

"It will not matter if you deliver something if you deliver the wrong thing." Noah Silvera does the arithmetic. Skipping the research saves half a day. Fixing the same problem in production costs a day and a half. The client waits longer for what they actually needed.

100

Dead Code @deadcode.website · 16/09/2026

Your product manager is relaying what another team told them, and so was that team. Noah Silvera calls it the line of telephone. Taking a requirement at face value means trusting all of it. She argues engineers own the outcome either way, so the floor is asking the client why.

100

Dead Code @deadcode.website · 15/09/2026

Some iteration happens outside the codebase. Noah Silvera has spent six years at Super Good Software on clients who want everything fast and right the first time. She argues the cheapest way to avoid building the wrong thing is negotiating requirements before opening the editor.

100

Dead Code @deadcode.website · 09/09/2026

Your production server is slow and nobody can tell you why. Charles Nutter attaches a tool to a running process and watches where the time goes, at one or two percent overhead. That tooling is a big reason JRuby users stay and comes from thousands of engineers improving the JVM.

100

Dead Code @deadcode.website · 09/09/2026

"Some of them tell me they've been running JRuby for 15 years, and I never heard a word about it." Charles Nutter meets new JRuby users at every conference he attends. He funds the project himself now through Headius Enterprises, and those users are the reason it still ships.

100

Dead Code @deadcode.website · 04/09/2026

"The top three complaints about JRuby are all startup time, basically." Charles Nutter thinks JRuby would be close to standard in Ruby shops today if that had been solved a decade ago. He also explains why the fix was never his to make and what the OpenJDK team changed recently.

100

Dead Code @deadcode.website · 02/09/2026

It cost $50 to get in and 60 people showed up. Charles Nutter was a Java architect on government contracts when he sat in on that DC Ruby conference and understood every slide without ever writing Ruby. He went looking for a way to use it at work and found JRuby idle since 2001.

100

Dead Code @deadcode.website · 01/09/2026

People hear "Ruby on the JVM" and immediately picture themselves writing Java. Charles Nutter has spent 20 years saying otherwise. JRuby is a full Ruby implementation, and a Rails or Hanami app comes straight over to run on better garbage collection and real parallel threads.

120

Dead Code @deadcode.website · 28/08/2026

His managers quoted the Agile Manifesto for a year. He assumed it was 400 pages of ISO-style rules. Then Nik Suresh actually looked it up, found five lines, and spent a week convinced he'd found the wrong document. His manager was no help. He'd never read it either.

100

Dead Code @deadcode.website · 26/08/2026

"If you've got one-hour stand-ups, like, just quit. You're cooked." Nik Suresh thought he was immune to his dysfunctional workplace because he could see how silly it was. Years later, he can name exactly what staying cost him.

110

Dead Code @deadcode.website · 21/08/2026

One day late? Freak out. Nik Suresh argues a missed deadline is evidence your estimate was wrong from the start, and every extra week makes that case stronger. His fix is to panic on day one, when there's still time to do something about it.

100

Dead Code @deadcode.website · 19/08/2026

"You're asking people to lie to you basically full time." Nik Suresh has a theory about what Jira boards and story points are really for. Hint: it has more to do with executive comfort than shipping software.

100

Dead Code @deadcode.website · 18/08/2026

Layoffs were coming, so every team started relabeling their one-point stories as threes. Nik Suresh watched it happen during COVID: velocity numbers went up, executives were pleased, and the teams that reported honest numbers got fired. Every single one of them.

100

Dead Code @deadcode.website · 14/08/2026

Always dreamed of building your own programming language? Nithin Bekal's advice: just dive in. Parsing is more approachable than it looks, and his first working release shipped in three days. "It may not be adopted by everyone, but who cares? You'll learn a lot along the way."

110

Dead Code @deadcode.website · 12/08/2026

"I add something in and then, like, two days later, I realize I hate it." Language design is hard. And Nithin Bekal says his language will keep its rough edges until he does the one thing he hasn't done yet: actually write code in it.

100

Dead Code @deadcode.website · 07/08/2026

Matz built Spinel. Steve Klabnik built Rue. And Nithin Bekal built Sapphire. There's a whole cluster of new hobby languages right now, and it's not a coincidence. Getting to 90% of a language in two months changes the math.

100

Dead Code @deadcode.website · 05/08/2026

"I definitely feel like I've lost control of the codebase." Nithin Bekal has a working language, a Wasm target, and 15,000 lines of Rust he doesn't fully understand. Now comes the hard part: taking it back.

110

Dead Code @deadcode.website · 04/08/2026

His laptop died a few weeks into building a new programming language. So he kept going... from his phone. Nithin Bekal on what it's like to give an LLM complete control over how your language evolves, and why it was "scary."

111

Dead Code @deadcode.website · 29/07/2026

Elixir would have made the event sourcing part easier. Ismael Celis picked Ruby anyway, specifically so it would be harder. The constraint was the point.

101

Dead Code @deadcode.website · 24/07/2026

Optimistic locking is a proxy for the real question. Ismael Celis on Dynamic Consistency Boundaries and what it actually means for a decision to still be valid by the time you commit it.

100

Dead Code @deadcode.website · 24/07/2026

Every time you update the cart, you throw away what the cart used to be. Ismael Celis makes the case that the temporal model isn't an alternative to the relational one. It's a superset of it.

100

Dead Code @deadcode.website · 22/07/2026

"How was your day?" You don't answer with a schema. You answer with a sequence of events. Ismael Celis on why we model software in a mode we don't actually think in.

100

Dead Code @deadcode.website · 21/07/2026

Event sourcing gets a reputation for being heavy. Ismael Celis says the core of it fits in a Ruby file and an array. Everything else (the eventual consistency, the runtime, the workflows) is an optional rabbit hole.

112

Dead Code @deadcode.website · 17/07/2026

Hanami 3.0 is just the beginning. Tim Riley shares what’s next for the framework, from a richer extension API to a developer experience people will actually want to show off.

110

Dead Code @deadcode.website · 15/07/2026

Ruby is a mature language, but the ecosystem is full of innovation. In this clip, Tim Riley makes the case for new ideas, different architectural approaches, and keeping the ecosystem open to experimentation.

100

Dead Code @deadcode.website · 10/07/2026

What happens when companies sponsor open source? Sometimes it gives maintainers the freedom to build the things everyone benefits from. Tim Riley talks about how sponsorship made Hanakai, Hanami 3.0, and a year of steady progress possible.

110

Dead Code @deadcode.website · 08/07/2026

Open source isn't just about access to code. Hanakai puts its values front and center. Tim explains why building an intentional, welcoming community is every bit as important as building great software.

100

Dead Code @deadcode.website · 07/07/2026

Ruby isn't a one-framework language. Tim Riley explains why Hanakai brings Hanami, Dry, and ROM together under one roof and why giving developers more architectural choices makes the Ruby ecosystem stronger.

110

Dead Code @deadcode.website · 03/07/2026

Ted M. Young’s biggest concern about AI isn’t that it will replace developers. It’s that developers may stop learning. In this clip, he explains why hands-on problem solving still matters and why he’s optimistic about the future of software craftsmanship.

110

Dead Code @deadcode.website · 01/07/2026

A board game about test-driven development turned into a lesson about teamwork. Ted M. Young shares how players naturally discovered the benefits of pairing and mob programming once they saw how much faster they could solve problems together.

100

Dead Code @deadcode.website · 26/06/2026

Most event sourcing conversations start with audit trails and time travel. Ted M. Young was convinced by something much simpler. In this clip, he explains why event sourcing changed the way he thinks about software architecture and persistence.

100

Dead Code @deadcode.website · 24/06/2026

Software development gets safer when the steps get smaller. Ted M. Young explains how predictive TDD helps developers take “many more much smaller steps,” creating faster feedback loops and more opportunities to learn before mistakes become expensive.

110

Dead Code @deadcode.website · 23/06/2026

Most developers expect a test to fail. Ted M. Young argues that the real value comes from predicting exactly how it will fail. When the result doesn’t match your expectation, you’ve uncovered a misunderstanding before it becomes a bug.

223

Dead Code @deadcode.website · 19/06/2026

Maybe the problem isn’t vibe coding. Maybe the problem is spending all day watching everyone else "build". Joan Westenberg shares her thoughts on doomscrolling, comparison, and why creators should spend less time consuming social media and more time focusing on their own work.

100

Dead Code @deadcode.website · 17/06/2026

What’s the best way to build something people care about? According to Joan Westenberg, it starts with creating something you genuinely want for yourself and the people around you, not chasing trends or trying to please everyone.

100

Dead Code @deadcode.website · 12/06/2026

AI didn’t just change how software gets built. It changed how communities have to defend themselves. Joan Westenberg discusses how AI-generated spam is reshaping moderation and why many of the internet communities we remember fondly would be much harder to build today.

100

Dead Code @deadcode.website · 10/06/2026

The biggest communities rarely start with a master plan. They start because someone finds a place they love, invites other people in, and slowly creates a home. Joan Westenberg explains why community can’t simply be designed into existence.

100

Dead Code @deadcode.website · 09/06/2026

It doesn't even take a weekend to vibe code a Hacker News clone. What you can’t generate with a prompt is the reason people come back. Joan Westenberg on why community is harder to build than software.

100

Dead Code @deadcode.website · 01/05/2026

Testing in Rails usually forces a tradeoff. Factories are flexible but slow. Fixtures are fast but messy. Kasper Timm Hansen built something that tries to fix both. Oaken is a different way of thinking about test data entirely.

111

Dead Code @deadcode.website · 29/04/2026

What if your dependencies were so small… that you weren’t afraid of them? Kasper Timm Hansen talks about why he aggressively limits lines of code and keeps gems tiny on purpose. Smaller code is easier to trust, understand, and even take over.

100

Dead Code @deadcode.website · 24/04/2026

One of the biggest challenges in Rails apps: your models never stop growing. User. Account. Order. They just keep expanding. Kasper Timm Hansen explains why the real job is breaking things apart before they get out of control.

100

Dead Code @deadcode.website · 22/04/2026

What’s the difference between a concept and an abstraction? One has direction. The other can feel like loose parts. Kasper Timm Hansen uses a simple analogy to explain why most code feels harder than it should. Better modeling starts with clearer ideas.

100

Dead Code @deadcode.website · 22/04/2026

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.

110

Dead Code @deadcode.website · 17/04/2026

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

100

Dead Code @deadcode.website · 15/04/2026

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.

100

Dead Code @deadcode.website · 10/04/2026

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.

120