Code Like a Surgeon  ## Metadata - Author: [[Changelog Master Feed]] - Full Title: Code Like a Surgeon - Category: #podcasts - URL: https://share.snipd.com/episode/b89a0e2e-ff34-413c-a9a4-a8c919dbbcec ## Document Notes ## Highlights - **The Dead Internet Theory Is Over** - A study found AI now writes as many web articles as humans, undermining the 'dead internet' myth while revealing high AI misrepresentation in assistants. - Jared declares the dead internet theory dead and highlights that AI assistants misrepresent news about 45% of the time. Transcript: Jared 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/abfefe59-c371-4c37-94b9-f30410e0d300)) - **Code Like A Surgeon** - Jeffrey Litt proposes coding like a surgeon: focus on high-leverage technical work while support handles prep and admin. - The surgeon metaphor scales better now because AI and tooling can provide much of the support once done by humans. Transcript: Jared 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/867cf8b8-0052-4b91-93e8-1e426f5aaf77)) - **Designing UIs In Unexpected Tools** - Matt Sefton recalls seeing designers use Keynote and unusual tools to prototype interfaces rapidly at WWDC and Apple labs. - He highlights a conversation that shifted to spreadsheets as underrated UI design tools. Transcript: Jared 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/24bc4050-0211-4219-8017-840d6b76b654)) - **Prefer Front-End Maximalism — With Caution** - Nate Meyvis recommends minimal backend preprocessing and putting more responsibility in the front end when appropriate. - Jared disagrees with full front-end maximalism and urges careful trade-offs depending on context. Transcript: Jared 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/bdf6a77f-a299-468b-846e-f872854e5916)) - **Treat The 9–5 As Leverage** - Hemant Pandey advises treating a 9-to-5 job as a stable launchpad and use it intentionally for growth and leverage. - He lists five practical ways to approach employment: environment, compounding skills, small side projects, redefine freedom, and use stability as leverage. Transcript: Jared 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. 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. ([Time 0:04:54](https://share.snipd.com/snip/7b8a9a32-f3eb-4d6d-8772-eb8f547bd9db)) - **Framework Progress Is Nuanced** - David Miranda built equivalent password testers in React and Backbone and found little code-length difference, exposing modest progress in frameworks. - Jared argues React's one-way data flow remains a fundamental improvement for complex apps despite Backbone-era simplicity. Transcript: Jared 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/167c8a78-d02a-450b-a381-b8ec1de36ff8))