Podcasts about JavaScript

Netlify's CEO, Matt Biilmann, reveals a seismic shift nobody saw coming: 16,000 daily signups—five times last year's rate—and 96% aren't coming from AI coding tools. They're everyday people accidentally building React apps through ChatGPT, then discovering they need somewhere to deploy them. The addressable market for developer tools just exploded from 17 million JavaScript developers to 3 billion spreadsheet users, but only if your product speaks fluent AI—which is why Netlify's founder now submits pull requests he built entirely through prompting, never touching code himself, and why 25% of users immediately copy error messages to LLMs instead of debugging manually. The web isn't dying to agents; it's being reborn by them, with CEOs coding again and non-developers shipping production apps while the entire economics of software—from perpetual licenses to subscriptions to pure usage—gets rewritten in real-time. Resources:Follow Matt Biilmann on X: https://x.com/biilmannFollow Martin Casado on X: https://x.com/martin_casadoFollow Erik Torenberg on X: https://x.com/eriktorenberg Stay Updated:If you enjoyed this episode, be sure to like, subscribe, and share with your friends!Find a16z on X: https://x.com/a16zFind a16z on LinkedIn: https://www.linkedin.com/company/a16zListen to the a16z Podcast on Spotify: https://open.spotify.com/show/5bC65RDvs3oxnLyqqvkUYXListen to the a16z Podcast on Apple Podcasts: https://podcasts.apple.com/us/podcast/a16z-podcast/id842818711Follow our host: https://x.com/eriktorenbergPlease note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see http://a16z.com/disclosures. Stay Updated:Find a16z on XFind a16z on LinkedInListen to the a16z Show on SpotifyListen to the a16z Show on Apple PodcastsFollow our host: https://twitter.com/eriktorenberg Please note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures. Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

What's coming for Aspire in 2026? Carl and Richard talk to Maddy Montaquila about her work as the product manager for Aspire, the tool that helps you build cloud-native, distributed applications in any language and on any platform. Maddy talks about moving beyond .NET, recognizing that modern applications are written in a number of languages, and the team has focused on ensuring excellent support for Python and JavaScript, as well as the .NET languages. The same is true for the cloud - Azure, AWS, GCP - Aspire works great with them all. And then there's the role of AI, both in building apps with Aspire and building AI into applications. Aspirify today!

A story about users competitors can't stealThis episode is for SaaS founders wondering why their users like the product but don't love it.Second movers usually copy the leader's playbook.Pete Hunt, CEO of Dagster Labs, took a different path. He joined as Head of Engineering in 2022, became CEO ten months later, and inherited a company that was #3 or #4 in a crowded category. Today they're #2 overall—and #1 for greenfield deployments.The difference? Pete built a product with values so clear that choosing it feels like choosing sides.And this inspired me to invite Pete to my podcast. We explore what happens when users choose you for reasons competitors can't copy. Pete shares why being #2 means you have to be 10x more aggressive, why relabeling a version number created an inflection point without changing code, and what broke when his sales forecasts started slipping.You'll discover why the real challenge wasn't preserving his culture—it was changing it.We also zoom in on two of the 10 traits that define remarkable software companies: – Acknowledge you cannot please everyone – Master the art of curiosityPete's journey proves that remarkable companies don't just build tools—they build tribes.Here's one of Pete's quotes that captures his contrarian belief about technical buyers:"These technical folks connect with the values of the product in an emotional way. It's a very powerful thing. People would choose JavaScript frameworks based on their values—something that becomes their identity. People say brand marketing doesn't work on developers. I just think it's completely wrong.By listening to this episode, you'll learn:Why healthy pipeline numbers lieWhy crossing the chasm meant changing culture, not preserving itWhat a version number change did that new features couldn'tWhy sales teams hold onto deals they should killFor more information about the guest from this week: Guest: Pete Hunt, CEO of Dagster LabsWebsite: dagster.io

Your website might rank #1 on Google but be completely invisible to ChatGPT, Claude, and Perplexity. In this episode, let's break down why a huge chunk of the web is fundamentally broken for AI systems - not because of bad content, but because of technical decisions that made sense for humans but make sites invisible to the AI systems rapidly becoming the front door to the internet.Chapter Timestamps00:00:00 - Introduction: The new game your website is losing00:01:43 - The Scale of the Problem: AI crawler traffic explosion00:05:19 - The JavaScript Problem: Why AI crawlers can't see your content00:10:28 - The Bot Protection Paradox: Accidentally blocking AI00:14:40 - The Speed Requirement: Why 200ms matters00:17:46 - AI Agents Are Struggling Too: Browser agents and their limitations00:20:46 - How to Fix It: 6 things you need to do00:25:33 - Closing: The web is adapting againKey Statistics569 million GPTBot requests on Vercel's network in a single month370 million ClaudeBot requests in the same period305% growth in GPTBot traffic (May 2024 to May 2025)157,000% increase in PerplexityBot requests year-over-year33% of organic search activity now comes from AI agents~40% failure rate for the best AI browser agents on complex tasksThe 6 Things to FixImplement Server-Side Rendering (SSR) - If your site uses a JavaScript framework (React, Vue, Angular) with client-side rendering, switch to SSR or static site generation immediately. Use Next.js, Nuxt, or a pre-rendering service.Add Structured Data with JSON-LD - Expose key information in machine-readable format using schema.org markup. Microsoft confirmed Bing uses this to help Copilot understand content.Optimize for Speed - Target server response time under 200ms. First Contentful Paint under 1 second. Largest Contentful Paint under 2.5 seconds.Check Your Bot Protection Settings - Review Cloudflare, AWS WAF, or your CDN's bot management. Make a deliberate decision about GPTBot, ClaudeBot, and PerplexityBot access.Kill Infinite Scroll and Lazy Loading for Content - Use paginated URLs with standard HTML links. Ensure high-value content is in the initial HTML response.Keep Sitemaps Current - Maintain proper redirects, consistent URL patterns, and fix broken links.Tools MentionedGlimpse - Free tool to test how AI sees your website: glimpse.webperformancetools.comShow LinksSources Referenced in This EpisodeAI Crawler Statistics:Vercel Blog - The Rise of the AI CrawlerCloudflare 2025 Year in ReviewCloudflare - From Googlebot to GPTBotSearch Engine Land - AI Optimization GuideJavaScript Rendering:Prerender.io - Understanding Web CrawlersSearch Engine Journal - Enterprise SEO Trends 2026No Hacks is a podcast about web performance, technical SEO, and the agentic web. Hosted by Slobodan "Sani" Manic.

In this episode of The Cybersecurity Defenders Podcast, we discuss some intel being shared in the LimaCharlie community.North Korean threat actors are targeting macOS software developers in a new malware campaign that abuses Visual Studio Code (VS Code) confi gurations to deliver JavaScript-based backdoors, according to research from Jamf.Sinkholes are usually seen as the end of a malicious campaign - the point where domains are seized and abuse stops.China's pen-testing and red-team ecosystem has always been hard to observe, especially since many teams stopped participating in international CTFs post-2018.A critical zero-day vulnerability, CVE-2025-64155, has been discovered in Fortinet's FortiSIEM platform by Horizon3.ai, allowing unauthenticated remote code execution and privilege escalation to root.Support our show by sharing your favorite episodes with a friend, subscribe, give us a rating or leave a comment on your podcast platform.This podcast is brought to you by LimaCharlie, maker of the SecOps Cloud Platform, infrastructure for SecOps where everything is built API first. Scale with confidence as your business grows. Start today for free at limacharlie.io.

Today we have Andrew Northern, Principal Security Researcher at Censys, discussing "From Evasion to Evidence: Exploiting the Funneling Behavior of Injects". This research explains how modern web malware campaigns use multi-stage JavaScript injections, redirects, and fake CAPTCHAs to selectively deliver payloads and evade detection. It shows that these attack chains rely on stable redirect and traffic-distribution chokepoints that can be monitored at scale. Using the SmartApe campaign as a case study, the report demonstrates how defenders can turn those chokepoints into high-confidence detection and tracking opportunities. The research can be found here: From Evasion to Evidence: Exploiting the Funneling Behavior of Injects Learn more about your ad choices. Visit megaphone.fm/adchoices

Today we have Andrew Northern, Principal Security Researcher at Censys, discussing "From Evasion to Evidence: Exploiting the Funneling Behavior of Injects". This research explains how modern web malware campaigns use multi-stage JavaScript injections, redirects, and fake CAPTCHAs to selectively deliver payloads and evade detection. It shows that these attack chains rely on stable redirect and traffic-distribution chokepoints that can be monitored at scale. Using the SmartApe campaign as a case study, the report demonstrates how defenders can turn those chokepoints into high-confidence detection and tracking opportunities. The research can be found here: From Evasion to Evidence: Exploiting the Funneling Behavior of Injects Learn more about your ad choices. Visit megaphone.fm/adchoices

In this episode of React Native Radio, Robin and Mazen are joined by Marc Rousavy to break down transforming packages to Nitro and why it's a big deal for high-performance native modules. They dig into Nitro's origins, how it stacks up against TurboModules and Expo, and what's coming next for VisionCamera. Show NotesNitroModulesChatGPT Nitro Module BuilderMarc's screencast: How to build a Nitro ModuleFrank Calise's Awesome Nitro ModulesRNR 310 - Nitro with Marc RousavyMargelo's Discord Connect With Us!Marc Rousavy: @mrousavyRobin Heinze: @robinheinzeMazen Chami: @mazenchamiReact Native Radio: @ReactNativeRdio This episode is brought to you by Infinite Red!Infinite Red is an expert React Native consultancy located in the USA. With over a decade of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter, core React Native contributors, creators of Ignite and Reactotron, and much, much more), Infinite Red is the best choice for helping you build and deploy your next React Native app.

Package management sits at the foundation of modern software development, quietly powering nearly every software project in the world. Tools like npm and Yarn have long been the core of the JavaScript ecosystem, enabling developers to install, update, and share code with ease. But as projects grow larger and the ecosystem more complex, this older The post Next-Gen JavaScript Package Management with Ruy Adorno and Darcy Clarke appeared first on Software Engineering Daily.

Michael Hladky joins the pod to explain how CSS performance improvements like content-visibility, CSS containment, contain layout, and contain paint can dramatically outperform JavaScript virtual scrolling. The conversation explores virtual scrolling, large DOM performance, and how layout and paint work inside the browser rendering pipeline, including recalculate styles and their impact on INP Interaction to Next Paint. Michael shares real-world examples of frontend performance optimization, discusses cross-browser CSS support including Safari content-visibility, and explains why web performance issues tied to rendering are often misunderstood and overlooked. Links LinkedIn: https://www.linkedin.com/in/michael-hladky-519340148/ GitHub: https://github.com/BioPhoton X: https://x.com/Michael_Hladky Resources Conference link: https://push-based.io/event/perfnow-2025-michael-hladky-zero-js-virtual-scrolling-css Conference resource: https://github.com/push-based/css-contain-and-content-visibility-research We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Fill out our listener survey! https://t.co/oKVAEXipxu Let us know by sending an email to our producer, Elizabeth, at elizabeth.becz@logrocket.com, or tweet at us at PodRocketPod. Check out our newsletter! https://blog.logrocket.com/the-replay-newsletter/ Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form, and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it for free at LogRocket.com. Try LogRocket for free today. Chapters 00:00 Introduction to CSS Performance and Virtual Scrolling 01:20 Why Interaction to Next Paint (INP) Changed Everything 03:00 The Real Cost of Layout and Paint 05:10 Why Large DOMs Break Performance 06:45 How CSS Containment Works 08:30 Contain Layout vs Contain Paint Explained 10:40 When Containment Breaks Your UI 12:20 Introducing Content Visibility 14:10 CSS Content Visibility vs JavaScript Virtual Scrolling 16:40 Why CSS Skips Recalculate Styles Entirely 18:50 Real Performance Gains on Desktop and Mobile 20:40 Cross-Browser Support Including Safari 22:10 Common Pitfalls and Flickering Issues 24:10 How to Measure Layout and Paint Performance 26:10 Why Frameworks Should Use This by Default 28:00 Design Systems and Low-Hanging Performance Wins 30:10 The Biggest CSS Performance Misconception 32:00 Final Takeaways on Frontend Performance

I want to build a cross-platform application. Should I just build a PWA or do I need to build a native app? Is it better to use Swift and Java or could I use C# or JavaScript? These are the questions we will answer in today's episode of Dev Questions.Website: https://www.iamtimcorey.com/ Ask Your Question: https://suggestions.iamtimcorey.com/ Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

15 years too late but it's finally here: server-side logic in Power Pages. What does it change in practice? Unlike Azure Functions, it's just another Power Pages asset that can be added to Power Platform ALM. Perfect for anything that is logic-lite/secret-heavy. Think payments and integrations that need secrets. Server-side logic avoids awkward workarounds using plugins, Power Automate, etc. just to keep keys safe. Re-use your Javascript skills though it's not lift-n-shift from the client-side exercise. Just couple new objects to learn: HTTP client for external calls and a Dataverse object for CRUD operations. There are plenty of scenarios where client-side Web API is better, like interaction with external services requiring callbacks, for example. As Nick succulently summed it up: It doesn't make anything possible we couldn't do before. It just makes doing a lot of things we did do before a lot easier. References Power Pages server logic overview (preview) | Microsoft Learn Get in touch voice@crm.audio Nick Hayduk @Engineered_Code George Doubinski @georgedude

