Dead Code

Dead Code

@deadcode.website

A podcast by @jardo.dev about making the software industry better. New episodes every Tuesday. https://deadcode.website

68 followers11 following458 posts

LLMs have left software with fewer excuses to be slow, and Varun Gandhi agrees. He still expects to run into a lot more slow software for a while. Shipping suboptimal code has never been easier, and he thinks the pendulum will take time to swing back.

Scrolling memes about a topic can feel like learning. Alistair Norman says vibe coding gives you the same quick hits of progress. The deep understanding comes from school and academic research, even when that feels like a grind.

DHH's Rails World keynote measured AI-assisted coding in lines of code. Alistair Norman thinks he chose that number because he didn't have a better one. Work that actually helped people would have come with a metric to show for it.

Agents can spin up an app fast, and that speed is fun at first. Sofia Besenski says design principles still apply once the shine wears off. She compares it to Martin Fowler's idea that skipping design works only until a project plateaus.

DHH compared lines of code at Rails World as if more meant better. Sofia Besenski calls that tokenmaxxing. An agent running in a loop could write a million lines of Rust in a month, and it wouldn't make her a better developer.

HEY is trading one Rails app for six native apps and a Rust backend. Sofia Besenski sees six new sets of failure points. She also points to research on cognitive debt, where engineers stop understanding the systems they're building.

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