"I can probably count on one hand the number of times I've been glad that I didn't delete a piece of code." Kerri Miller used to think an uncalled method did no damage and more tests were always better. About 30 years in, she's stopped keeping code around in case she needs it.

One harmless-looking test was creating more than 80 records every time it ran. Kerri Miller says it didn't test anything interesting, so she deleted it. Years of using code analysis tools have made her think about the cost of every decision in the code she writes.

Code that sits between two teams tends to rot because neither feels responsible for it. Kerri Miller points to Rails partials, which are written in Ruby but get more attention from front-end engineers. That's where she wants to take Keela next. She'll be happy with 80% accuracy.

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%.

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.

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.

"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.

"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.

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.

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.

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.

"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.

"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.

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.

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.

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.

"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.

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.

"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.

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.

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."

"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.

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.

"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.

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."

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.

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.

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.

"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.

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.