Rewrites are seductive. Clean slates promise clarity, speed, and “doing it right this time.” In practice, they're often late, over budget, and quietly demoralizing.In this episode of Maintainable, Robby sits down with Brittany Ellich, a Senior Software Engineer at GitHub, to talk about a different path. One rooted in stewardship, readability, and resisting the urge to start over.Brittany's career began with a long string of rebuild projects. Over time, she noticed a pattern. The estimates were wrong. Feature development stalled. Teams burned energy reaching parity with systems they'd already had. That experience pushed her toward a strong belief: if software is in production and serving users, it's usually worth maintaining.[00:00:57] What well-maintained software actually looks likeFor Brittany, readability is the first signal. If code can't be understood, it can't be changed safely. Maintenance begins with making systems approachable for the next person.[00:01:42] Rethinking technical debtShe explains how her understanding of technical debt has evolved. Rather than a fixed category of work, it's often anything that doesn't map directly to new features. Bugs, reliability issues, and long-term risks frequently get lumped together, making prioritization harder than it needs to be.[00:05:49] Why AI changes the maintenance equationBrittany describes how coding agents have made it easier to tackle small, previously ignored maintenance tasks. Instead of waiting for debt to accumulate into massive projects, teams can chip away incrementally. (Related: GitHub Copilot and the Copilot coding agent workflow she's explored.)[00:07:16] Context from GitHub's billing systemsWorking on metered billing at GitHub means correctness and reliability matter more than flash. Billing should be boring. When it's not, customers notice quickly.[00:11:43] Navigating a multi-era codebaseGitHub's original Rails codebase is still in active use. Brittany relies heavily on Git blame and old pull requests to understand why decisions were made, treating them as a form of living documentation.[00:25:27] Treating coding agents like teammatesRather than delegating massive changes, Brittany assigns agents small, well-scoped tasks. She approaches them the same way she would a new engineer: clear instructions, limited scope, and careful review.[00:36:00] Structuring the day to avoid cognitive overloadShe breaks agent interaction into focused windows, checking in a few times a day instead of constantly monitoring progress. This keeps deep work intact while still moving maintenance forward.[00:40:24] Low-risk ways to experimentImproving test coverage and generating repository instructions are safe entry points. These changes add value without risking production behavior.[00:54:10] Navigating team resistance and ethicsBrittany acknowledges skepticism around AI and encourages teams to start with existing backlog problems rather than selling AI as a feature factory.[00:57:57] Books, habits, and staying balancedOutside of software, Brittany recommends Atomic Habits by James Clear, sharing how small routines help her stay focused.The takeaway is clear. AI doesn't replace engineering judgment. Used thoughtfully, it can support the unglamorous work that keeps software alive.Good software doesn't need a rewrite.It needs caretakers.References MentionedGitHub – Brittany's current role and the primary environment discussedGitHub Universe – Where Brittany presented her coding agent workflowAtomic Habits by James Clear – Brittany's recommended book outside of techOvercommitted - Podcast Brittany co-hostsThe Balanced Engineer Newsletter – Brittany's monthly newsletter on engineering, leadership, and balanceBrittany Ellich's website – Central hub for her writing and linksGitHub Copilot – The AI tooling discussed throughout the episodeHow the GitHub billing team uses the coding agent in GitHub Copilot to continuously burn down technical debt – GitHub blog post referencedThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.Keep your coding cool and error-free, one line at a time! Use the code maintainable to get a 10% discount for your first year. Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

In this episode of PodRocket, Daniel Thompson--Yvetot joins us to break down what's new in Tauri 2.0 and how developers are using the Tauri framework to build desktop and mobile apps with Rust and JavaScript. We discuss how Tauri lets developers use frameworks like React, Vue, and Angular for the UI while handling heavy logic in Rust, resulting in smaller app binaries and better performance than Electron alternatives. The conversation covers Create Tauri App for faster onboarding, the new plugin system for controlling file system and OS access, and how Tauri improves app security by reducing attack surfaces. They also dive into mobile app development, differences between system WebViews, experiments with Chromium Embedded Framework, and why cross platform apps still need platform-specific thinking. Daniel also shares what's coming next for Tauri, including flexibility in webviews, accessibility tooling, compliance requirements in Europe, and the roadmap toward Tauri 3.0. Links Tauri: https://v2.tauri.app LinkedIn: https://www.linkedin.com/in/denjell We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Fill out our listener survey (https://t.co/oKVAEXipxu)! https://t.co/oKVAEXipxu Let us know by sending an email to our producer, Elizabeth, at elizabeth.becz@logrocket.com (mailto:elizabeth.becz@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Check out our newsletter (https://blog.logrocket.com/the-replay-newsletter/)! https://blog.logrocket.com/the-replay-newsletter/ Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it for free at LogRocket.com. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Chapters Special Guest: Daniel Thompson-Yvetot.

In this episode I talk with Sean Schertell about his return to Rails after many years in JavaScript, the pain of node module hell, Kamal for deployment, and Sean's new startup ZiaMap for land surveyors.Links:CodepilotZiaMapNonsense Monthly

LLMs have made it absurdly easy to go deep on almost any topic. So why haven't we all used ChatGPT to earn college degrees we wished we had majored in or pursued a niche interest, like learning how to name the trees in our neighborhood? I know I'm not the only one to feel guilty for well-intentioned attempts at autodidactism that inevitably peter out.Entrepreneur Nir Zicherman has a reason for this disconnect: LLMs can answer most of your questions, but they won't notice when you're lost or pull you back in when your motivation starts to fade.As the CEO and cofounder of Oboe, a platform that generates personalized courses about everything from the history of snowboarding to JavaScript fundamentals using AI, Zicherman has thought deeply about why the ability to access information does not automatically lead to understanding a concept. In this episode of AI & I, he talks to Dan Shipper about everything he's learned about learning with LLMs.They get into Zicherman's counterintuitive belief that learning is a more passive process than you'd think, the biggest blocker for most people who want to learn something new, and where AI agents currently fall short in providing a meaningful learning experience.If you found this episode interesting, please like, subscribe, comment, and share!Want even more?Sign up for Every to unlock our ultimate guide to prompting ChatGPT here: https://every.ck.page/ultimate-guide-to-prompting-chatgpt. It's usually only for paying subscribers, but you can get it here for free.To hear more from Dan Shipper:Subscribe to Every: https://every.to/subscribeFollow him on X: https://twitter.com/danshipperTimestamps:00:00:00 - Start00:00:36 - Introduction00:01:49 - Why you need a dedicated AI learning app00:04:32 - The process of learning is more passive than you might think00:10:21 - Live demo of Oboe to create a course about philosopher Ludwig Wittgenstein00:16:52 - Learning works best when it comes in many formats00:28:21 - Where AI agents currently fall short in the learning experience00:34:10 - The importance of making learning feel accessible00:35:56 - How Zicherman uses Oboe to learn quantum physics00:40:54 - How embeddings spaces remind Dan of quantum mechanicsLinks to resources mentioned in the episode:Nir Zicherman: @NirZichermanLearn something new with Oboe: https://oboe.com/

An airhacks.fm conversation with Thomas Wuerthinger (@thomaswue) about: clarification of GraalVM release cadence changes and decoupling from openJDK releases, GraalVM focusing on LTS Java releases only (skipping non-LTS like Java 26), GraalVM as a multi-vendor polyglot project with community edition and third-party vendors like Red Hat BellSoft and microdoc, increased focus on python support due to AI popularity, GraalVM team alignment with Oracle Database organization, Oracle Multilingual Engine (MLE) for running JavaScript and Python in Oracle Database, MySQL MLE integration, native image support for stored procedures in Oracle Database, shipping lambda functions from client applications to database for temporary execution, treating Oracle Database as an operating system for running business logic, serverless workloads directly in Oracle Database, application snapshotting similar to CRaC but running in user space without kernel privileges, efficient scale-to-zero capabilities with native images, Oracle REST Data Services service generalization for serverless execution platform, database triggers for workflow systems and application wake-up, durable functions with transactional state storage in Oracle Database, comparison to AS400 architecture with transaction manager database and operating system in same memory, memory price increases making GraalVM native image more attractive, lower memory consumption benefits of native image beyond just startup time, CPU-based inference support with SIMD and Vector API, TornadoVM for GPU-based inference built on Graal compiler, WebAssembly compilation target for native images, edge function deployment with WebAssembly, Intel memory protection keys for sandboxed native image execution, native image layers for shared base libraries similar to docker layers, profile-guided optimizations for size reduction, upx binary compression for 3x size reduction, memory savings from eliminated class metadata and profiling data not garbage collector differences, 32-bit object headers in serial GC smaller than HotSpot, polyglot integration allowing Python and JavaScript embedding in Java applications, Micronaut framework compile-time annotation processing, quarkus framework best alignment with native image for smallest binaries, GraalVM roadmap focused on database synergies and serverless innovation Thomas Wuerthinger on twitter: @thomaswue

Topics covered in this episode: ty: An extremely fast Python type checker and LSP Python Supply Chain Security Made Easy typing_extensions MI6 chief: We'll be as fluent in Python as we are in Russian Extras Joke Watch on YouTube About the show Connect with the hosts Michael: @mkennedy@fosstodon.org / @mkennedy.codes (bsky) Brian: @brianokken@fosstodon.org / @brianokken.bsky.social Show: @pythonbytes@fosstodon.org / @pythonbytes.fm (bsky) Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Monday at 10am PT. Older video versions available there too. Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it. Brian #1: ty: An extremely fast Python type checker and LSP Charlie Marsh announced the Beta release of ty on Dec 16 “designed as an alternative to tools like mypy, Pyright, and Pylance.” Extremely fast even from first run Successive runs are incremental, only rerunning necessary computations as a user edits a file or function. This allows live updates. Includes nice visual diagnostics much like color enhanced tracebacks Extensive configuration control Nice for if you want to gradually fix warnings from ty for a project Also released a nice VSCode (or Cursor) extension Check the docs. There are lots of features. Also a note about disabling the default language server (or disabling ty's language server) so you don't have 2 running Michael #2: Python Supply Chain Security Made Easy We know about supply chain security issues, but what can you do? Typosquatting (not great) Github/PyPI account take-overs (very bad) Enter pip-audit. Run it in two ways: Against your installed dependencies in current venv As a proper unit test (so when running pytest or CI/CD). Let others find out first, wait a week on all dependency updates: uv pip compile requirements.piptools --upgrade --output-file requirements.txt --exclude-newer "1 week" Follow up article: DevOps Python Supply Chain Security Create a dedicated Docker image for testing dependencies with pip-audit in isolation before installing them into your venv. Run pip-compile / uv lock --upgrade to generate the new lock file Test in a ephemeral pip-audit optimized Docker container Only then if things pass, uv pip install / uv sync Add a dedicated Docker image build step that fails the docker build step if a vulnerable package is found. Brian #3: typing_extensions Kind of a followup on the deprecation warning topic we were talking about in December. prioinv on Mastodon notified us that the project typing-extensions includes it as part of the backport set. The warnings.deprecated decorator is new to Python 3.13, but with typing-extensions, you can use it in previous versions. But typing_extesions is way cooler than just that. The module serves 2 purposes: Enable use of new type system features on older Python versions. Enable experimentation with type system features proposed in new PEPs before they are accepted and added to the typing module. So cool. There's a lot of features here. I'm hoping it allows someone to use the latest typing syntax across multiple Python versions. I'm “tentatively” excited. But I'm bracing for someone to tell me why it's not a silver bullet. Michael #4: MI6 chief: We'll be as fluent in Python as we are in Russian "Advances in artificial intelligence, biotechnology and quantum computing are not only revolutionizing economies but rewriting the reality of conflict, as they 'converge' to create science fiction-like tools,” said new MI6 chief Blaise Metreweli. She focused mainly on threats from Russia, the country is "testing us in the grey zone with tactics that are just below the threshold of war.” This demands what she called "mastery of technology" across the service, with officers required to become "as comfortable with lines of code as we are with human sources, as fluent in Python as we are in multiple other languages." Recruitment will target linguists, data scientists, engineers, and technologists alike. Extras Brian: Next chapter of Lean TDD being released today, Finding Waste in TDD Still going to attempt a Jan 31 deadline for first draft of book. That really doesn't seem like enough time, but I'm optimistic. SteamDeck is not helping me find time to write But I very much appreciate the gift from my fam Send me game suggestions on Mastodon or Bluesky. I'd love to hear what you all are playing. Michael: Astral has announced the Beta release of ty, which they say they are "ready to recommend to motivated users for production use." Blog post Release page Reuven Lerner has a video series on Pandas 3 Joke: Error Handling in the age of AI Play on the inversion of JavaScript the Good Parts

