The Changelog: Software Development, Open Source - Code like a surgeon (News)

Episode Date: October 27, 2025

The Dead Internet Theory dies, Geoffrey Litt tries to code like a surgeon, Matt Sephton thinks spreadsheets are great for UI design, Nate Meyvis advocates for front-end maximalism, Hemant Pandey thinks 9-5 employment is a great option for most, David Miranda compares React to Backbone in 2025.

What up, nerds? I'm Jared, and this is ChangeLog News for the week of Monday, October 27th, 2025. Rest in peace, dead internet theory. A new study found that AI is now writing as many web articles as humans, and that's just counting the robots they actually caught. I think it's time we pronounce. the theory dead because the dead internet itself is alive and growing. Oh, and did I mention that AI assistants also misrepresent news content 45% of the time? Ooh. Okay, let's get into this

week's news. Code like a surgeon. Needless to say, we're all trying to figure out how to best do the code thing in a post-LLM world. Should we direct? Should we babysit? Should we ignore the hype and just keep typing, Jeffrey Litt has opinions. Quote, Personally, I'm trying to code like a surgeon. A surgeon isn't a manager. They do the actual work, but their skills and time are highly leveraged

with a support team that handles prep, secondary tasks, and admin. The surgeon focuses on the important stuff they are uniquely good at, end quote. This software surgeon concept isn't a new idea. Fred Brooks talked about it way back in 1975. Back then, the support roles were all other humans, but that means it scales way better now when we can get all of our support from robots.

In other words, we can all be surgeons now. Q. Weird Al, doing what he does best. Even with this metaphor in hand, the hard part remains identifying what matters and what doesn't. And that is A, a moving target. can be a hard pill to swallow, especially if you enjoy things that no longer matter, and C requires change. And change is often the hardest part of all. How to tame a user interface using a spreadsheet. Here's Matt Sefton, quote, many years ago, while working at Apple and running a lab at WWDC,

I met a guy who was using a piece of Apple software designed for creating interactive ads to design a carplay user interface for a popular U.S. car manufacturer. impressed by his ability to think outside the box and told him so. I mentioned to him how human interface designers at Apple were using Keynote to rapidly prototype user interfaces and animations. The discussion then took a strange turn onto spreadsheets. End quote. I remember having my mind blown when I learned that the lead designer behind Groovesharks's enviable UI did all of his work in Keynote. It's an amazingly malleable piece of software. Matt, it turns out, thinks spreadsheets are one of the greatest user interface design tools ever created. In the linked post, he shows you why

and how. Front end maximalism. Nate Mavis says, quote, here's a question that comes up all the time. I have a front end that calls into a back end. It needs to do things now and might need to do more things later. How much filtering and pre-processing should the back end do before it passes the data to the front end? And here's an answer that I like, as little as possible. End quote. Nate takes a front-end maximalism approach, which I actually disagree with pretty strongly. For some of the reasons he lists in the When Not Use a Front End Maximilist Approach section of his post. Still, I'm happy to link to Nate's post, even though I think he's wrong, because I appreciate the viewpoint diversity,

and these are absolutely discussions we should be having. Also, I find his use of Gaul's law to advocate for putting more logic in your front end. Kind of hilarious. It's now time. For sponsored news, GitHub Actions, but faster. Your CI shouldn't be the bottleneck between commits and customers, but the truth is, it can be. GitHub Actions can feel slow out of the box, long builds, redundant installs, wasted minutes, it all adds up. Namespace fixes that with blazing fast caching for GitHub Actions.

It accelerates dependency installs, reuses previous builds, and keeps your pipelines warm. So, instead of waiting for containers to build, or parts of your toolchain. to install, you're shipping new features. The result? Less coffee breaks, more deploys. Teams are shaving minutes off every run, saving many hours per week. That means faster iteration and faster customer impact. If you're using GitHub actions and love your time, check out Namespace. Learn more at namespace.S.O or by following the link in this week's newsletter.

And thank you to Namespace for sponsoring ChangeLog News. Why the 9 to 5 is underrated. As a guy who hasn't worked a 9 to 5 since 2011, I deeply understand both the pros and cons of self-employment, and I wince when I see people fetishize being your own boss like it's the end-all be-all of career achievement. It's not very often that I see somebody explicate why typical 9-5 employment is actually a great option for many people, so I thought I'd link up this post by Hamant Pandy, which does a good job of it. Quote, the 9-5 has been unfairly villainized. it like a cage, but for most people, it's actually the best launch pad to build a great life.

You don't have to quit your job to build a meaningful, fulfilling life. You just have to be intentional with how you approach it, end quote. Hamant lays down five ways you can intentionally approach your 9 to 5 to make it work for you. One, find the right environment. Two, invest in skills that compound. Three, build something small on the side. Four, redefine freedom. And five, use stability as leverage.

Lots of good advice in this post, ending with this, which I will gladly co-sign. Quote, maybe one day you'll quit and go all in, but do it because you're ready, not because the internet told you to. React versus Backbone in 2025. David Miranda built two simple password strength testers, one in React and one in Backbone. Remember Backbone? Quote, look at the two implementations above. The code is roughly the same length. They do exactly the same thing.

One was written with a framework from 2010. the other with a framework that's had countless developer hours and a massive ecosystem behind it for over a decade. The interesting part is not how much better React is, it's how little progress we've actually made, end quote. David argues that React looks cleaner, but you're trading explicit simplicity for abstraction complexity, and that magic has a high price. I think the comparison falls short, though, because the comparison app itself is too simple. I'm not sure if David was there in 2010 when we were all building web apps with Backbone, but I sure was. Everything starts off great, but eventually you end up with the world's largest ball of twine. React's biggest innovation was bringing one-way data flow to web apps,

which dramatically simplifies the mental model devs have to carry in their brain when building complex apps. I don't love React myself, but I wouldn't go back to Backbone for that reason alone. However, I would, and I do, go back to JQuery-style sites, when all I need is JavaScript Sprinkles, and let's be honest, JavaScript Sprinkles is so often exactly what we need. That's the news for now, but go and subscribe to the ChangeLog newsletter for the full scoop of links worth clicking on, such as, you already have a Git server, how we saved 500K a year by rolling our own S3, and you should feed the bots. Get in on the newsletter at changelog.

Do it. Do it. Last week on the pod, Ellie Huxable joined me to discuss bringing Atouin to the desktop, and Gerhard Lazu took us through all our latest improvements in Kaizen 21. And coming up this week, Adam Jacob from System Initiative on Wednesday, and a spooky special with Adam and yours truly on Friday. Have yourself a great week. Like, subscribe, and five-star review us. If you dig our work, and I'll talk to you again real soon.

Game on