Code Like a Surgeon  ## Metadata - Author: [[The Changelog: Software Development, Open Source]] - Full Title: Code Like a Surgeon - Category: #podcasts - URL: https://share.snipd.com/episode/db17e115-5865-4537-a113-3db48798b6c4 ## Document Notes ## Highlights - **AI Is Filling The Web And Misrepresenting News** - A new study found AI now writes as many web articles as humans and AI assistants misrepresent news content about 45% of the time. - Jerod declares the "dead internet theory" effectively dead while noting the web's AI-generated content is growing. Transcript: Jerod Santo 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? ([Time 0:00:16](https://share.snipd.com/snip/b7e0fa35-4c28-4d14-b79b-dbc9e2e992c2)) - **Code Like A Surgeon** - Jeffrey Litt proposes developers should "code like a surgeon," focusing on high-impact technical work while delegating support tasks to others or tools. - This model scales better today because automation and AI can provide much of the historical human support behind skilled engineers. Transcript: Jerod Santo 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. Cue 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. B, 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. ([Time 0:00:46](https://share.snipd.com/snip/e7feaa39-f28d-4233-a338-ea4024e29165)) - **Design Prototyping From Keynote To Spreadsheets** - Matt Sefton recounts meeting a designer who used ad-creation software and Keynote to prototype car UI and animations at WWDC. - He highlights a conversation that shifted to using spreadsheets as powerful UI design tools. Transcript: Jerod Santo Here's Matt Sefton. Quote, many years ago, I can't for the very first time. 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. I was 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 GrooveShark'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. ([Time 0:02:12](https://share.snipd.com/snip/1c985d33-cbea-4112-ad99-c45880472d31)) - **Favor Front-End Responsibility Carefully** - Nate Meyvis advocates minimizing back-end preprocessing and pushing logic toward the front end when appropriate. - Jerod cautions this isn't universally correct and points to trade-offs and cases where back-end logic is preferable. Transcript: Jerod Santo 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 to use a front end maximalist approach section Of his post. ([Time 0:03:07](https://share.snipd.com/snip/a39a93ce-477d-4cb9-81fc-86158ad7874b)) - **Use The 9–5 As Leverage** - Hemant Pandey recommends treating a 9-to-5 as a launchpad by finding the right environment and investing in compounding skills. - He advises building small side projects and using job stability as leverage rather than idolizing entrepreneurship. Transcript: Jerod Santo Why the 9-to is underrated. As a guy who hasn't worked a 9-to 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-to employment is actually a great option for many people, so I thought I'd link up this post by Hamant Pandey, which does A good job of it. Quote, the 9-to has been unfairly villainized. We treat it like a cage, but for most people, it's actually the best launchpad 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 nine to five 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. ([Time 0:04:54](https://share.snipd.com/snip/facdb1eb-749a-44c9-99bf-42dce4ed2330)) - **Frameworks Trade Magic For Mental Models** - David Miranda shows a 2010 Backbone implementation and a modern React version doing the same task with similar code length, arguing little progress in simplicity. - Jerod argues React's one-way data flow improved complexity management for large apps, while small sites still benefit from lightweight jQuery-style approaches. Transcript: Jerod Santo 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, 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. ([Time 0:06:11](https://share.snipd.com/snip/7d10f5c0-0bd9-4e48-8d00-d770bfd86a5e))