Introducing Rob Ruiz Meet Rob Ruiz, a seasoned Senior Full Stack Developer with nearly two decades of expertise in WordPress innovation and open-source magic. As the Lead Maintainer of WP Rig since 2020, Rob has been the driving force behind this groundbreaking open-source framework that empowers developers to craft high-performance, accessible, and progressively enhanced WordPress themes with ease. WP Rig isn’t just a starter theme—it’s a turbocharged toolkit that bundles modern build processes, linting, optimization, and testing to deliver lightning-fast, standards-compliant sites that shine on any device. Show Notes For more on Rob and WP Rig, check out these links: LinkedIn Profile: https://www.linkedin.com/in/robcruiz WP Rig Official Site: https://wprig.io GitHub Repository: https://github.com/wprig/wprig Latest Releases: https://github.com/wprig/wprig/releases WP Rig 3.1 Announcement: https://wprig.io/wp-rig-3-1/ Transcript: Topher DeRosia: Hey everybody. Welcome to Hallway Chats. I’m your host Topher DeRosia, and with me today I have- Rob Ruiz: Rob Ruiz. Topher: Rob. You and I have talked a couple of times, once recently, and I learned about a project you’re working on, but not a whole lot about you. Where do you live? What do you do for a living? Rob: Yeah, for sure. Good question. Although I’m originally from Orlando, Florida, I’ve been living in Omaha, Nebraska for a couple of decades now. So I’m pretty much a native. I know a lot of people around here and I’ve been fairly involved in various local communities over the years. I’m a web developer. Started off as a graphic designer kind of out of college, and then got interested in web stuff. And so as a graphic designer turned future web developer, I guess, I was very interested in content management systems because it made the creating and managing of websites very, very easy. My first couple of sites were Flash websites, sites with macro media Flash. Then once I found content management systems, I was like, “Wow, this is way easier than coding the whole thing from scratch with Flash.” And then all the other obvious benefits that come from that. So I originally started with Joomla, interestingly enough, and used Joomla for about two or three years, then found WordPress and never looked back. And so I’ve been using WordPress ever since. As the years have gone on, WordPress has enabled me to slowly transition from a more kind of web designer, I guess, to a very full-blown web developer and software engineer, and even software architect to some degree. So here we are many years later. Topher: There’s a big step from designer to developer. How did that go for you? I’m assuming you went to PHP. Although if you were doing Flash sites, you probably learned ActionScript. Rob: Yeah. Yeah. That was very convenient when I started learning JavaScript. It made it very easy to learn JavaScript faster because I already had a familiarity with ActionScript. So there’s a lot of similarities there. But yeah. Even before I started doing PHP, I started learning more HTML and CSS. I did do a couple of static websites between there that were just like no content management system at all. So I was able to kind of sharpen my sword there with the CSS and HTML, which wasn’t particularly hard. But yeah, definitely, the PHP… that was a big step was PHP because it’s a proper logical programming language. There was a lot there I needed to unpack, and so it took me a while. I had to stick to it and really rinse and repeat before I finally got my feet under me. Topher: I can imagine. All right. So then you work for yourself or you freelance or do you have a real job, as it were? Rob: Currently, I do have a real job. Currently, I’m working at a company called Bold Orange out of Minneapolis. They’re a web agency. But I kind of bounce around from a lot of different jobs. And then, yes, I do freelance on the side, and I also develop my own products as well for myself and my company. Topher: Cool. Bold Orange sounds familiar. Who owns that? Rob: To be honest, I don’t know who the owners are. It’s just a pretty big web agency out of Minneapolis. They are a big company. You could just look them up at boldorange.com. They work for some pretty big companies. Topher: Cool. All right. You and I talked last about WP Rig. Give me a little background on where that came from and how you got it. Rob: Yeah, for sure. Well, there was a period of time where I was working at a company called Proxy Bid that is in the auction industry, and they had a product or a service — I don’t know how you want to look at that —called Auction Services. That product is basically just building WordPress sites for auction companies. They tasked us with a way to kind of standardize those websites essentially. And what we realized is that picking a different theme for every single site made things difficult to manage and increase tech debt by a lot. So what we were tasked with was, okay, if we’re going to build our own theme that we’re just going to make highly dynamic so we can make it look different from site to site. So we want to build it, but we want to build it smart and we want to make it reusable and maintainable. So let’s find a good framework to build this on so that we can maintain coding standards and end up with as little tech debt as possible, essentially. That’s when I first discovered WP Rig. In my research, I came across it and others. We came across Roots Sage and some of the other big names, I guess. It was actually a team exercise. We all went out and looked for different ones and studied different ones and mine that I found was WP Rig. And I was extremely interested in that one over the other ones. Interestingly enough- Topher: Can you tell me why over the other ones? Rob: That’s a great question. Yeah. I really liked the design patterns. I really liked the focus on WordPress coding standards. So having a system built in that checked all the code against WordPress coding standards was cool. I loved the compiling transpiling, whatever, for CSS and JavaScript kind of built in. That sounded really, really interesting. The fact that there was PHP unit testing built into it. So there’s like a starter testing framework built in that’s easy to extend so that you can add additional unit tests as your theme grows. We really wanted to make sure… because we were very into CICD pipelines. So we wanted to make sure that as developers were adding or contributing to any themes that we built with this, that we could have automated tests run and automated builds run, and just automate as much as possible. So WP rig just seemed like something that gave us those capabilities right out of the box. So that was a big thing. And I loved the way that they did it. Roots Sage does something similar, but they use their blade templating engine built in there. We really wanted to stick to something that was a bit more standard WordPress so that there wasn’t like a large knowledge overhead so that we didn’t have to say like, okay, if we’re bringing on other developers, like junior developers work on it, oh, it would be nice if you use Laravel too because we use this templating engine in all of our themes. We didn’t want to have to worry about that essentially. It was all object-oriented and all that stuff too. That’s what looked interesting to me. We ended up building a theme with WP Rig. I don’t know what they ended up doing with it after that, because I ended up getting let go shortly thereafter because the company had recently been acquired. Also, this was right after COVID too. So there was just a lot of moving parts and changing things at the time. So I ended up getting let go. But literally a week after I got let go, I came across a post on WP Tavern about how this framework was looking for new maintainers. Basically, this was a call put out by Morton, the original author of WP Rig. He reached out to WP Tavern and said, “Look, we’re not interested in maintaining this thing anymore, but it’s pretty cool. We like what we’ve built. And so we’re looking for other people to come in and adopt it essentially.” So I joined a Zoom meeting with a handful of other individuals that were also interested in this whole endeavor, and Morton reached out to me after the call and basically just said, “I looked you up. I liked some of the input that you had during the meeting. Let’s talk a little bit more.” And then that eventually led to conversations about me essentially taking the whole project over entirely. So, the branding, the hosting of the website, being lead maintainer on the project. Basically, gave me the keys to the kingdom in terms of GitHub and everything. So that’s how it ended up going in terms of the handoff between Morton and I. And I’m very grateful to him. They really created something super cool and I was honored to take it over and kind of, I don’t know, keep it going, I guess. Topher: I would be really curious. I don’t think either of us have the answer. I’d be curious to know how similar that path is to other project handoffs. It’s different from like an acquisition. You didn’t buy a plugin from somebody. It was kind of like vibes, I guess. Rob: It was like vibes. It was very vibey. I guess that’s probably the case in an open source situation. It’s very much an open source project. It’s a community-driven thing. It’s for everybody by everybody. I don’t know if all open source community projects roll like that, but that’s how this one worked out. There was some amount of ownership on Morton’s behalf. He did hire somebody to do the branding for WP Rig and the logo. And then obviously he was paying for stuff like the WPrig.io domain and the hosting through SiteGround and so on and so forth. So, we did have to transfer some of that and I’ve taken over those, I guess, financial burdens, if you want to think of it like that. But I’m totally okay with it. Topher: All right. You sort of mentioned some of the things Rig does, compiling and all that kind of stuff. Can you tell me… we didn’t discuss this before. I’m sitting at my desk and I think I want a website. How long does it take to go from that to looking at WordPress and logging into the admin with Rig? Rob: Okay. Rig is not an environment management system like local- Topher: I’m realizing my mistake. Somebody sends me a design in Figma. How long does it take me to go from that to, I’m not going to say complete because I mean, that’s CSS, but you know, how long does it take me to get to the point where I’m looking at a theme that is mine for the client that I’m going to start converting? Rob: Well, if you’re just looking for a starting point, if you’re just like, okay, how long does it take to get to like, okay, here’s my blank slate and I’m ready to start adopting all of these rules that are set up in Figma or whatever, I mean, you’re looking at maybe 5 minutes, 10 minutes, something like that. It’s pretty automated. You just need some simple knowledge of Git. And then there are some prerequisites to using WP Rig. You do have to have composer installed because we do leverage some Composer packages to some of it, although to be honest, you could probably get away with not using Composer. You just have to be okay with sacrificing some of the tools the WP Rig assumes you’re going to have. And then obviously Node. You have to have Node installed. A lot of our documentation assumes that you have NPM, that you’re using NPM for all your Nodes or your package management. But we did recently introduce support for Bun. And so you can use Bun instead of NPM, which is actually a lot faster and better in many ways. Topher: Okay. A lot of my audience are not developers, users, or light developers, like they’ll download a theme, hack a template, whatever. Is this for them? Am I boring those people right now? Rob: That’s a great question. I mean, and I think this is an interesting dichotomy and paradigm in the WordPress ecosystem, because you’ve got kind of this great divide. At least this is something I’ve noticed in my years in the WordPress community is you have many people that are not coders or developers that are very interested in expanding their knowledge of WordPress, but it’s strictly from a more of a marketing perspective where it’s like, I just want to know how to build websites with WordPress and how to use it to achieve my goals online from a marketing standpoint. You have that group of people, and then you have this other group of people that are very developer centric that want to know how to extend WordPress and how to empower those other people that we just discussed. Right? Topher: Right. Rob: So, yeah, that’s a very good question. I would say that WP Rig is very much designed for the developers, not for the marketers. The assumption there is that you’re going to be doing some amount of coding. Now, can you get away with doing a very light amount of coding? Yes. Yes, you can. I mean, if you compare what you’re going to get out of that assumed workflow to something that you would get off like Theme Forest or whatever, it’s going to be a night and day difference because those theme, Forest Themes, have hours, hundreds, sometimes hundreds of hours of development put into them. So, you’re not going to just out of the box immediately get something that is comparable to that. Topher: You need to put in those hundreds of hours of development to make a theme. Rob: As of today, yes. That may change soon though. Topher: Watch this space. Rob: That’s all I’ll say. Topher: Okay. So now we know who it’s for. I’m assuming there’s a website for it. What is it? Rob: Yeah. If you go to WPrig.io, we have a homepage that shows you all the features that are there in WP Rig. And then there’s a whole documentation area that helps people get up and running with WP Rig because there is a small learning curve there that’s pretty palatable for anybody who’s familiar with modern development workflows. So that is a thing. So the type of person that this is designed for anybody that wants to make a theme for anything. Let’s say you’re a big agency and you pull in a big client and that client wants something extremely custom and they come to you with Figma designs. Sure, you could go out there and find some premium theme and try to like child theme and overhaul that if you want. But in many situations, I would say in most situations, if you’re working from a Figma design that’s not based off of another theme already that’s just kind of somebody else’s brainchild, then you’re probably going to want to start from scratch. And so the idea here is that this is something to replace an approach, like underscores an approach. Actually, WP Pig was based off of underscores. The whole concept of it, as Morton explained it to me, was that he wanted to build an underscores that was more modern and full-featured from a development standpoint. Topher: Does it have any opinions about Gutenberg? Rob: It does now, but it did not when I took it over because Gutenberg did not exist yet when I took over WP Rig. Topher: Okay. What are its opinions? Rob: Yeah, sure. The opinion right out of the gate is that you can use Gutenberg as an editor and it has support like CSS rules in it for the standard blocks. So you should be able to use regular Gutenberg blocks in your theme and they should look just fine. There’s no resets in there. It doesn’t start from scratch. There’s not a bunch of styling you have to do for the blocks necessarily. Now, if you go to the full site editing or block-based mentality here, there are some things you need to do in WP Rig to convert the out-of-the-box WP Rig into another paradigm essentially. Right when you pull WP Rig, the assumption is you’re building what most people would refer to as a hybrid theme. The theme supports API or whatever, and the assumption is that you’re not going to be using the site editor. You’re just going to kind of do traditional WordPress, but you might be using Gutenberg for your content. So you’re just using Gutenberg kind of to author your pages and your posts and stuff like that, but not necessarily the whole site. WP Rig has the ability to kind of transform itself into other paradigms. So the first paradigm we built out was the universal theme approach. And the idea there is that you get a combination of the full site editing capabilities. But then you also have the traditional menu manager and the settings customizer framework or whatever is still there, right? These are things that don’t exist in a standard block-based theme. So I guess an easy example would be like the 2025 WordPress theme that comes right out of the box. It comes installed in WordPress. That is a true block-based theme, not a universal theme. So it doesn’t have those features because the assumption there is that it doesn’t need those features. You can kind of transform WP Rig into a universal theme that’s kind of a hybrid between a block-based and a classic theme. And then it can also transform into a strictly block-based theme as well. So following the same architecture as like the WordPress 2025 theme or Ollie or something like that is also a true block-based theme as well. So you can easily convert or transform the starting point of WP Rig into either of those paradigms if that’s the type of theme you’re setting out to build. Topher: Okay. That sounds super flexible. How much work is it to do that? Rob: It’s like one command line. Previously we had some tutorials on the website that showed you step-by-step, like what you needed to change about the theme to do that. You would have to add some files, delete some files, edit some code, add some theme supports into the base support class and some other stuff. I have recently, as of like a year and a half ago or a year ago, created a command line or a command that you can type into the command line that basically does that entire conversion process for you in like the blink of an eye. It takes probably a second to a second and a half to perform those changes to the code and then you’re good to go. It is best to do that conversion before you start building out your whole theme. It’s not impossible to do it after. But you’re more likely to run into problems or conflicts if you’ve already set out building your whole theme under one paradigm, and then you decide how the project you want to switch over to block-based or whatever. You’re likely to run into the need to refactor a bunch of stuff in that situation. So it is ideal to make that choice extremely early on in the process of developing your theme. But either way it’ll still work. That’s just one of the many tools that exist in WP Rig to transform it or convert it in several ways. That’s just one example. There are other examples of ways that Rig kind of converts itself to other paradigms as well. Topher: Yeah. All right. In my development life, I’ve had two parts to it. And one is the weekend hobbyist, or I download cadence and I whip something up in 20 minutes because I just want to experiment and the other is agency life where everything’s in Git, things are compiled, there are versions, blah, blah, blah. This sounds very friendly to that more professional pathway. Rob: Absolutely. Yes. Or, I mean, there’s another situation here too. If you’re a company who develops themes and publishes them to a platform like ThemeForest or any other platform, perhaps you’re selling themes on your own website, whatever, if you’re making things for sale, there’s no reason you couldn’t use WP Rig to build your themes. We have a bundle process that bundles your theme for publication or publishing. Whether you’re an agency or whether you’re putting your theme out for sale, it doesn’t matter, during that bundle process, it does actually white label the entire code base to where there’s no mention of WP Rig in the code whatsoever. Let’s say you were to build a theme that you wanted to put up for sale because you have some cool ideas. Say, page transitions now are completely supported in all modern or in most modern browsers. And when I say print page transitions, for those that are in the know, I am talking about not single page app page transitions, but through website page transitions. You can now do that. Let’s say you were like, “Hey, I’m feeling ambitious and I want to put out some new theme that comes with these page transitions built in,” and that’s going to be fancy on ThemeForest when people look at my demo, people might want to buy that. You could totally use WP Rig to build that out into a theme and the bundle process will white label all of the code. And then when people buy your theme and download that code, if they’re starting to go through and look through your code, they’re not going to have any way of knowing that it was built with WP Rig unless they’re familiar with the base WP Rig architecture, like how it does its object-oriented programming. It might be familiar with the patterns that it’s using and be able to kind of discern like, okay, well, this is the same pattern WP Rig uses, so high likelihood it was built with WP Rig. But they’re not going to be able to know by reading through the code. It’s not going to say WP Rig everywhere. It’s going to have the theme all over the place in the code. Topher: Okay. So then is that still WP Rig code? It just changed its labels? Rob: Yeah. Topher: So, it’s not like you’re exporting HTML, CSS and JavaScript? The underlying Rig framework is still there. Rob: Yeah. During the bundle process, it is bundling CSS and HTML. Well, HTML in the case of a block-based theme. But, yeah, it is bundling your PHP, your CSS, your JavaScript into the theme that you’re going to let people download when they buy it, or that you’re going to ship to your whatever client’s website. But all that code is going to be transpiled. In the case of CSS and JavaScript, there’s only going to be minified versions of that code in that theme. The source code is not actually going to be in there. Topher: This sounds pretty cool. You mentioned some stuff might be coming. You don’t have to tell me what it is, but do you have a timeline? When should we be watching for the next cool thing from Rig? Rob: Okay, cool. Well, I’m going to keep iterating on Rig forever. Regardless of any future products that might be built on WP Rig, WP Rig will always and forever remain an open source product for anybody to use for free and we, I, and possibly others in the future will continue to update it and support it over time. We just recently put out 3.1. You could expect the 3.2 anytime in the next six months to a year, probably closer to six months. One feature I’m looking at particularly closely right now is the new stuff coming out in version 6.9 of WordPress around the various APIs that are there. I think one of them is called the form… There’s a field API and a form API or view API or something like that. So WP Rig comes with a React-based settings framework in it. So if you want your theme to have a bunch of settings in it to make it flexible for whoever buys your theme, you can use this settings framework to easily create a bunch of fields, and then that framework will automatically manage all your fields and store all the data from those fields and make it easy to retrieve the values of the input on those fields, without knowing any React at all. Now, if you know React, you can go in there and, you know, embellish what’s already there, but it takes a JSON approach. So if you just understand JSON, you can go in and change the JSON for the framework, and that will automatically add fields into the settings framework. So you don’t even have to know React to extend the settings page if you want. That will likely get an overhaul using these new APIs being introduced into Rig. Topher: All right. How often have you run into something where, “Oh, look, WordPress has a new feature, I need to rebuild my system”? Rob: Over the last four or five years, it’s happened a lot because, yeah, I mean, like I said, when I first took this thing over, Gutenberg had not even been introduced yet. So, you had the introduction of Gutenberg and blocks. That was one thing. Then this whole full site editing became a thing, which later became the site editor. So that became a whole thing. Then all these various APIs. I mean, it happens quite frequently. So I’ve been working to keep it modern and up to date over the past four years and it’s been an incredible learning experience. It not only keeps my WordPress knowledge extremely sharp, but I’ve also learned how various other toolkits are built. That’s been the interesting thing. From a development standpoint, there’s two challenges here. One of the challenges is staying modern on the WordPress side of things. For instance, WordPress coding standards came out with a version 3 and then a version 3.1 about two years ago. I had to update WP Rig to leverage those modern coding standards. So that’s one example is as WordPress changes, the code in WP Rig also needs to change. Or for instance, if new CSS standards change, right, new CSS properties come out, it is ideal for the base CSS in WP Rig, meaning the CSS that you get right out of the box with it, comes with some of these, for instance, CSS grid, Flexbox, stuff like that. If I was adopting a theme framework to build a theme on, I would expect some of that stuff to be in there. And those things were extremely new when I first took over WP Rig and were not all baked in there essentially. So I’ve had to add a lot of that over time. Now there’s another side to this, which is not just keeping up with WordPress and CSS and PHP, 8. whatever, yada yada yada. You’ve also got the toolkit. There are various node packages and composer packages of power WP Rig and the process in which it does the transpiling, the bundling, the automated manipulation of your code during various aspects of the usage of WP Rig is a whole nother set of challenges because now you have to learn concepts like, well, how do I write custom node scripts? Right? Like there were no WP CLI commands built into WP Rig when I first took it over. Now there’s a whole list. There’s a whole library of WP CLI commands that come in Rig right out of the gate. And so I’ve had to learn about that. So just various things that come with knowing how do you automate the process of converting code, that’s something that was completely foreign to me when I first took over WP Rig. That’s been another incredible learning experience is understanding like what’s the difference between Webpack and Gulp. I didn’t know, right? I would tell people I’m using Gulp and WP Rig and they would be like, “Well, why don’t you just use Webpack?” and I would say, “I don’t know. I don’t know what the difference is.” So over time I could figure out what are the differences? Why aren’t we using Webpack? And I’m glad I spent some time on that because it turns out Webpack is not the hottest thing anymore, so I just skipped right over all that. When I overhauled for version 3, we’re now not using Gulp anymore as of 3.1. We’re now using more of a Vite-like process, far more modern than Webpack and far better and faster and sleeker and lighter. I had to learn a bunch about what powers Vite. What is Vite doing under the hood that we might be able to also do in WP Rig, but do it in a WordPress way. Because Vite is a SaaS tool. If you’re building a SaaS, like React with a… we’re not a SaaS. I guess a spa is a better term to use here. If you’re building a single page application with React or view or belt or whatever, right, then knowing what Vite is and just using Vite right out of the box is perfect. But it doesn’t translate perfectly to WordPress land because WordPress has its own opinions. And so I did have to do some dissecting there and figure out what to keep and what to not keep to what to kind of set aside so that WordPress can keep doing what WordPress does the way WordPress likes to do it, but also improve on how we’re doing some of the compiling and transpiling and the manipulation of the code during these various. Topher: All right. I want to pivot a little bit to some personal-ish questions. Rob: Okay. Topher: This is a big project. I’m sure it takes up plenty of your time. How scalable is that in your life? Do you want to do this for the rest of your life? Rob: That’s a fantastic question. I don’t know about the rest of my life. I mean, I definitely want to do web development for the rest of my life because the web has, let’s be honest, it’s transformed everyone’s way of life, whether you’re a web developer or not. You know, the fact that we have the internet in our pocket now, you know, it has changed everything. Apps, everything. It’s all built on the web. So I certainly want to be involved in the web the rest of my life. Do I want to keep doing WordPress the rest of my life? I don’t know. Do I want to keep doing WP Rig the rest of my life? I don’t know. But I will say that you bring up a very interesting point, which is it does take up a lot of time and also trust in open source over the past four or five years I would argue has diminished a little bit as a result of various events that have occurred over the past two or three years. I mean, we could cite the whole WP Engine Matt Mullerwig thing. We can also cite what’s going on with Oracle and JavaScript. Well, I mean, there’s many examples of this. I mean, we can cite the whole thing that happened… I mean, there’s various packages out there that are used and developed and open source to anybody, and some of them are going on maintained and it’s causing security vulnerabilities and degradation and all this stuff. So it’s a very important point. One thing I started thinking about after considering that in relation to WP Rig was I noticed that there’s usually a for-profit arm of any of these frameworks that seems to extend the lifespan of it. Let’s just talk about React, for example, React is an open source JavaScript framework, but it’s used by Facebook and Facebook is extremely for-profit. So companies that are making infrastructural or architectural decisions, they will base their choice on whether or not to use a framework largely on how long they think this framework is going to remain relevant or valid or maintained, right? A large part of that is, well, is there a company making money off of this thing? Because if there is, the chances- Topher: They’re going to keep doing that. Rob: They’re going to keep doing it. It’s going to stay around. That’s good. I think that’s healthy. A lot of people that like open source and want everything to be free, they might look at something like that and say like, well, I don’t want you to make a paid version of it or there shouldn’t be a pro version. I think that’s a very short-sighted way of looking at that software and these innovations. I think a more experienced way of looking at it is if you want something to remain relevant and maintained for a long period of time, having a for-profit way in which it’s leveraged is a very good thing. I mean, let’s be real. Would WordPress still be what it is today if there wasn’t a wordpress.com or if WooCommerce wasn’t owned by Automattic or whatever, right? They’ll be on top. I mean, it’s obviously impossible to say, but my argument would be, probably not. I mean, look at what’s happened to the other content management systems out there. You know, Joomla Drupal. They don’t really have a flourishing, you know, paid pro service that goes with their thing that’s very popular, at least definitely not as popular as WordPress.com or WordPress VIP or some of these other things that exist out there. And so having something that’s making and generating money that can then contribute back into it the way Automattic has been doing with WordPress over these years has, in my opinion, been instrumental. I mean, people can talk smack about Gutenberg all they want, but let’s be real, it’s 2025, would you still feel that WordPress is an elegant solution if we were still working from the WYSIWYG and using the classic editor? And I know a lot of people are still using the classic editor and there’s classic for us, the fork and all that stuff. But I mean, that only makes sense in a very specific implementation of WordPress, a very specific paradigm. If you want to explore any of these other paradigms out there, that way of thinking about WordPress kind of falls apart pretty quickly. I, for one, am happy that Gutenberg exists. I’m very happy that Automattic continues. And I’m grateful, actually, that Automattic continues to contribute back into WordPress. And not just them, obviously there’s other companies, XWP, 10Up, all these other companies are also contributing as well. But I’m very grateful that this ecosystem exists and that there’s contribution going back in and it’s happening from companies that are making money with this. And I think that’s vital. All that to say that WP Rig may and likely will have paid products in the future that leverage WP Rig. So that’s not to say that WP Rig will eventually cost money. That’s just to say that eventually people can expect other products to come out in the future that will be built on WP Rig and incentivize the continued contributions back into WP Rig. The open source version of WP Rig. Topher: That’s cool. I think that’s wise. If you want anything to stay alive, you have to feed it. Rob: That’s right. Topher: I had some more questions but I had forgotten them because I got caught up in your answer. Rob: Oh, thank you. I’ll take that as a compliment. I mean, my answer was eloquent. But I’m happy to expand on anything, know you, WordPress related, me related, you know, whether it comes to the ecosystem in WordPress, the whole WordCamp meetup thing is very interesting. I led the WP Omaha meetup for many years here in Omaha, Nebraska and I also led the WordCamp, the organizing of WordCamp here in Omaha for several years as well. That whole community, the whole ecosystem, at least in America seems to have largely fallen apart. I don’t know if you want to talk about that at all. But yeah, I’m ready to dive into any topics. Topher: I’m going to have one more question and then we’re going to wrap up. And it was that you were talking about all the things you had to learn. I’m sure there were nights where you were looking at your computer thinking, “Oh man, I had it working, now I gotta go learn a new thing.” I would love for you to go back in time and blog all of that if you would. But given that you can’t, I would be interested in a blog moving forward, documenting what you’re learning, how you’re learning it and starting maybe with a post that’s summarizes all of that. Obviously, that’s up to you and how you want to spend your time, but I think it’d be really valuable to other people starting a project, picking up somebody else’s project to see what the roadmap might look like. You know what I mean? Rob: For sure. Well, I can briefly summarize what I’ve learned over the years and where I’m at today with how I do this kind of stuff. I will say that a lot of the improvements to WP Rig that have happened over the last year or two would not be possible without the advent of AI. Topher: Interesting. Rob: That’s a fancy way of saying that I have been by coding a lot of WP Rig lately. If you know how to use AI, it is extremely powerful and it can help you do many things very quickly that previously would have taken much longer or more manpower. So, yeah, perhaps if there was like five, six, seven people actively, excuse me, actively contributing to WP Rig, then this type of stuff would have been possible previously, but that’s not the case. There is one person, well, one main contributor to WP Rig today and you’re talking to them. There are a handful of other people that have been likely contributing to WP Rig over the versions and you can find their contributions in the change log file in WP Rig. But those contributions have been extremely light compared to what I’ve been doing. I wouldn’t be able to do any of it without AI. I have learned my ability to learn things extremely rapidly has ramped up tenfold since I started learning how to properly leverage LLMs and AI. So that’s not to say that like, you know, WP Rig, all the code is just being completely written by AI and I’m just like. make it better, enter, and then like WP Rig is better. I wish it was that easy. It’s certainly not that. But when I needed to start asking some of these vital questions that I really didn’t have anyone to turn to to help answer them, I was able to turn to AI. For instance, let’s go back to the Webpack versus Gulp situation. Although Gulp is no longer used in WP Rig, you know, it was used in WP Rig until very recently. So I had to understand like, what is this system, how does it work, how do I extend it and how do I update it and all these things, right? And why aren’t we using WebPack and you know, is there validity to this criticism behind you should use webpack instead of Gulp or whatever, right? I was able to use AI to ask these questions and be able to get extremely good answers out of it and give me the direction I needed to make some of these kind of higher level decisions on like architecturally where should WP Rig go? It was through these virtual conversations with LLMs that I was able to refine the direction of WP Rig in a direction that is both modern and forward-thinking and architecturally sound. I learned a tremendous amount from AI about the architecture, about the code, about all of it. My advice to anybody that wants to extend their skill set a little bit in the development side of things is to leverage this new thing that we have in a way that is as productive as possible for you. So that’s going to vary from person to person. But for me, if I’m on a flight or if I’m stuck somewhere for a while, like, let’s say I got to take my kid to practice or something and I’m stuck there for an hour and I got to find some way to kill my time 9 times out of 10, I’m on my laptop or on my phone having conversations with Grok or ChatGPT or Gemini or whatever. I am literally refining… I’m just sitting there asking it questions that are on my mind that I wish I could ask somebody who’s like 10 times more capable than me. It has been instrumental. WP Rig wouldn’t be where it is today if it wasn’t for that. I would just say to anybody, especially now that it’s all on apps and you don’t have to be on a browser anymore, adopt that way of thinking. You know, if you’re on your lunch break or whatever and you have an hour lunch break and you only take 15 minutes to eat, what could you be doing with those other 45 minutes? You could just jump on this magical thing that we have now and start probing it for questions. Like, Hey, here’s what I know. Here’s what I don’t know. Fill these knowledge gaps for me.” And it is extremely good at doing that. Topher: So my question was, can you blog this and your answer told me that there’s more there that I want to hear. That’s the stuff that should be in your book when you write your book. Rob: I’m flattered that you would be interested in reading anything that I write. So thank you. I’ve written stuff in the past and it hasn’t gotten a lot of attention. But I also don’t have any platforms to market it either. But yeah, no, I made some… I’m sorry. Topher: I think your experience is valuable far beyond Rig or WordPress. If you abstract it out of a particular project to say, you know, I did this with a project, I learned this this way, I think that would be super valuable. Rob: Well, I will say that recently at my current job, I was challenged to create an end to end testing framework with Playwright that would speed up how long it takes to test things and also prevent, you know, to make things fail earlier, essentially, to prevent broken things from ending up in the wild, right, and having to catch them the hard way. I didn’t know a lot about Playwright, but I do know how toolkits work now because of WP Rig. And I was able to successfully in a matter of, I don’t know, three days, put together a starter kit for a test framework that we’re already using at work to test any website that we create for any client. It can be extended and it can be hooked into any CI CD pipeline and it generates reports for you and it does a whole bunch of stuff. I was able to do this relatively quickly. This knowledge, yes, does come in handy in other situations. Will I end up developing other toolkits like WP Rig in the future for other things? I guess if I can give any advice to anybody listening out there, another piece of advice I would give people is, you know, especially if you’re a junior developer and you’re still learning or whatever, or you’re just a marketing person and just want to have more control over the functionality side of what you’re creating or more insight into that so you could better, you know, manage projects or whatever. My advice would be to take on a small little project that is scoped relatively small that’s not too much for you to chew and go build something and do it with… Just doing that will be good. But if you can do it with the intent to then present it in some fashion, whether it be a blog article or creating a YouTube video or going to a meetup and giving a talk on it or even a lunch and learn at work or whatever, right, that will, in my experience, it will dramatically amplify how much you learn from that little pet project that’s kind of like a mini learning experience. And I highly encourage anybody out there to do that on the regular. Actually, no matter what your experience level is in development, I think you should do these things on a regular basis. Topher: All right. I’m going to wrap this up. I got to get back to work. You probably have to get back to work. Rob: Yeah. Topher: Thanks for talking. Rob: Thanks for having me, Topher. Really appreciate it. Topher: Where could people find you? WPrig.io?  Rob: Yeah, WPrig.io. WP rig has accounts on all of the major platforms and, even on Bluesky and Mastodon. You can look me up, Rob Ruiz. You can find me on LinkedIn. You can find me on all of those same platforms as well. You can add me on Facebook if you want, whatever. And I’m also in the WordPress Slack as well as Rob Ruiz. You can find me in the WordPress Slack. And then I’m on the WordPress Reddit and all that stuff. So yeah, reach out. If anybody wants to have any questions about Rig or anything else, I’m happy to engage.  Topher: Sounds good. All right, I’ll see you. Rob: All right, thanks, Topher. Have a good day. Topher: This has been an episode of the Hallway Chats podcast. I’m your host Topher DeRosia. Many thanks to our sponsor Nexcess. If you’d like to hear more Hallway Chats, please let us know on hallwaychats.com.

We're kicking off 2026 with two coding resources inspired by winter-break. This week, we feature Coddy.tech, a goal-based coding platform where students can choose a language (Python, JavaScript, HTML, and more) and a skill level, then follow a step-by-step learning path with built-in feedback and challenges. We also talk about projects.raspberrypi.org, a free project hub from the Raspberry Pi Foundation that offers Scratch, Python, AI, web dev, and more, all organized by student interests like nature, space, art, music, and science. Together, these tools support problem-solving, creativity, typing skills, and persistence through productive trial-and-error.Mentioned in this episode:Education Podcast NetworkTech Tools for Teachers is part of the Education Podcast Network. https://www.edupodcastnetwork.com/This podcast uses the following third-party services for analysis: Podcorn - https://podcorn.com/privacyPodtrac - https://analytics.podtrac.com/privacy-policy-gdrp

In this episode of Remote Ruby, Chris, Andrew, and David humorously discuss the rapid increase of 'wrapped' features in various apps, recount personal experiences with food apps, and then dive into their favorite conference moments of the year. They also explore the concept of UI affordances and its importance in web design and give a preview of upcoming conferences in 2026, and a brief discussion on modern CSS and JavaScript elements. Hit download now to hear much more! LinksChris Oliver XAndrew Mason BlueskyDavid Hill BlueskyJudoscale- Remote Ruby listener giftRBQ Conf, March 26 & 27, 2026Tropical on Rails, April 9 & 10, 2026Blue Ridge Ruby, April 30 & May 1, 2026Blastoff Rails, June 11 & 12, 2026Baltic Ruby, June 12 & 13, 2026Ruby Conf, July 14-16, 2026RubyConf Africa, August 21 & 22, 2026Rails World, Sept 23 & 24, 2026Ruby eventsAffordances: The Missing Layer in Frontend Architecture (Stephen Margheim) Chris Oliver X/Twitter Andrew Mason X/Twitter Jason Charnes X/Twitter

In this panel episode, the crew discusses AI platform consolidation, open-source sustainability, and the future of web development. We break down Anthropic's acquisition of Bun, what it means for the JavaScript ecosystem, and whether open-source projects can remain independent as AI companies invest heavily in infrastructure. We also discuss Zig leaving GitHub, growing concerns around AI-first developer tools, npm security vulnerabilities, and supply-chain risk in modern software. The episode wraps with hot takes on AI infrastructure costs, developer productivity, and practical advice for engineers navigating today's rapidly changing tech landscape. Resources Anthropic acquires Bun as Claude Code hits $1B milestone: https://www.anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-milestone Zig quits GitHub, says Microsoft's AI obsession ruined the service: https://ziglang.org/news/migrating-from-github-to-codeberg/ Shai-Hulud: 1K+ npm packages & 27K repos infected: https://helixguard.ai/blog/malicious-sha1hulud-2025-11-24 IBM CEO says AI data center spending “won't pay off” at current costs: https://www.businessinsider.com/ibm-ceo-big-tech-ai-capex-data-center-spending-2025-12 We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Fill out our listener survey (https://t.co/oKVAEXipxu)! https://t.co/oKVAEXipxu Let us know by sending an email to our producer, Elizabeth, at elizabeth.becz@logrocket.com (mailto:elizabeth.becz@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Check out our newsletter (https://blog.logrocket.com/the-replay-newsletter/)! https://blog.logrocket.com/the-replay-newsletter/ Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it for free at LogRocket.com. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Chapters 01:00 – Meet the Panel: Paige, Jack, and Paul 02:00 – Anthropic Acquires Bun: First Reactions 05:30 – What the Bun Acquisition Means for JavaScript Runtimes 09:00 – Open Source Funding, Independence, and New Exit Models 14:30 – Zig Leaves GitHub: AI-First Platforms and OSS Friction 20:30 – GitHub, Copilot, and Developer Experience Tradeoffs 24:30 – npm Security, Supply Chain Attacks, and Trust at Scale 31:00 – Are We Too Dependent on Big Tech Platforms? 36:30 – AI Infrastructure Costs and the Sustainability Question 43:00 – Small Models, Local AI, and the Future of Inference 50:30 – Hot Takes: Subscriptions, Burnout, and Developer Frustration 58:30 – Security Alerts, Tooling Wins, and Final Thoughts Special Guest: Jack Herrington.

Wes and Scott talk about their bold predictions for web development in 2026, from WebGPU-powered design and modern CSS breakthroughs to JavaScript standards, AI-driven tooling, security risks, the future of frameworks, workflows, and more! Show Notes 00:00 Welcome to Syntax! 00:49 WebGPU and 3D experiences will finally take off Lando Norris 01:30 Web design will make a comeback Raycast shaders.com 04:03 Light mode returns (yes, really) 07:06 Modern CSS standards are about to have a huge year CSS Wrapped Graffiti 13:15 Will the Temporal API finally ship everywhere in 2026? 14:18 The rise of the standard stack 16:18 Are we headed toward standardized RPC? 19:41 What's next (and what's not) for React 21:07 Why we'll see more security failures in web dev 22:35 SvelteKit 3 lands in 2026 22:53 Where developer tooling is headed next Oxc Biome 26:44 More big acquisitions Anthropic Bun 28:02 2026: the year of durable compute 30:57 Frameworks will matter less as AI gets better 33:34 End-to-end AI workflows become the norm 36:04 Brought to you by Sentry.io 37:21 Personalized software for everyday people 39:11 MCP and MCP UI will pop 42:24 Developer skills will fall off 46:20 Crappy software will continue Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

From creating SWE-bench in a Princeton basement to shipping CodeClash, SWE-bench Multimodal, and SWE-bench Multilingual, John Yang has spent the last year and a half watching his benchmark become the de facto standard for evaluating AI coding agents—trusted by Cognition (Devin), OpenAI, Anthropic, and every major lab racing to solve software engineering at scale. We caught up with John live at NeurIPS 2025 to dig into the state of code evals heading into 2026: why SWE-bench went from ignored (October 2023) to the industry standard after Devin's launch (and how Walden emailed him two weeks before the big reveal), how the benchmark evolved from Django-heavy to nine languages across 40 repos (JavaScript, Rust, Java, C, Ruby), why unit tests as verification are limiting and long-running agent tournaments might be the future (CodeClash: agents maintain codebases, compete in arenas, and iterate over multiple rounds), the proliferation of SWE-bench variants (SWE-bench Pro, SWE-bench Live, SWE-Efficiency, AlgoTune, SciCode) and how benchmark authors are now justifying their splits with curation techniques instead of just "more repos," why Tau-bench's "impossible tasks" controversy is actually a feature not a bug (intentionally including impossible tasks flags cheating), the tension between long autonomy (5-hour runs) vs. interactivity (Cognition's emphasis on fast back-and-forth), how Terminal-bench unlocked creativity by letting PhD students and non-coders design environments beyond GitHub issues and PRs, the academic data problem (companies like Cognition and Cursor have rich user interaction data, academics need user simulators or compelling products like LMArena to get similar signal), and his vision for CodeClash as a testbed for human-AI collaboration—freeze model capability, vary the collaboration setup (solo agent, multi-agent, human+agent), and measure how interaction patterns change as models climb the ladder from code completion to full codebase reasoning. We discuss: John's path: Princeton → SWE-bench (October 2023) → Stanford PhD with Diyi Yang and the Iris Group, focusing on code evals, human-AI collaboration, and long-running agent benchmarks The SWE-bench origin story: released October 2023, mostly ignored until Cognition's Devin launch kicked off the arms race (Walden emailed John two weeks before: "we have a good number") SWE-bench Verified: the curated, high-quality split that became the standard for serious evals SWE-bench Multimodal and Multilingual: nine languages (JavaScript, Rust, Java, C, Ruby) across 40 repos, moving beyond the Django-heavy original distribution The SWE-bench Pro controversy: independent authors used the "SWE-bench" name without John's blessing, but he's okay with it ("congrats to them, it's a great benchmark") CodeClash: John's new benchmark for long-horizon development—agents maintain their own codebases, edit and improve them each round, then compete in arenas (programming games like Halite, economic tasks like GDP optimization) SWE-Efficiency (Jeffrey Maugh, John's high school classmate): optimize code for speed without changing behavior (parallelization, SIMD operations) AlgoTune, SciCode, Terminal-bench, Tau-bench, SecBench, SRE-bench: the Cambrian explosion of code evals, each diving into different domains (security, SRE, science, user simulation) The Tau-bench "impossible tasks" debate: some tasks are underspecified or impossible, but John thinks that's actually a feature (flags cheating if you score above 75%) Cognition's research focus: codebase understanding (retrieval++), helping humans understand their own codebases, and automatic context engineering for LLMs (research sub-agents) The vision: CodeClash as a testbed for human-AI collaboration—vary the setup (solo agent, multi-agent, human+agent), freeze model capability, and measure how interaction changes as models improve — John Yang SWE-bench: https://www.swebench.com X: https://x.com/jyangballin Chapters 00:00:00 Introduction: John Yang on SWE-bench and Code Evaluations 00:00:31 SWE-bench Origins and Devon's Impact on the Coding Agent Arms Race 00:01:09 SWE-bench Ecosystem: Verified, Pro, Multimodal, and Multilingual Variants 00:02:17 Moving Beyond Django: Diversifying Code Evaluation Repositories 00:03:08 Code Clash: Long-Horizon Development Through Programming Tournaments 00:04:41 From Halite to Economic Value: Designing Competitive Coding Arenas 00:06:04 Ofir's Lab: SWE-ficiency, AlgoTune, and SciCode for Scientific Computing 00:07:52 The Benchmark Landscape: TAU-bench, Terminal-bench, and User Simulation 00:09:20 The Impossible Task Debate: Refusals, Ambiguity, and Benchmark Integrity 00:12:32 The Future of Code Evals: Long Autonomy vs Human-AI Collaboration 00:14:37 Call to Action: User Interaction Data and Codebase Understanding Research

Shelly Palmer has spent 45 years watching technology reshape every industry—from writing news themes for CBS to consulting with every major media company on AI strategy. On this year-end recap, he cuts through the noise with one devastating observation: 2025 was the year everyone talked about AI while almost nobody actually used it. Executives shook their heads knowingly in meetings, pontificated about capabilities the models don't yet have, and parroted nonsense they read from other people who knew nothing. But when you asked one innocent question, they crumbled.In the News: CES 2026 shapes up with Nvidia sponsoring two full days of AI training. Samsung is skipping the main floor for a massive offsite activation. Sony brings no electronics—only Honda's experimental vehicles. The TCL and Chinese companies' presence hinges on tariff policy. The innovation series breakfast that Shelly runs is becoming an official CES event after a decade of independence.The conversation spirals into deeper territory: $3 trillion in government money is stacked behind AI development. The U.S. explicitly states it must beat China to AGI—making this the Manhattan Project of our lifetime. Shelly walks through what he's seen in successful companies (leadership using the tech, paid "Tech Tuesdays" for AI experiments, cross-discipline teams with SecOps and legal at the table) versus the chaos of places with no process. He breaks down what's real—drone warfare, cybersecurity applications, robotics—versus what's hot air. And he makes a case that won't be killed by AI itself, but by militarized applications and the geopolitical arms race we're already in.5 Key Takeaways from Shelly:Leadership belief and hands-on use are non-negotiable. Companies winning with AI have senior leaders who actually use the technology. When the CEO walks into an LT meeting saying "I built this agent over the weekend," everyone else starts experimenting too.The recipe for AI success has three ingredients: leadership belief, paid time to experiment (Tech Tuesdays/Thursdays with real budgets), and cross-discipline teams (SecOps, legal, compliance, risk) paving the way. Chaos erupts without this structure.You cannot build a point of view on AI from reading blogs or watching YouTubers. Pick a personal project you care about, go hands-on with a model (Claude, Gemini, GPT), and complete it from beginning to end. Only lived experience grounds your understanding.AI parallelizes with web 1.0: In 1998, you had to hand-code HTML, build databases manually, write raw JavaScript. Today you can vibe code a site in 90 seconds. AI will eventually reach "spin me up an expert that does X" without asking questions—we're not there yet, but it's inevitable.It's both bubble and Manhattan Project. Some valuations are insane and will burst. But military applications, cyber warfare, drone control, robotics—those aren't going anywhere. The government won't back off. Both outcomes happen simultaneously.This episode is brought to you by Zappar, creators of Mattercraft—the leading visual development environment for building immersive 3D web experiences for mobile headsets and desktop. Mattercraft combines game engine power with web flexibility and features an AI assistant to help you design, code, and debug in real time in your browser. Build smarter at mattercraft.io.See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

This is a re-release of a super popular episode from back in 2023 - happy holidays! Learning JavaScript from scratch can be as much about syntax as it is programming concepts, especially when it's your first language. Concepts like knowing how and why you need a place to store bits of data (variables), re-using code snippets instead of writing them repeatedly (functions), making decisions (conditional statements), and working with collections of data (arrays and looping) are all second nature to experienced developers. These concepts are the foundational building blocks that let you solve problems by thinking like a computer (sometimes this is called programmatic logic). In this episode, Matt and Mike discuss these key JavaScript basics including variables, functions, conditional statements, arrays, and looping. Show Notes: https://www.htmlallthethings.com/podcast/javascript-basics-learn-these-concepts-first-re-release

In this episode of the Crazy Wisdom Podcast, host Stewart Alsop sits down with Mike Bakon to explore the fascinating intersection of hardware hacking, blockchain technology, and decentralized systems. Their conversation spans from Mike's childhood fascination with taking apart electronics in 1980s Poland to his current work with ESP32 microcontrollers, LoRa mesh networks, and Cardano blockchain development. They discuss the technical differences between UTXO and account-based blockchains, the challenges of true decentralization versus hybrid systems, and how AI tools are changing the development landscape. Mike shares his vision for incentivizing mesh networks through blockchain technology and explains why he believes mass adoption of decentralized systems will come through abstraction rather than technical education. The discussion also touches on the potential for creating new internet infrastructure using ad hoc mesh networks and the importance of maintaining truly decentralized, permissionless systems in an increasingly surveilled world. You can find Mike in Twitter as @anothervariable.Check out this GPT we trained on the conversationTimestamps00:00 Introduction to Hardware and Early Experiences02:59 The Evolution of AI in Hardware Development05:56 Decentralization and Blockchain Technology09:02 Understanding UTXO vs Account-Based Blockchains11:59 Smart Contracts and Their Functionality14:58 The Importance of Decentralization in Blockchain17:59 The Process of Data Verification in Blockchain20:48 The Future of Blockchain and Its Applications34:38 Decentralization and Trustless Systems37:42 Mainstream Adoption of Blockchain39:58 The Role of Currency in Blockchain43:27 Interoperability vs Bridging in Blockchain47:27 Exploring Mesh Networks and LoRa Technology01:00:25 The Future of AI and DecentralizationKey Insights1. Hardware curiosity drives innovation from childhood - Mike's journey into hardware began as a child in 1980s Poland, where he would disassemble toys like battery-powered cars to understand how they worked. This natural curiosity about taking things apart and understanding their inner workings laid the foundation for his later expertise in microcontrollers like the ESP32 and his deep understanding of both hardware and software integration.2. AI as a research companion, not a replacement for coding - Mike uses AI and LLMs primarily as research tools and coding companions rather than letting them write entire applications. He finds them invaluable for getting quick answers to coding problems, analyzing Git repositories, and avoiding the need to search through Stack Overflow, but maintains anxiety when AI writes whole functions, preferring to understand and write his own code.3. Blockchain decentralization requires trustless consensus verification - The fundamental difference between blockchain databases and traditional databases lies in the consensus process that data must go through before being recorded. Unlike centralized systems where one entity controls data validation, blockchains require hundreds of nodes to verify each block through trustless consensus mechanisms, ensuring data integrity without relying on any single authority.4. UTXO vs account-based blockchains have fundamentally different architectures - Cardano uses an extended UTXO model (like Bitcoin but with smart contracts) where transactions consume existing UTXOs and create new ones, keeping the ledger lean. Ethereum uses account-based ledgers that store persistent state, leading to much larger data requirements over time and making it increasingly difficult for individuals to sync and maintain full nodes independently.5. True interoperability differs fundamentally from bridging - Real blockchain interoperability means being able to send assets directly between different blockchains (like sending ADA to a Bitcoin wallet) without intermediaries. This is possible between UTXO-based chains like Cardano and Bitcoin. Bridges, in contrast, require centralized entities to listen for transactions on one chain and trigger corresponding actions on another, introducing centralization risks.6. Mesh networks need economic incentives for sustainable infrastructure - While technologies like LoRa and Meshtastic enable impressive decentralized communication networks, the challenge lies in incentivizing people to maintain the hardware infrastructure. Mike sees potential in combining blockchain-based rewards (like earning ADA for running mesh network nodes) with existing decentralized communication protocols to create self-sustaining networks.7. Mass adoption comes through abstraction, not education - Rather than trying to educate everyone about blockchain technology, mass adoption will happen when developers can build applications on decentralized infrastructure that users interact with seamlessly, without needing to understand the underlying blockchain mechanics. Users should be able to benefit from decentralization through well-designed interfaces that abstract away the complexity of wallets, addresses, and consensus mechanisms.

Is transgenderism a mental disorder? Is transexualism a delusional pursuit? Is sexual identity a cultural value arbitrarily assigned at birth? This is the topic of today's discussion. My first experience with a person seeking transexual modification was as a private practice marriage counselor in Idaho, back in the early 1980's. This fellow was seeking an official diagnosis of transexualism as required by the state in order to proceed with surgical procedures. He had been denied certification by other psychologists and was hoping I would provide him with the needed diagnosis. One session was enough for me to deny his claim. Why? After hearing his story, it turned out that his wife had recently decided she was a lesbian and no longer wanted to have sex with him. In order to save his marriage he decided to have his genitals surgically removed so he could “become a woman” to save their marriage. Though motivated by love for his wife, this reason would not qualify him for surgery under any transgender or transexual definition. I can tell you he was plenty pissed off by my refusal to go along with his plan. By definition, a transgendered individual is one who identifies with a gender incongruent with their body. They prefer dressing in clothing usually associated with the “other” gender and purposely minimize their secondary sexual characteristics. They may prefer engaging in activities more popular with the “other” gender. Population estimates of transgender persons has jumped from an historically steady 0.6% of the total population as of 2016 to 1.0% of the population surveyed in 2025, with young people ages 13-17 now accounting for 3.3% of the general population. Transexual is defined as taking the extra step of body modification through surgery or hormones to bring the body into closer congruence with self-identity. It is estimated that 25% to 30% of transgendered individuals now undergo body modification, up from an estimated 10% to 15% in the early 2000's. What accounts for this rise in trans identity? Is it merely a rise in societal acceptance that grants the freedom to declare one's identity publicly as many claim, or is there another, more gnostic, interpretation of this phenomena? Let's consider this carefully. Many gnostic texts suggest that the spiritual plane is gendered and populated by male and female entities, which gives rise to tidy mythological pantheons of male and female gods. However, I question the meaning of the term “gender” as it applies to the aeonic realm. At least one important book of the Nag Hammadi makes no mention of gender in the spiritual realm, and that's the Tripartite Tractate upon which this gnosis is based. [I take that back. Actually, there's one mention of the fallen Aeon being as one stripped of their masculinity, but that's more a statement of overall loss of integration and power arising from the fall.] Everything I'm sharing with you today is based upon the Tripartite Tractate and the logical conclusions that arise from that book. Yes, the terms “Father” and “Son” are assigned to the originating consciousness out of which our consciousness flows, but the meaning of those terms has nothing to do with sexual attributes or form. Neutral names like “Source” and “Offspring” would do as nicely but lack the personal relatability of family and the familiarity of traditional names. Sexual orientation and activity only applies to us creatures here in the Deficiency for purposes of reproduction. The portal between the ethereal and the so-called material cosmos requires a mechanism for fruiting the 2nd Order Powers arriving from the Fullness. Sexual activity is primarily responsible for populating the 2nd economy for all creatures above the level of bacteria, amoeba, fungi, and some plants and invertebrates. It would seem that the rules for fruiting changed from asexual to sexual as the complexity of the 2nd Order creatures arriving on the planet changed from smallest to largest. The Aeons are not male and female. They are fully integrated units of consciousness. What we call male identity and female identity reflect our lack of integration of our complete identity, or what Jung referred to as the lack of self-actualization of our animus and anima. In other words, our essential identities are neither male nor female but both. So identifying with either is actually a deficiency that represents incomplete individuation hampered by overidentification with the physical form. Male identity is misclassified as belonging to a man's soul identity, or what we here at Gnostic Insights call “ego” identity. The same goes for female identity. Remember, all 2nd Order Powers share the same One Self consciousness that flows unimpeded from Above. What distinguishes us is our ego identity—our self-identified name, position, place, and duty. The same goes for the Aeons. The Aeons share their One identity with the Son as fractals of the Son, and are distinguished from one another by their self-identified egoic position within the hierarchy of the Fullness of God according to name, position, place, and duty. Like the Aeons, we encompass and embrace the full anima/animus spectrum within our ego identity. But down here, physical and material forces act upon our bodies and influence self-identity as either male or female. In reality, we are equally both. Furthermore, the memes we pick up here from our childhood experiences, especially childhood sexual trauma, can affect our gender identity. The Son is the Father's only direct emanation. The Son is a monad, not a dyad or syzygy. Even though we call this monad the Son, it is not a male figure. The Son is a fully realized individual representing all aspects of the originating Source. The Son is the singular embodiment of the ALL. The Totalities of the ALL are the full expression of the diversity of the Son. The Totalities of the ALL are not self-aware; they are fully identified with the ungendered Son. The ALL is called the “aeon of the Aeons.” During the act of singing glorious praise to the Father, this “aeon of the aeons” produces a limitless variety of Aeons that occupy the Fullness of God. The Aeons of the Fullness are fractal iterations of the ungendered Son. The Aeons self-sort themselves into a hierarchy of unique positions, ranks, and duties within the Fullness. Their job is to continue giving glory to the Father through song. The Aeons do not reproduce sexually. They combine with other Aeons and sings songs of glory to the Father all together within these various combinations, which produces fruit from their comingled glory. And during the giving of glory, the Aeons dream of Paradise. We 2nd Order Powers are the fruit of these Aeons dreaming of Paradise. We enjoy making love the same way the Aeons enjoy giving glory together. In our fallen world, we 2nd Order Powers manifest as only two sexes for the purpose of reproduction. Self-assigned gender identity is irrelevant to the end goal of biological reproduction; male plus female are required. Love is not confined to sexual activity or reproduction. Love is love and we are all full of love that flows like an unending stream from the Father through the Fullness. Love is not limited to sex, reproduction, or gender identification. Now we move on to a consideration of reincarnation and its implications for transgender confusion. We've talked about reincarnation in prior episodes. If you would like to review those, the links are in the transcript to this episode, so if you are listening to an audio podcast, please visit the Gnostic Insights website where all previous episodes are posted, or view this transcript at the Cyd Ropp Gnostic Reformation Substack. [Revisiting Reincarnation] [Reincarnation, Research, and Gnosis] Reincarnation provides an excellent counter-argument to transgenderism, so let's consider the logic of this together. We do not necessarily reincarnate as the same gender from lifetime to lifetime. Therefore it follows that our ego's memory houses all of our prior gender identities. What we take for our gender identity is usually associated with the body we are currently inhabiting. A person may identify with their previous life's gender and carry those memes strongly forward into this incarnation. It is not an error to notice those gender-identified memes and behave accordingly. The error is thinking this current body needs to conform to that previous meme chord that we call gender. Confusion arises from thinking one is born into the wrong body or telling a child they are born into the wrong body. No. We are born into the most perfect body possible for our current incarnation. We are sent into this fallen world by our aeonic parents with our full cooperation. We forget our mission once we are here. We forget why we are here and who we really are, just as the Demiurge did. The error is thinking we know better than the Fullness from our fallen perspective down here who we are and what body we should be wearing. “Tomboy” girls and so-called “effeminate” boys are just that. There is no need to make the body conform to the previous life's body. There is a reason to inhabit the body one is born into. Perhaps lessons to be learned by living a lifetime in a less familiar body configuration. Remember, our talents are gifted by our aeonic parents, just as our DNA comes through our earthly parents. A female who is gifted with so-called “masculine” traits is not masculine. The words masculine or feminine are misnomers of our gender-obsessed, fallen culture. Here's a chart of so-called masculine and feminine traits drawn up by an AI at my request. The AI noted that, “Personality traits are often categorized as masculine or feminine, though it's important to note that these traits exist on a spectrum and can be present in anyone, regardless of gender.” And, indeed, you can see by the chart that a well-balanced, integrated personality would display both types of traits as needed, regardless of sex. Trait Type Communication Masculine: Direct, assertive Feminine: Empathetic, nurturing Emotional Expression Masculine: Reserved, independent Feminine: Expressive, relational Leadership Style Masculine: Authoritative, task-oriented Feminine: Collaborative, inclusive Conflict Resolution Masculine: Competitive, confrontational Feminine: Cooperative, harmony Decision Making Masculine: Decisive, risk-taking Feminine: Reflective, consensus-building Problem Solving Masculine”: Analytical, logical Feminine: Intuitive, holistic Self-Perception Masculine: Self-reliant, confident Feminine: Community building, supportive Offering my own experience as an example, this unit of consciousness that is known as Cyd is often miscategorized by others as exhibiting so-called masculine traits in academic and workplace settings. Yet, at home, I skew much more toward the “feminine.” That's probably why I enjoyed running a large bed and breakfast for several years, because both types of traits make for an efficient yet caring innkeeper. Growing up, I was considered a “tomboy,” preferring wrestling and sports to playing with dolls and trying on make-up. My pixie haircut displays my lifelong disdain for futzing with hairdo's, curlers, and hair products. My mother was a glamorous woman, a real girlie-girl that forever tried to force me into pink and ruffles while I preferred jeans and hoodies, much to her frustration. Again, I don't think that any of these distinctions have one whit to do with gender. It never even crossed my mind that I should be a boy. Rude people from time to time have suggested I “come out” as gay and join the alphabet community. No thanks. No need. I am not confused. I am who I am. Knowing who you are, your aeonic inheritance and lifetimes of experience, transcends the tidy categories the culture would like to cram us into. The categories become irrelevant. We carry our fixed, God-given personalities along with our self-identity egos with us from lifetime to lifetime, adding and subtracting memes and meme chords like gender identity as we go. However, our initial personalities were formed by Aeons giving praise together in various combinations. Eventually we reach our final resting place. That resting place is not the silence of decomposing flesh in the grave. We have occupied countless bodies and forms throughout our lifetimes. We have left those bodies behind every time. We are not confined to those vessels of flesh and bone that sicken and die. Our One Self spirit and ever-evolving ego carry on. We either return to the next, most perfect body for our unit of consciousness to inhabit, or we stay in the higher ethereal plane occupied by Aeons and 2nd Order Powers who have left behind the material cosmos and the confusion that arises in the Deficiency. We will remain recognizable by ourselves and others. Our ego identification is not dependent on our gender or appearance; we have occupied so many different bodies in so many different incarnations that there is no way our identity is anchored by a single material form. Like Christ and the 3rd Order of Powers, we will all be recognizable to those who know us, irrespective of appearance or sexual traits. Like the Aeons, our ego is tied to our mind, our words, our rank in the overall system of the Fullness. “Each of those who glorify has his own station, rank, dwelling place, and place of rest, which is the glorification he brings forth.” [Tripartite Tractate verse 70] “For each of the aeons is a name corresponding to each of the Father's qualities and powers. Since he exists in many names, it is by mingling and through mutual harmony that they are able to speak of him, by means of a richness of speech. Thus, the Father is a single Name because he is One, but nevertheless innumerable in his qualities and names.” [verse 73] Just be who you are without labels or gender identification. Embrace your self-identity irrespective of how you present to others as long as it is true to your aeonic, God-given Self and ego. Drop those confusing and unnecessary cultural memes that weigh down your soul. Our God Above All Gods is not the author of confusion. Gender confusion is just another demiurgic ploy to throw you off track and keep you down. The Father's will is strong and clear and uplifting. The path of discovering gnosis and self-actualization is not through the labyrinths of despair and self-doubt. And it is certainly not through a surgeon's scalpel. Turn your eyes up to the Fullness and within to find true self identity and acceptance. This article is not meant to criticize but to uplift divergent individuals like myself. God blesses all of us. Onward and upward. Please enable JavaScript in your browser to complete this form.Name *FirstLastEmail *Stripe Credit Card *Choose your item *Item A - $10.00Item B - $25.00Item C - $50.00Total$0.00Submit

JavaScript has grown far beyond the browser. It now powers millions of backend systems, APIs, and cloud services through Node.js, which is one of the most widely deployed runtimes on the planet. Keeping such a critical piece of infrastructure fast, secure, and stable is a massive engineering challenge, and the work behind it is often The post Node.js in 2026 with Rafael Gonzaga appeared first on Software Engineering Daily.

professorjrod@gmail.comExplore the pivotal moment in technology education as we trace the origins of the internet browser from Mosaic's innovation at NCSA to Netscape Navigator's rise as the gateway to the web. This episode dives deep into internet history, highlighting the major players like Jim Clark and Marc Andreessen who shaped the early web experience. We also analyze the browser wars triggered by Microsoft's Internet Explorer, illustrating challenges in technology development and competition. Whether you're preparing for your CompTIA exam or passionate about tech exam prep, understanding this history enriches your IT skills development and offers valuable context for technology education.I walk through the tactics that made Navigator beloved—progressive rendering, rapid updates, and the birth of JavaScript—and the strategic choices that slowed it down, like the all-in-one Communicator suite. We unpack the bundling play that tilted distribution, the developer headaches of competing nonstandard features, and the DOJ antitrust case that redefined how we think about platform power. The twists don't end there: AOL buys Netscape, adoption fades, and then a bold move changes the web again—open sourcing the code to create Mozilla.From Gecko to Phoenix to Firefox, we trace how community-driven software brought speed, security, and standards back to center stage. That lineage lives in every tab you open today, from Firefox to Chrome to Safari, and in the modern idea of the browser as a platform for apps, SaaS, and daily life. Along the way, I share classroom plans, student podcast previews, and a practical way educators can keep learners engaged over winter break.If you love origin stories, tech strategy, or just remember the thrill of that big N on a beige PC, this one's for you. Listen, subscribe, and share your first browser memory with us—was it Navigator, IE, or something else? And if this journey brought back the dial-up feels, leave a review and pass it on.Support the showArt By Sarah/DesmondMusic by Joakim KarudLittle chacha ProductionsJuan Rodriguez can be reached atTikTok @ProfessorJrodProfessorJRod@gmail.com@Prof_JRodInstagram ProfessorJRod

In this episode, Noel sits down with David Mytton, founder and CEO of Arcjet, to unpack the React2Shell vulnerability and why it became such a serious remote code execution risk for apps using React server components and Next.js. They explain how server-side features introduced in React 19 changed the attack surface, why cloud providers leaned on WAF mitigation instead of instant patching, and what this incident reveals about modern JavaScript supply chain risk. The conversation also covers dependency sprawl, rushed patches, and why security as a feature needs to start long before production. Links X: https://x.com/davidmytton Blog: https://davidmytton.blog Resources Multiple Threat Actors Exploit React2Shell: https://cloud.google.com/blog/topics/threat-intelligence/threat-actors-exploit-react2shell-cve-2025-55182 We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Fill out our listener survey (https://t.co/oKVAEXipxu)! https://t.co/oKVAEXipxu Let us know by sending an email to our producer, Elizabeth, at elizabeth.becz@logrocket.com (mailto:elizabeth.becz@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). Check out our newsletter (https://blog.logrocket.com/the-replay-newsletter/)! https://blog.logrocket.com/the-replay-newsletter/ Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://podrocket.logrocket.com/get-podrocket-stickers), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it for free at LogRocket.com. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Chapters

For years, building interactive widgets in Python notebooks meant wrestling with toolchains, platform quirks, and a mountain of JavaScript machinery. Most developers took one look and backed away slowly. Trevor Manz decided that barrier did not need to exist. His idea was simple: give Python users just enough JavaScript to unlock the web's interactivity, without dragging along the rest of the web ecosystem. That idea became anywidget, and it is quickly becoming the quiet connective tissue of modern interactive computing. Today we dig into how it works, why it has taken off, and how it might change the way we explore data. Episode sponsors Seer: AI Debugging, Code TALKPYTHON PyCharm, code STRONGER PYTHON Talk Python Courses Links from the show Trevor on GitHub: github.com anywidget GitHub: github.com Trevor's SciPy 2024 Talk: www.youtube.com Marimo GitHub: github.com Myst (Markdown docs): mystmd.org Altair: altair-viz.github.io DuckDB: duckdb.org Mosaic: uwdata.github.io ipywidgets: ipywidgets.readthedocs.io Tension between Web and Data Sci Graphic: blobs.talkpython.fm Quak: github.com Walk through building a widget: anywidget.dev Widget Gallery: anywidget.dev Video: How do I anywidget?: www.youtube.com PyCharm + PSF Fundraiser: pycharm-psf-2025 code STRONGER PYTHON Watch this episode on YouTube: youtube.com Episode #530 deep-dive: talkpython.fm/530 Episode transcripts: talkpython.fm Theme Song: Developer Rap

BONUS: Swimming in Tech Debt — Practical Techniques to Keep Your Team from Drowning in Its Codebase In this fascinating conversation, veteran software engineer and author Lou Franco shares hard-won lessons from decades at startups, Trello, and Atlassian. We explore his book "Swimming in Tech Debt," diving deep into the 8 Questions framework for evaluating tech debt decisions, personal practices that compound over time, team-level strategies for systematic improvement, and leadership approaches that balance velocity with sustainability. Lou reveals why tech debt is often the result of success, how to navigate the spectrum between ignoring debt and rewriting too much, and practical techniques individuals, teams, and leaders can use starting today. The Exit Interview That Changed Everything "We didn't go slower by paying tech debt. We went actually faster, because we were constantly in that code, and now we didn't have to run into problems." — Lou Franco   Lou's understanding of tech debt crystallized during an exit interview at Atalasoft, a small startup where he'd spent years. An engineer leaving the company confronted him: "You guys don't care about tech debt." Lou had been focused on shipping features, believing that paying tech debt would slow them down. But this engineer told a different story — when they finally fixed their terrible build and installation system, they actually sped up. They were constantly touching that code, and removing the friction made everything easier. This moment revealed a fundamental truth: tech debt isn't just about code quality or engineering pride. It's about velocity, momentum, and the ability to move fast sustainably. Lou carried this lesson through his career at Trello (where he learned the dangers of rewriting too much) and Atlassian (where he saw enterprise-scale tech debt management). These experiences became the foundation for "Swimming in Tech Debt." Tech Debt Is the Result of Success "Tech debt is often the result of success. Unsuccessful projects don't have tech debt." — Lou Franco   This reframes the entire conversation about tech debt. Failed products don't accumulate debt — they disappear before it matters. Tech debt emerges when your code survives long enough to outlive its original assumptions, when your user base grows beyond initial expectations, when your team scales faster than your architecture anticipated. At Atalasoft, they built for 10 users and got 100. At Trello, mobile usage exploded beyond their web-first assumptions. Success creates tech debt by changing the context in which code operates. This means tech debt conversations should happen at different intensities depending on where you are in the product lifecycle. Early startups pursuing product-market fit should minimize tech debt investments — move fast, learn, potentially throw away the code. Growth-stage companies need balanced approaches. Mature products benefit significantly from tech debt investments because operational efficiency compounds over years. Understanding this lifecycle perspective helps teams make appropriate decisions rather than applying one-size-fits-all rules. The 8 Questions Framework for Tech Debt Decisions "Those 8 questions guide you to what you should do. If it's risky, has regressions, and you don't even know if it's gonna work, this is when you're gonna do a project spike." — Lou Franco   Lou introduces a systematic framework for evaluating whether to pay tech debt, inspired by Bob Moesta's push-pull forces from product management. The 8 questions create a complete picture:   Visibility — Will people outside the team understand what we're doing? Alignment — Does this match our engineering values and target architecture? Resistance — How hard is this code to work with right now? Volatility — How often do we touch this code? Regression Risk — What's the chance we'll introduce new problems? Project Size — How big is this to fix? Estimate Risk — How uncertain are we about the effort required? Outcome Uncertainty — How confident are we the fix will actually improve things?   High volatility and high resistance with low regression risk? Pay the debt now. High regression risk with no tests? Write tests first, then reassess. Uncertain outcomes on a big project? Do a spike or proof of concept. The framework prevents both extremes — ignoring costly debt and undertaking risky rewrites without proper preparation. Personal Practices That Compound Daily "When I sit down at my desk, the first thing I do is I pay a little tech debt. I'm looking at code, I'm about to change it, do I even understand it? Am I having some kind of resistance to it? Put in a little helpful comment, maybe a little refactoring." — Lou Franco   Lou shares personal habits that create compounding improvements over time. Start each coding session by paying a small amount of tech debt in the area you're about to work — add a clarifying comment, extract a confusing variable, improve a function name. This warms you up, reduces friction for your actual work, and leaves the code slightly better than you found it. The clean-as-you-go philosophy means tech debt never accumulates faster than you can manage it. But Lou's most powerful practice comes at the end of each session: mutation testing by hand. Before finishing for the day, deliberately break something — change a plus to minus, a less-than to less-than-or-equal. See if tests catch it. Often they don't, revealing gaps in test coverage. The key insight: don't fix it immediately. Leave that failing test as the bridge to tomorrow's coding session. It connects today's momentum to tomorrow's work, ensuring you always start with context and purpose rather than cold-starting each day. Mutation Testing: Breaking Things on Purpose "Before I'm done working on a coding session, I break something on purpose. I'll change a plus to a minus, a less than to a less than equals, and see if tests break. A lot of times tests don't break. Now you've found a problem in your test." — Lou Franco   Manual mutation testing — deliberately breaking code to verify tests catch the break — reveals a critical gap in most test suites. You can have 100% code coverage and still have untested behavior. A line of code that's executed during tests isn't necessarily tested — the test might not actually verify what that line does. By changing operators, flipping booleans, or altering constants, you discover whether your tests protect against actual logic errors or just exercise code paths. Lou recommends doing this manually as part of your daily practice, but automated tools exist for systematic discovery: Stryker (for JavaScript, C#, Scala) and MutMut (for Python) can mutate your entire codebase and report which mutations survive uncaught. This isn't just about test quality — it's about understanding what your code actually does and building confidence that changes won't introduce subtle bugs. Team-Level Practices: Budgets, Backlogs, and Target Architecture "Create a target architecture document — where would we be if we started over today? Every PR is an opportunity to move slightly toward that target." — Lou Franco   At the team level, Lou advocates for three interconnected practices. First, create a target architecture document that describes where you'd be if starting fresh today — not a detailed design, but architectural patterns, technology choices, and structural principles that represent current best practices. This isn't a rewrite plan; it's a North Star. Every pull request becomes an opportunity to move incrementally toward that target when touching relevant code. Second, establish a budget split between PM-led feature work and engineering-led tech debt work — perhaps 80/20 or whatever ratio fits your product lifecycle stage. This creates predictable capacity for tech debt without requiring constant negotiation. Third, hold quarterly tech debt backlog meetings separate from sprint planning. Treat this backlog like PMs treat product discovery — explore options, estimate impacts, prioritize based on the 8 Questions framework. Some items fit in sprints; others require dedicated engineers for a quarter or two. This systematic approach prevents tech debt from being perpetually deprioritized while avoiding the opposite extreme of engineers disappearing into six-month "improvement" projects with no visible progress. The Atlassian Five-Alarm Fire "The Atlassian CTO's 'five-alarm fire' — stopping all feature development to focus on reliability. I reduced sync errors by 75% during that initiative." — Lou Franco   Lou shares a powerful example of leadership-driven tech debt management at scale. The Atlassian CTO called a "five-alarm fire" — halting all feature development across the company to focus exclusively on reliability and tech debt. This wasn't panic; it was strategic recognition that accumulated debt threatened the business. Lou worked on reducing sync errors, achieving a 75% reduction during this focused period. The initiative demonstrated several leadership principles: willingness to make hard calls that stop revenue-generating feature work, clear communication of why reliability matters strategically, trust that teams will use the time wisely, and commitment to see it through despite pressure to resume features. This level of intervention is rare and shouldn't be frequent, but it shows what's possible when leadership truly prioritizes tech debt. More commonly, leaders should express product lifecycle constraints (startup urgency vs. mature product stability), give teams autonomy to find appropriate projects within those constraints, and require accountability through visible metrics and dashboards that show progress. The Rewrite Trap: Why Big Rewrites Usually Fail "A system that took 10 years to write has implicit knowledge that can't be replicated in 6 months. I'm mostly gonna advocate for piecemeal migrations along the way, reducing the size of the problem over time." — Lou Franco   Lou lived through Trello's iOS navigation rewrite — a classic example of throwing away working code to start fresh, only to discover all the edge cases, implicit behaviors, and user expectations baked into the "old" system. A codebase that evolved over several years contains implicit knowledge — user workflows, edge case handling, performance optimizations, and subtle behaviors that users rely on even if they never explicitly requested them. Attempting to rewrite this in six months inevitably misses critical details. Lou strongly advocates for piecemeal migrations instead. The Trello "Decaffeinate Project" exemplifies this approach — migrating from CoffeeScript to TypeScript incrementally, with public dashboards showing the percentage remaining, interoperable technologies allowing gradual transition, and the ability to pause or reverse if needed. Keep both systems running in parallel during migrations. Use runtime observability to verify new code behaves identically to old code. Reduce the problem size steadily over months rather than attempting big-bang replacements. The only exception: sometimes keeping parallel systems requires scaffolding that creates its own complexity, so evaluate whether piecemeal migration is actually simpler or if you're better off living with the current system. Making Tech Debt Visible Through Dashboards "Put up a dashboard, showing it happen. Make invisible internal improvements visible through metrics engineering leadership understands." — Lou Franco   One of tech debt's biggest challenges is invisibility — non-technical stakeholders can't see the improvement from refactoring or test coverage. Lou learned to make tech debt work visible through dashboards and metrics. The Decaffeinate Project tracked percentage of CoffeeScript files remaining, providing a clear progress indicator anyone could understand. When reducing sync errors, Lou created dashboards showing error rates declining over time. These visualizations serve multiple purposes: they demonstrate value to leadership, create accountability for engineering teams, build momentum as progress becomes visible, and help teams celebrate wins that would otherwise go unnoticed. The key is choosing metrics that matter to the business — error rates, page load times, deployment frequency, mean time to recovery — rather than pure code quality metrics like cyclomatic complexity that don't translate outside engineering. Connect tech debt work to customer experience, reliability, or developer productivity in ways leadership can see and value. Onboarding as a Tech Debt Opportunity "Unit testing is a really great way to learn a system. It's like an executable specification that's helping you prove that you understand the system." — Lou Franco   Lou identifies onboarding as an underutilized opportunity for tech debt reduction. When new engineers join, they need to learn the codebase. Rather than just reading code or shadowing, Lou suggests having them write unit tests in areas they're learning. This serves dual purposes: tests are executable specifications that prove understanding of system behavior, and they create safety nets in areas that likely lack coverage (otherwise, why would new engineers be confused by the code?). The new engineer gets hands-on learning, the team gets better test coverage, and everyone wins. This practice also surfaces confusing code — if new engineers struggle to understand what to test, that's a signal the code needs clarifying comments, better naming, or refactoring. Make onboarding a systematic tech debt reduction opportunity rather than passive knowledge transfer. Leadership's Role: Constraints, Autonomy, and Accountability "Leadership needs to express the constraints. Tell the team what you're feeling about tech debt at a high level, and what you think generally is the appropriate amount of time to be spent on it. Then give them autonomy." — Lou Franco   Lou distills leadership's role in tech debt management to three elements. First, express constraints — communicate where you believe the product is in its lifecycle (early startup, rapid growth, mature cash cow) and what that means for tech debt tolerance. Are we pursuing product-market fit where code might be thrown away? Are we scaling a proven product where reliability matters? Are we maintaining a stable system where operational efficiency pays dividends? These constraints help teams make appropriate trade-offs. Second, give autonomy — once constraints are clear, trust teams to identify specific tech debt projects that fit those constraints. Engineers understand the codebase's pain points better than leaders do. Third, require accountability — teams must make their work visible through dashboards, metrics, and regular updates. Autonomy without accountability becomes invisible engineering projects that might not deliver value. Accountability without autonomy becomes micromanagement that wastes engineering judgment. The balance creates space for teams to make smart decisions while keeping leadership informed and confident in the investment. AI and the Future of Tech Debt "I really do AI-assisted software engineering. And by that, I mean I 100% review every single line of that code. I write the tests, and all the code is as I would have written it, it's just a lot faster. Developers are still responsible for it. Read the code." — Lou Franco   Lou has a chapter about AI in his book, addressing the elephant in the room: will AI-generated code create massive tech debt? His answer is nuanced. AI can accelerate development tremendously if used correctly — Lou uses it extensively but reviews every single line, writes all tests himself, and ensures the code matches what he would have written manually. The problem emerges with "vibe coders" — non-developers using AI to generate code they don't understand, creating unmaintainable messes that become someone else's problem. Developers remain responsible for all code, regardless of how it's generated. This means you must read and understand AI-generated code, not blindly accept it. Lou also raises supply chain security concerns — dependencies can contain malicious code, and AI might introduce vulnerabilities developers miss. His recommendation: stay six months behind on dependency updates, let others discover the problems first, and consider separate sandboxed development machines to limit security exposure. AI is a powerful tool, but it doesn't eliminate the need for engineering judgment, testing discipline, or code review practices. The Style Guide Beyond Formatting "Have a style guide that goes beyond formatting to include target architecture. This is the kind of code we want to write going forward." — Lou Franco   Lou advocates for style guides that extend beyond tabs-versus-spaces formatting rules to include architectural guidance. Document patterns you want to move toward: how should components be structured, what state management approaches do we prefer, how should we handle errors, what testing patterns should we follow? This creates a shared understanding of the target architecture without requiring a massive design document. When reviewing pull requests, teams can reference the style guide to explain why certain approaches align with where the codebase is headed versus perpetuating old patterns. This makes tech debt conversations less personal and more objective — it's not about criticizing someone's code, it's about aligning with team standards and strategic direction. The style guide becomes a living document that evolves as the team learns and technology changes, capturing collective wisdom about what good code looks like in your specific context. Recommended Resources Some of the resources mentioned in this episode include:  Steve Blank's Four Steps To Epiphany The podcast episode with Bernie Maloney where we discuss the critical difference between "enterprise" and "startup". And Geoffrey Moore's Crossing the Chasm, and Dealing with Darwin.   About Lou Franco   Lou Franco is a veteran software engineer and author of Swimming in Tech Debt. With decades of experience at startups, as well as Trello, and Atlassian, he's seen both sides of debt—as coder and leader. Today, he advises teams on engineering practices, helping them turn messy codebases into momentum.   You can link with Lou Franco on LinkedIn and learn more at LouFranco.com.