Podcasts about programming languages

Intro topic: Video Game PricesNews/Links:Step one: Jump in the Lava - Abyssofthttps://youtu.be/WdadpHLAfdA?si=oXYnhB0EdkR_RaPEScalable world models for continuous controlhttps://www.tdmpc2.com/Clever code is probably the worst code you could write - Engineer's Codexhttps://read.engineerscodex.com/p/clever-code-is-probably-the-worstA new, open source text-to-speech model called Dia has arrived to challenge ElevenLabs, OpenAI and morehttps://venturebeat.com/ai/a-new-open-source-text-to-speech-model-called-dia-has-arrived-to-challenge-elevenlabs-openai-and-more/Book of the ShowPatrickThe Muscle Ladder - Jeff Nippardhttps://amzn.to/44DznszJasonMetaphysics of Warhttps://amzn.to/4jMjvZ5Patreon Plug https://www.patreon.com/programmingthrowdown?ty=hTool of the ShowPatrickPokemon Trading Card Game PocketJasonPhi-4https://huggingface.co/spaces/microsoft/phi-4-multimodalTopic: Memory ManagementMotivationAvoid thrashing / crashesAllocate resources efficientlyKeep high uptimeWhereOS LevelHeap managementVirtual MemoryLanguage/Compiler LevelCppGarbage collectionOwnershipToolsInstrumentationExport to Datadog / GrafanaPython: psutil & tracemallocValgrindWhat to do when your program uses too much memory?Reduce data sizesCompressionReferencesLazy initializerGenerators & Back PressureRing buffersArena allocatorsDisk based caching ★ Support this podcast on Patreon ★

Apologies for the hiatus! Dave needed some time off to recover from burnout, and these episodes remained in the can. Thanks for Waiting for us

In this episode of Project Synapse, join our group of AI-obsessed IT professionals as they discuss the intriguing concept of AI-generated code, specifically focusing on 'vibe coding.' Marcel Gagne, a former system administrator turned author, dives deep into the history and potential of writing code through AI. The episode covers the evolution from early programming languages like COBOL and Fortran to modern AI coding tools like Cursor and Firebase. Discover how AI tools aid in prototyping, personal productivity, and the future possibilities in enterprise-level applications. The team also explores security implications, testing methodologies, and the importance of responsible AI use in development. Tune in to learn about the present and future impact of AI on programming and systems development. 00:00 Introduction to Project Synapse 00:36 Meet the Hosts 02:53 The Evolution of Programming Languages 08:27 The Rise of Vibe Coding 14:00 Practical Applications and Experiences 19:54 Advanced Tools and IDEs 22:39 Challenges and Solutions in AI Coding 29:56 Starting Fresh: The Importance of Context 33:04 Introduction to Programming by Kenny Rogers 33:28 Legendary Programmer John Carmack 33:38 AI in Game Development 34:19 Nostalgia for Classic Games 35:59 The Evolution of Game Engines 38:04 AI's Role in Modern Coding 38:36 Proof of Concept and Rapid Prototyping 44:20 Security Concerns with AI-Generated Code 50:06 The Future of AI in Enterprise Systems 01:00:27 The Importance of Testing and Security 01:03:44 Final Thoughts and Recommendations

Prof. Kevin Ellis and Dr. Zenna Tavares talk about making AI smarter, like humans. They want AI to learn from just a little bit of information by actively trying things out, not just by looking at tons of data.They discuss two main ways AI can "think": one way is like following specific rules or steps (like a computer program), and the other is more intuitive, like guessing based on patterns (like modern AI often does). They found combining both methods works well for solving complex puzzles like ARC.A key idea is "compositionality" - building big ideas from small ones, like LEGOs. This is powerful but can also be overwhelming. Another important idea is "abstraction" - understanding things simply, without getting lost in details, and knowing there are different levels of understanding.Ultimately, they believe the best AI will need to explore, experiment, and build models of the world, much like humans do when learning something new.SPONSOR MESSAGES:***Tufa AI Labs is a brand new research lab in Zurich started by Benjamin Crouzier focussed on o-series style reasoning and AGI. They are hiring a Chief Engineer and ML engineers. Events in Zurich. Goto https://tufalabs.ai/***TRANSCRIPT:https://www.dropbox.com/scl/fi/3ngggvhb3tnemw879er5y/BASIS.pdf?rlkey=lr2zbj3317mex1q5l0c2rsk0h&dl=0 Zenna Tavares:http://www.zenna.org/Kevin Ellis:https://www.cs.cornell.edu/~ellisk/TOC:1. Compositionality and Learning Foundations [00:00:00] 1.1 Compositional Search and Learning Challenges [00:03:55] 1.2 Bayesian Learning and World Models [00:12:05] 1.3 Programming Languages and Compositionality Trade-offs [00:15:35] 1.4 Inductive vs Transductive Approaches in AI Systems2. Neural-Symbolic Program Synthesis [00:27:20] 2.1 Integration of LLMs with Traditional Programming and Meta-Programming [00:30:43] 2.2 Wake-Sleep Learning and DreamCoder Architecture [00:38:26] 2.3 Program Synthesis from Interactions and Hidden State Inference [00:41:36] 2.4 Abstraction Mechanisms and Resource Rationality [00:48:38] 2.5 Inductive Biases and Causal Abstraction in AI Systems3. Abstract Reasoning Systems [00:52:10] 3.1 Abstract Concepts and Grid-Based Transformations in ARC [00:56:08] 3.2 Induction vs Transduction Approaches in Abstract Reasoning [00:59:12] 3.3 ARC Limitations and Interactive Learning Extensions [01:06:30] 3.4 Wake-Sleep Program Learning and Hybrid Approaches [01:11:37] 3.5 Project MARA and Future Research DirectionsREFS:[00:00:25] DreamCoder, Kevin Ellis et al.https://arxiv.org/abs/2006.08381[00:01:10] Mind Your Step, Ryan Liu et al.https://arxiv.org/abs/2410.21333[00:06:05] Bayesian inference, Griffiths, T. L., Kemp, C., & Tenenbaum, J. B.https://psycnet.apa.org/record/2008-06911-003[00:13:00] Induction and Transduction, Wen-Ding Li, Zenna Tavares, Yewen Pu, Kevin Ellishttps://arxiv.org/abs/2411.02272[00:23:15] Neurosymbolic AI, Garcez, Artur d'Avila et al.https://arxiv.org/abs/2012.05876[00:33:50] Induction and Transduction (II), Wen-Ding Li, Kevin Ellis et al.https://arxiv.org/abs/2411.02272[00:38:35] ARC, François Chollethttps://arxiv.org/abs/1911.01547[00:39:20] Causal Reactive Programs, Ria Das, Joshua B. Tenenbaum, Armando Solar-Lezama, Zenna Tavareshttp://www.zenna.org/publications/autumn2022.pdf[00:42:50] MuZero, Julian Schrittwieser et al.http://arxiv.org/pdf/1911.08265[00:43:20] VisualPredicator, Yichao Lianghttps://arxiv.org/abs/2410.23156[00:48:55] Bayesian models of cognition, Joshua B. Tenenbaumhttps://mitpress.mit.edu/9780262049412/bayesian-models-of-cognition/[00:49:30] The Bitter Lesson, Rich Suttonhttp://www.incompleteideas.net/IncIdeas/BitterLesson.html[01:06:35] Program induction, Kevin Ellis, Wen-Ding Lihttps://arxiv.org/pdf/2411.02272[01:06:50] DreamCoder (II), Kevin Ellis et al.https://arxiv.org/abs/2006.08381[01:11:55] Project MARA, Zenna Tavares, Kevin Ellishttps://www.basis.ai/blog/mara/

Guy Royse, dev advocate at Redis, discusses going beyond the cache with Redis and Node.js. He explores its capabilities as a memory-first database, session management, and even fun use cases like the Bigfoot Tracker API. He also shares insights on Redis OM for object mapping and its future in the JavaScript ecosystem. Links http://guyroyse.com http://github.com/guyroyse https://www.twitch.tv/guyroyse https://www.youtube.com/channel/UCNt5SDc6LosO41E77jr59cQ https://x.com/guyroyse https://www.linkedin.com/in/groyse https://2024.connect.tech/session/693665 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? Let us know by sending an email to our producer, Emily, at emily.kochanekketner@logrocket.com (mailto:emily.kochanekketner@logrocket.com), or tweet at us at PodRocketPod (https://twitter.com/PodRocketpod). 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 understand where your users are struggling by trying it for free at [LogRocket.com]. Try LogRocket for free today.(https://logrocket.com/signup/?pdr) Special Guest: Guy Royse.

In this week's episode, the crew play Real or Fake for esoteric programming languages. Are Whitespace, JSF***, Cow or DeadFish real or fake? Listen to find out.Follow the show and be sure to join the discussion on Discord! Our website is workingcode.dev and we're @workingcode.dev on Bluesky. New episodes drop weekly on Wednesday.And, if you're feeling the love, support us on Patreon.With audio editing and engineering by ZCross Media.Full show notes and transcript here.

The AI arms race is on, and the stakes couldn't be higher. Bankless podcast producer Josh Kale breaks down which players are poised to dominate this next industrial revolution. From the transformative power of AI across industries to the geopolitical and economic implications, we explore the critical dynamics shaping our technological future—and what this means for investors, builders, and society at large. ------

The rise of the World Wide Web enabled developers to build tools and platforms on top of it. Similarly, the advent of large language models (LLMs) allows for creating new AI-driven tools, such as autonomous agents that interact with LLMs, execute tasks, and make decisions. However, verifying these decisions is crucial, and critical reasoning may be a solution, according to Yam Marcovitz, tech lead at Parlant.io and CEO of emcie.co.Marcovitz likens LLM development to the evolution of programming languages, from punch cards to modern languages like Python. Early LLMs started with small transformer models, leading to systems like BERT and GPT-3. Now, instead of mere text auto-completion, models are evolving to enable better reasoning and complex instructions.Parlant uses "attentive reasoning queries (ARQs)" to maintain consistency in AI responses, ensuring near-perfect accuracy. Their approach balances structure and flexibility, preventing models from operating entirely autonomously. Ultimately, Marcovitz argues that subjectivity in human interpretation extends to LLMs, making perfect objectivity unrealistic.Learn more from The New Stack about the evolution of LLMs: AI Alignment in Practice: What It Means and How to Get It Agentic AI: The Next Frontier of AI Power Make the Most of AI Agents: Tips and Tricks for Developers Join our community of newsletter subscribers to stay on top of the news and at the top of your game. 

This show has been flagged as Clean by the host. What is Scratch? Who made it? How does it work? What can it do? What are the blocks and how they relate to coding? Can be dragged and placed Different shapes/colours represent different aspects Round ones are analogous to Functions Sharp ones are variables Control ones are Logic/Conditions Why is this good? Allows kids to focus on logic and the mindset of coding without having to learn or care about Syntax/lines of code Allows for direct visualisation of what the code does My own experience Started with blocks in Lego Mindstorm Evolved to C HTML/PHP and then Python The workshop Kids made 2 games that covered all basics Triggers/Input Functions Variables Were all customised by them Explain that each kid made their version the football crazy one turned my cat and balloon game into a Football Match They got to take them home The games covered the basics on this way Input using keyboard for triggering functions Use Functions to modify location parameters If/Then Conditions for when sprites are touching each other/the walls Variables for storing points Operands to increase Points in variable End conditions Loops for permanently checking the If/Then Conditions Ask about the organisation Mora Mundus Download and learn more about Scratch . Provide feedback on this episode.

Programming Language Evolution: Data-Driven Analysis of Future TrendsEpisode OverviewAnalysis of programming language rankings through the lens of modern requirements, adjusting popularity metrics with quantitative factors including safety features, energy efficiency, and temporal relevance.Key Segments1. Traditional Rankings Limitations (00:00-01:53)TIOBE Index raw rankings examinedPython dominance (23.88% market share) analyzedDiscussion of interpretted language limitationsHistorical context of legacy languagesC++ performance characteristics vs safety trade-offs2. Current Market Leaders Analysis (01:53-04:21)Detailed breakdown of top languages:Python (23.88%): Interpretted, dynamic typingC++ (11.37%): Performance focusedJava (10.66%): JVM-basedC (9.84%): Systems levelC# (4.12%): Microsoft ecosystemJavaScript (3.78%): Web-focusedSQL (2.87%): Domain-specificGo (2.26%): Modern compiledDelphi (2.18%): Object PascalVisual Basic (2.04%): Legacy managed3. Modern Requirements Deep Dive (04:21-06:32)Energy efficiency considerationsMemory safety paradigmsConcurrency support analysisPackage management evolutionModern compilation techniques4. Future-Oriented Rankings (06:32-08:38)RustMemory safety without GCOwnership/borrowing systemAdvanced concurrency primitivesCargo package managementGoCloud infrastructure optimizationGoroutine-based concurrencySimplified systems programmingEnergy efficient garbage collectionZigManual memory managementCompile-time featuresSystems/embedded focusModern C alternativeSwiftARC memory managementStrong type systemModern language featuresPerformance optimizationCarbon/MojoExperimental successorsModern safety featuresPerformance characteristicsNext-generation compilation5. Future Predictions (08:38-10:51)Shift away from legacy languagesFocus on energy efficiencySafety-first design principlesCompilation vs interpretationAI/ML impact on language designKey InsightsLanguage Evolution MetricsSafety featuresEnergy efficiencyModern compilation techniquesPackage managementConcurrency supportLegacy Language ChallengesTechnical debtPerformance limitationsSafety compromisesEnergy inefficiencyPackage management complexityFuture-Focused FeaturesMemory safety guaranteesConcurrent computationEnergy optimizationModern tooling integrationAI/ML compatibilityProduction NotesTarget AudienceProfessional developersTechnical architectsSystem designersSoftware engineering studentsKey Timestamps00:54 - TIOBE Index introduction04:21 - Modern language requirements06:32 - Future-oriented rankings08:38 - Predictions and analysis10:34 - Concluding insightsFollow-up Episode TopicsDeep dive into Rust vs Go trade-offsEnergy efficiency benchmarkingMemory safety paradigms comparisonModern compilation techniquesAI/ML impact on language design

If you're in SF, join us tomorrow for a fun meetup at CodeGen Night!If you're in NYC, join us for AI Engineer Summit! The Agent Engineering track is now sold out, but 25 tickets remain for AI Leadership and 5 tickets for the workshops. You can see the full schedule of speakers and workshops at https://ai.engineer!It's exceedingly hard to introduce someone like Bret Taylor. We could recite his Wikipedia page, or his extensive work history through Silicon Valley's greatest companies, but everyone else already does that.As a podcast by AI engineers for AI engineers, we had the opportunity to do something a little different. We wanted to dig into what Bret sees from his vantage point at the top of our industry for the last 2 decades, and how that explains the rise of the AI Architect at Sierra, the leading conversational AI/CX platform.“Across our customer base, we are seeing a new role emerge - the role of the AI architect. These leaders are responsible for helping define, manage and evolve their company's AI agent over time. They come from a variety of both technical and business backgrounds, and we think that every company will have one or many AI architects managing their AI agent and related experience.”In our conversation, Bret Taylor confirms the Paul Buchheit legend that he rewrote Google Maps in a weekend, armed with only the help of a then-nascent Google Closure Compiler and no other modern tooling. But what we find remarkable is that he was the PM of Maps, not an engineer, though of course he still identifies as one. We find this theme recurring throughout Bret's career and worldview. We think it is plain as day that AI leadership will have to be hands-on and technical, especially when the ground is shifting as quickly as it is today:“There's a lot of power in combining product and engineering into as few people as possible… few great things have been created by committee.”“If engineering is an order taking organization for product you can sometimes make meaningful things, but rarely will you create extremely well crafted breakthrough products. Those tend to be small teams who deeply understand the customer need that they're solving, who have a maniacal focus on outcomes.”“And I think the reason why is if you look at like software as a service five years ago, maybe you can have a separation of product and engineering because most software as a service created five years ago. I wouldn't say there's like a lot of technological breakthroughs required for most business applications. And if you're making expense reporting software or whatever, it's useful… You kind of know how databases work, how to build auto scaling with your AWS cluster, whatever, you know, it's just, you're just applying best practices to yet another problem. "When you have areas like the early days of mobile development or the early days of interactive web applications, which I think Google Maps and Gmail represent, or now AI agents, you're in this constant conversation with what the requirements of your customers and stakeholders are and all the different people interacting with it and the capabilities of the technology. And it's almost impossible to specify the requirements of a product when you're not sure of the limitations of the technology itself.”This is the first time the difference between technical leadership for “normal” software and for “AI” software was articulated this clearly for us, and we'll be thinking a lot about this going forward. We left a lot of nuggets in the conversation, so we hope you'll just dive in with us (and thank Bret for joining the pod!)Timestamps* 00:00:02 Introductions and Bret Taylor's background* 00:01:23 Bret's experience at Stanford and the dot-com era* 00:04:04 The story of rewriting Google Maps backend* 00:11:06 Early days of interactive web applications at Google* 00:15:26 Discussion on product management and engineering roles* 00:21:00 AI and the future of software development* 00:26:42 Bret's approach to identifying customer needs and building AI companies* 00:32:09 The evolution of business models in the AI era* 00:41:00 The future of programming languages and software development* 00:49:38 Challenges in precisely communicating human intent to machines* 00:56:44 Discussion on Artificial General Intelligence (AGI) and its impact* 01:08:51 The future of agent-to-agent communication* 01:14:03 Bret's involvement in the OpenAI leadership crisis* 01:22:11 OpenAI's relationship with Microsoft* 01:23:23 OpenAI's mission and priorities* 01:27:40 Bret's guiding principles for career choices* 01:29:12 Brief discussion on pasta-making* 01:30:47 How Bret keeps up with AI developments* 01:32:15 Exciting research directions in AI* 01:35:19 Closing remarks and hiring at Sierra Transcript[00:02:05] Introduction and Guest Welcome[00:02:05] Alessio: Hey everyone, welcome to the Latent Space Podcast. This is Alessio, partner and CTO at Decibel Partners, and I'm joined by my co host swyx, founder of smol.ai.[00:02:17] swyx: Hey, and today we're super excited to have Bret Taylor join us. Welcome. Thanks for having me. It's a little unreal to have you in the studio.[00:02:25] swyx: I've read about you so much over the years, like even before. Open AI effectively. I mean, I use Google Maps to get here. So like, thank you for everything that you've done. Like, like your story history, like, you know, I think people can find out what your greatest hits have been.[00:02:40] Bret Taylor's Early Career and Education[00:02:40] swyx: How do you usually like to introduce yourself when, you know, you talk about, you summarize your career, like, how do you look at yourself?[00:02:47] Bret: Yeah, it's a great question. You know, we, before we went on the mics here, we're talking about the audience for this podcast being more engineering. And I do think depending on the audience, I'll introduce myself differently because I've had a lot of [00:03:00] corporate and board roles. I probably self identify as an engineer more than anything else though.[00:03:04] Bret: So even when I was. Salesforce, I was coding on the weekends. So I think of myself as an engineer and then all the roles that I do in my career sort of start with that just because I do feel like engineering is sort of a mindset and how I approach most of my life. So I'm an engineer first and that's how I describe myself.[00:03:24] Bret: You majored in computer[00:03:25] swyx: science, like 1998. And, and I was high[00:03:28] Bret: school, actually my, my college degree was Oh, two undergrad. Oh, three masters. Right. That old.[00:03:33] swyx: Yeah. I mean, no, I was going, I was going like 1998 to 2003, but like engineering wasn't as, wasn't a thing back then. Like we didn't have the title of senior engineer, you know, kind of like, it was just.[00:03:44] swyx: You were a programmer, you were a developer, maybe. What was it like in Stanford? Like, what was that feeling like? You know, was it, were you feeling like on the cusp of a great computer revolution? Or was it just like a niche, you know, interest at the time?[00:03:57] Stanford and the Dot-Com Bubble[00:03:57] Bret: Well, I was at Stanford, as you said, from 1998 to [00:04:00] 2002.[00:04:02] Bret: 1998 was near the peak of the dot com bubble. So. This is back in the day where most people that they're coding in the computer lab, just because there was these sun microsystems, Unix boxes there that most of us had to do our assignments on. And every single day there was a. com like buying pizza for everybody.[00:04:20] Bret: I didn't have to like, I got. Free food, like my first two years of university and then the dot com bubble burst in the middle of my college career. And so by the end there was like tumbleweed going to the job fair, you know, it was like, cause it was hard to describe unless you were there at the time, the like level of hype and being a computer science major at Stanford was like, A thousand opportunities.[00:04:45] Bret: And then, and then when I left, it was like Microsoft, IBM.[00:04:49] Joining Google and Early Projects[00:04:49] Bret: And then the two startups that I applied to were VMware and Google. And I ended up going to Google in large part because a woman named Marissa Meyer, who had been a teaching [00:05:00] assistant when I was, what was called a section leader, which was like a junior teaching assistant kind of for one of the big interest.[00:05:05] Bret: Yes. Classes. She had gone there. And she was recruiting me and I knew her and it was sort of felt safe, you know, like, I don't know. I thought about it much, but it turned out to be a real blessing. I realized like, you know, you always want to think you'd pick Google if given the option, but no one knew at the time.[00:05:20] Bret: And I wonder if I'd graduated in like 1999 where I've been like, mom, I just got a job at pets. com. It's good. But you know, at the end I just didn't have any options. So I was like, do I want to go like make kernel software at VMware? Do I want to go build search at Google? And I chose Google. 50, 50 ball.[00:05:36] Bret: I'm not really a 50, 50 ball. So I feel very fortunate in retrospect that the economy collapsed because in some ways it forced me into like one of the greatest companies of all time, but I kind of lucked into it, I think.[00:05:47] The Google Maps Rewrite Story[00:05:47] Alessio: So the famous story about Google is that you rewrote the Google maps back in, in one week after the map quest quest maps acquisition, what was the story there?[00:05:57] Alessio: Is it. Actually true. Is it [00:06:00] being glorified? Like how, how did that come to be? And is there any detail that maybe Paul hasn't shared before?[00:06:06] Bret: It's largely true, but I'll give the color commentary. So it was actually the front end, not the back end, but it turns out for Google maps, the front end was sort of the hard part just because Google maps was.[00:06:17] Bret: Largely the first ish kind of really interactive web application, say first ish. I think Gmail certainly was though Gmail, probably a lot of people then who weren't engineers probably didn't appreciate its level of interactivity. It was just fast, but. Google maps, because you could drag the map and it was sort of graphical.[00:06:38] Bret: My, it really in the mainstream, I think, was it a map[00:06:41] swyx: quest back then that was, you had the arrows up and down, it[00:06:44] Bret: was up and down arrows. Each map was a single image and you just click left and then wait for a few seconds to the new map to let it was really small too, because generating a big image was kind of expensive on computers that day.[00:06:57] Bret: So Google maps was truly innovative in that [00:07:00] regard. The story on it. There was a small company called where two technologies started by two Danish brothers, Lars and Jens Rasmussen, who are two of my closest friends now. They had made a windows app called expedition, which had beautiful maps. Even in 2000.[00:07:18] Bret: For whenever we acquired or sort of acquired their company, Windows software was not particularly fashionable, but they were really passionate about mapping and we had made a local search product that was kind of middling in terms of popularity, sort of like a yellow page of search product. So we wanted to really go into mapping.[00:07:36] Bret: We'd started working on it. Their small team seemed passionate about it. So we're like, come join us. We can build this together.[00:07:42] Technical Challenges and Innovations[00:07:42] Bret: It turned out to be a great blessing that they had built a windows app because you're less technically constrained when you're doing native code than you are building a web browser, particularly back then when there weren't really interactive web apps and it ended up.[00:07:56] Bret: Changing the level of quality that we [00:08:00] wanted to hit with the app because we were shooting for something that felt like a native windows application. So it was a really good fortune that we sort of, you know, their unusual technical choices turned out to be the greatest blessing. So we spent a lot of time basically saying, how can you make a interactive draggable map in a web browser?[00:08:18] Bret: How do you progressively load, you know, new map tiles, you know, as you're dragging even things like down in the weeds of the browser at the time, most browsers like Internet Explorer, which was dominant at the time would only load two images at a time from the same domain. So we ended up making our map tile servers have like.[00:08:37] Bret: Forty different subdomains so we could load maps and parallels like lots of hacks. I'm happy to go into as much as like[00:08:44] swyx: HTTP connections and stuff.[00:08:46] Bret: They just like, there was just maximum parallelism of two. And so if you had a map, set of map tiles, like eight of them, so So we just, we were down in the weeds of the browser anyway.[00:08:56] Bret: So it was lots of plumbing. I can, I know a lot more about browsers than [00:09:00] most people, but then by the end of it, it was fairly, it was a lot of duct tape on that code. If you've ever done an engineering project where you're not really sure the path from point A to point B, it's almost like. Building a house by building one room at a time.[00:09:14] Bret: The, there's not a lot of architectural cohesion at the end. And then we acquired a company called Keyhole, which became Google earth, which was like that three, it was a native windows app as well, separate app, great app, but with that, we got licenses to all this satellite imagery. And so in August of 2005, we added.[00:09:33] Bret: Satellite imagery to Google Maps, which added even more complexity in the code base. And then we decided we wanted to support Safari. There was no mobile phones yet. So Safari was this like nascent browser on, on the Mac. And it turns out there's like a lot of decisions behind the scenes, sort of inspired by this windows app, like heavy use of XML and XSLT and all these like.[00:09:54] Bret: Technologies that were like briefly fashionable in the early two thousands and everyone hates now for good [00:10:00] reason. And it turns out that all of the XML functionality and Internet Explorer wasn't supporting Safari. So people are like re implementing like XML parsers. And it was just like this like pile of s**t.[00:10:11] Bret: And I had to say a s**t on your part. Yeah, of[00:10:12] Alessio: course.[00:10:13] Bret: So. It went from this like beautifully elegant application that everyone was proud of to something that probably had hundreds of K of JavaScript, which sounds like nothing. Now we're talking like people have modems, you know, not all modems, but it was a big deal.[00:10:29] Bret: So it was like slow. It took a while to load and just, it wasn't like a great code base. Like everything was fragile. So I just got. Super frustrated by it. And then one weekend I did rewrite all of it. And at the time the word JSON hadn't been coined yet too, just to give you a sense. So it's all XML.[00:10:47] swyx: Yeah.[00:10:47] Bret: So we used what is now you would call JSON, but I just said like, let's use eval so that we can parse the data fast. And, and again, that's, it would literally as JSON, but at the time there was no name for it. So we [00:11:00] just said, let's. Pass on JavaScript from the server and eval it. And then somebody just refactored the whole thing.[00:11:05] Bret: And, and it wasn't like I was some genius. It was just like, you know, if you knew everything you wished you had known at the beginning and I knew all the functionality, cause I was the primary, one of the primary authors of the JavaScript. And I just like, I just drank a lot of coffee and just stayed up all weekend.[00:11:22] Bret: And then I, I guess I developed a bit of reputation and no one knew about this for a long time. And then Paul who created Gmail and I ended up starting a company with him too, after all of this told this on a podcast and now it's large, but it's largely true. I did rewrite it and it, my proudest thing.[00:11:38] Bret: And I think JavaScript people appreciate this. Like the un G zipped bundle size for all of Google maps. When I rewrote, it was 20 K G zipped. It was like much smaller for the entire application. It went down by like 10 X. So. What happened on Google? Google is a pretty mainstream company. And so like our usage is shot up because it turns out like it's faster.[00:11:57] Bret: Just being faster is worth a lot of [00:12:00] percentage points of growth at a scale of Google. So how[00:12:03] swyx: much modern tooling did you have? Like test suites no compilers.[00:12:07] Bret: Actually, that's not true. We did it one thing. So I actually think Google, I, you can. Download it. There's a, Google has a closure compiler, a closure compiler.[00:12:15] Bret: I don't know if anyone still uses it. It's gone. Yeah. Yeah. It's sort of gone out of favor. Yeah. Well, even until recently it was better than most JavaScript minifiers because it was more like it did a lot more renaming of variables and things. Most people use ES build now just cause it's fast and closure compilers built on Java and super slow and stuff like that.[00:12:37] Bret: But, so we did have that, that was it. Okay.[00:12:39] The Evolution of Web Applications[00:12:39] Bret: So and that was treated internally, you know, it was a really interesting time at Google at the time because there's a lot of teams working on fairly advanced JavaScript when no one was. So Google suggest, which Kevin Gibbs was the tech lead for, was the first kind of type ahead, autocomplete, I believe in a web browser, and now it's just pervasive in search boxes that you sort of [00:13:00] see a type ahead there.[00:13:01] Bret: I mean, chat, dbt[00:13:01] swyx: just added it. It's kind of like a round trip.[00:13:03] Bret: Totally. No, it's now pervasive as a UI affordance, but that was like Kevin's 20 percent project. And then Gmail, Paul you know, he tells the story better than anyone, but he's like, you know, basically was scratching his own itch, but what was really neat about it is email, because it's such a productivity tool, just needed to be faster.[00:13:21] Bret: So, you know, he was scratching his own itch of just making more stuff work on the client side. And then we, because of Lars and Yen sort of like setting the bar of this windows app or like we need our maps to be draggable. So we ended up. Not only innovate in terms of having a big sync, what would be called a single page application today, but also all the graphical stuff you know, we were crashing Firefox, like it was going out of style because, you know, when you make a document object model with the idea that it's a document and then you layer on some JavaScript and then we're essentially abusing all of this, it just was running into code paths that were not.[00:13:56] Bret: Well, it's rotten, you know, at this time. And so it was [00:14:00] super fun. And, and, you know, in the building you had, so you had compilers, people helping minify JavaScript just practically, but there is a great engineering team. So they were like, that's why Closure Compiler is so good. It was like a. Person who actually knew about programming languages doing it, not just, you know, writing regular expressions.[00:14:17] Bret: And then the team that is now the Chrome team believe, and I, I don't know this for a fact, but I'm pretty sure Google is the main contributor to Firefox for a long time in terms of code. And a lot of browser people were there. So every time we would crash Firefox, we'd like walk up two floors and say like, what the hell is going on here?[00:14:35] Bret: And they would load their browser, like in a debugger. And we could like figure out exactly what was breaking. And you can't change the code, right? Cause it's the browser. It's like slow, right? I mean, slow to update. So, but we could figure out exactly where the bug was and then work around it in our JavaScript.[00:14:52] Bret: So it was just like new territory. Like so super, super fun time, just like a lot of, a lot of great engineers figuring out [00:15:00] new things. And And now, you know, the word, this term is no longer in fashion, but the word Ajax, which was asynchronous JavaScript and XML cause I'm telling you XML, but see the word XML there, to be fair, the way you made HTTP requests from a client to server was this.[00:15:18] Bret: Object called XML HTTP request because Microsoft and making Outlook web access back in the day made this and it turns out to have nothing to do with XML. It's just a way of making HTTP requests because XML was like the fashionable thing. It was like that was the way you, you know, you did it. But the JSON came out of that, you know, and then a lot of the best practices around building JavaScript applications is pre React.[00:15:44] Bret: I think React was probably the big conceptual step forward that we needed. Even my first social network after Google, we used a lot of like HTML injection and. Making real time updates was still very hand coded and it's really neat when you [00:16:00] see conceptual breakthroughs like react because it's, I just love those things where it's like obvious once you see it, but it's so not obvious until you do.[00:16:07] Bret: And actually, well, I'm sure we'll get into AI, but I, I sort of feel like we'll go through that evolution with AI agents as well that I feel like we're missing a lot of the core abstractions that I think in 10 years we'll be like, gosh, how'd you make agents? Before that, you know, but it was kind of that early days of web applications.[00:16:22] swyx: There's a lot of contenders for the reactive jobs of of AI, but no clear winner yet. I would say one thing I was there for, I mean, there's so much we can go into there. You just covered so much.[00:16:32] Product Management and Engineering Synergy[00:16:32] swyx: One thing I just, I just observe is that I think the early Google days had this interesting mix of PM and engineer, which I think you are, you didn't, you didn't wait for PM to tell you these are my, this is my PRD.[00:16:42] swyx: This is my requirements.[00:16:44] mix: Oh,[00:16:44] Bret: okay.[00:16:45] swyx: I wasn't technically a software engineer. I mean,[00:16:48] Bret: by title, obviously. Right, right, right.[00:16:51] swyx: It's like a blend. And I feel like these days, product is its own discipline and its own lore and own industry and engineering is its own thing. And there's this process [00:17:00] that happens and they're kind of separated, but you don't produce as good of a product as if they were the same person.[00:17:06] swyx: And I'm curious, you know, if, if that, if that sort of resonates in, in, in terms of like comparing early Google versus modern startups that you see out there,[00:17:16] Bret: I certainly like wear a lot of hats. So, you know, sort of biased in this, but I really agree that there's a lot of power and combining product design engineering into as few people as possible because, you know few great things have been created by committee, you know, and so.[00:17:33] Bret: If engineering is an order taking organization for product you can sometimes make meaningful things, but rarely will you create extremely well crafted breakthrough products. Those tend to be small teams who deeply understand the customer need that they're solving, who have a. Maniacal focus on outcomes.[00:17:53] Bret: And I think the reason why it's, I think for some areas, if you look at like software as a service five years ago, maybe you can have a [00:18:00] separation of product and engineering because most software as a service created five years ago. I wouldn't say there's like a lot of like. Technological breakthroughs required for most, you know, business applications.[00:18:11] Bret: And if you're making expense reporting software or whatever, it's useful. I don't mean to be dismissive of expense reporting software, but you probably just want to understand like, what are the requirements of the finance department? What are the requirements of an individual file expense report? Okay.[00:18:25] Bret: Go implement that. And you kind of know how web applications are implemented. You kind of know how to. How databases work, how to build auto scaling with your AWS cluster, whatever, you know, it's just, you're just applying best practices to yet another problem when you have areas like the early days of mobile development or the early days of interactive web applications, which I think Google Maps and Gmail represent, or now AI agents, you're in this constant conversation with what the requirements of your customers and stakeholders are and all the different people interacting with it.[00:18:58] Bret: And the capabilities of the [00:19:00] technology. And it's almost impossible to specify the requirements of a product when you're not sure of the limitations of the technology itself. And that's why I use the word conversation. It's not literal. That's sort of funny to use that word in the age of conversational AI.[00:19:15] Bret: You're constantly sort of saying, like, ideally, you could sprinkle some magic AI pixie dust and solve all the world's problems, but it's not the way it works. And it turns out that actually, I'll just give an interesting example.[00:19:26] AI Agents and Modern Tooling[00:19:26] Bret: I think most people listening probably use co pilots to code like Cursor or Devon or Microsoft Copilot or whatever.[00:19:34] Bret: Most of those tools are, they're remarkable. I'm, I couldn't, you know, imagine development without them now, but they're not autonomous yet. Like I wouldn't let it just write most code without my interactively inspecting it. We just are somewhere between it's an amazing co pilot and it's an autonomous software engineer.[00:19:53] Bret: As a product manager, like your aspirations for what the product is are like kind of meaningful. But [00:20:00] if you're a product person, yeah, of course you'd say it should be autonomous. You should click a button and program should come out the other side. The requirements meaningless. Like what matters is like, what is based on the like very nuanced limitations of the technology.[00:20:14] Bret: What is it capable of? And then how do you maximize the leverage? It gives a software engineering team, given those very nuanced trade offs. Coupled with the fact that those nuanced trade offs are changing more rapidly than any technology in my memory, meaning every few months you'll have new models with new capabilities.[00:20:34] Bret: So how do you construct a product that can absorb those new capabilities as rapidly as possible as well? That requires such a combination of technical depth and understanding the customer that you really need more integration. Of product design and engineering. And so I think it's why with these big technology waves, I think startups have a bit of a leg up relative to incumbents because they [00:21:00] tend to be sort of more self actualized in terms of just like bringing those disciplines closer together.[00:21:06] Bret: And in particular, I think entrepreneurs, the proverbial full stack engineers, you know, have a leg up as well because. I think most breakthroughs happen when you have someone who can understand those extremely nuanced technical trade offs, have a vision for a product. And then in the process of building it, have that, as I said, like metaphorical conversation with the technology, right?[00:21:30] Bret: Gosh, I ran into a technical limit that I didn't expect. It's not just like changing that feature. You might need to refactor the whole product based on that. And I think that's, that it's particularly important right now. So I don't, you know, if you, if you're building a big ERP system, probably there's a great reason to have product and engineering.[00:21:51] Bret: I think in general, the disciplines are there for a reason. I think when you're dealing with something as nuanced as the like technologies, like large language models today, there's a ton of [00:22:00] advantage of having. Individuals or organizations that integrate the disciplines more formally.[00:22:05] Alessio: That makes a lot of sense.[00:22:06] Alessio: I've run a lot of engineering teams in the past, and I think the product versus engineering tension has always been more about effort than like whether or not the feature is buildable. But I think, yeah, today you see a lot more of like. Models actually cannot do that. And I think the most interesting thing is on the startup side, people don't yet know where a lot of the AI value is going to accrue.[00:22:26] Alessio: So you have this rush of people building frameworks, building infrastructure, layered things, but we don't really know the shape of the compute. I'm curious that Sierra, like how you thought about building an house, a lot of the tooling for evals or like just, you know, building the agents and all of that.[00:22:41] Alessio: Versus how you see some of the startup opportunities that is maybe still out there.[00:22:46] Bret: We build most of our tooling in house at Sierra, not all. It's, we don't, it's not like not invented here syndrome necessarily, though, maybe slightly guilty of that in some ways, but because we're trying to build a platform [00:23:00] that's in Dorian, you know, we really want to have control over our own destiny.[00:23:03] Bret: And you had made a comment earlier that like. We're still trying to figure out who like the reactive agents are and the jury is still out. I would argue it hasn't been created yet. I don't think the jury is still out to go use that metaphor. We're sort of in the jQuery era of agents, not the react era.[00:23:19] Bret: And, and that's like a throwback for people listening,[00:23:22] swyx: we shouldn't rush it. You know?[00:23:23] Bret: No, yeah, that's my point is. And so. Because we're trying to create an enduring company at Sierra that outlives us, you know, I'm not sure we want to like attach our cart to some like to a horse where it's not clear that like we've figured out and I actually want as a company, we're trying to enable just at a high level and I'll, I'll quickly go back to tech at Sierra, we help consumer brands build customer facing AI agents.[00:23:48] Bret: So. Everyone from Sonos to ADT home security to Sirius XM, you know, if you call them on the phone and AI will pick up with you, you know, chat with them on the Sirius XM homepage. It's an AI agent called Harmony [00:24:00] that they've built on our platform. We're what are the contours of what it means for someone to build an end to end complete customer experience with AI with conversational AI.[00:24:09] Bret: You know, we really want to dive into the deep end of, of all the trade offs to do it. You know, where do you use fine tuning? Where do you string models together? You know, where do you use reasoning? Where do you use generation? How do you use reasoning? How do you express the guardrails of an agentic process?[00:24:25] Bret: How do you impose determinism on a fundamentally non deterministic technology? There's just a lot of really like as an important design space. And I could sit here and tell you, we have the best approach. Every entrepreneur will, you know. But I hope that in two years, we look back at our platform and laugh at how naive we were, because that's the pace of change broadly.[00:24:45] Bret: If you talk about like the startup opportunities, I'm not wholly skeptical of tools companies, but I'm fairly skeptical. There's always an exception for every role, but I believe that certainly there's a big market for [00:25:00] frontier models, but largely for companies with huge CapEx budgets. So. Open AI and Microsoft's Anthropic and Amazon Web Services, Google Cloud XAI, which is very well capitalized now, but I think the, the idea that a company can make money sort of pre training a foundation model is probably not true.[00:25:20] Bret: It's hard to, you're competing with just, you know, unreasonably large CapEx budgets. And I just like the cloud infrastructure market, I think will be largely there. I also really believe in the applications of AI. And I define that not as like building agents or things like that. I define it much more as like, you're actually solving a problem for a business.[00:25:40] Bret: So it's what Harvey is doing in legal profession or what cursor is doing for software engineering or what we're doing for customer experience and customer service. The reason I believe in that is I do think that in the age of AI, what's really interesting about software is it can actually complete a task.[00:25:56] Bret: It can actually do a job, which is very different than the value proposition of [00:26:00] software was to ancient history two years ago. And as a consequence, I think the way you build a solution and For a domain is very different than you would have before, which means that it's not obvious, like the incumbent incumbents have like a leg up, you know, necessarily, they certainly have some advantages, but there's just such a different form factor, you know, for providing a solution and it's just really valuable.[00:26:23] Bret: You know, it's. Like just think of how much money cursor is saving software engineering teams or the alternative, how much revenue it can produce tool making is really challenging. If you look at the cloud market, just as a analog, there are a lot of like interesting tools, companies, you know, Confluent, Monetized Kafka, Snowflake, Hortonworks, you know, there's a, there's a bunch of them.[00:26:48] Bret: A lot of them, you know, have that mix of sort of like like confluence or have the open source or open core or whatever you call it. I, I, I'm not an expert in this area. You know, I do think [00:27:00] that developers are fickle. I think that in the tool space, I probably like. Default towards open source being like the area that will win.[00:27:09] Bret: It's hard to build a company around this and then you end up with companies sort of built around open source to that can work. Don't get me wrong, but I just think that it's nowadays the tools are changing so rapidly that I'm like, not totally skeptical of tool makers, but I just think that open source will broadly win, but I think that the CapEx required for building frontier models is such that it will go to a handful of big companies.[00:27:33] Bret: And then I really believe in agents for specific domains which I think will, it's sort of the analog to software as a service in this new era. You know, it's like, if you just think of the cloud. You can lease a server. It's just a low level primitive, or you can buy an app like you know, Shopify or whatever.[00:27:51] Bret: And most people building a storefront would prefer Shopify over hand rolling their e commerce storefront. I think the same thing will be true of AI. So [00:28:00] I've. I tend to like, if I have a, like an entrepreneur asked me for advice, I'm like, you know, move up the stack as far as you can towards a customer need.[00:28:09] Bret: Broadly, but I, but it doesn't reduce my excitement about what is the reactive building agents kind of thing, just because it is, it is the right question to ask, but I think we'll probably play out probably an open source space more than anything else.[00:28:21] swyx: Yeah, and it's not a priority for you. There's a lot in there.[00:28:24] swyx: I'm kind of curious about your idea maze towards, there are many customer needs. You happen to identify customer experience as yours, but it could equally have been coding assistance or whatever. I think for some, I'm just kind of curious at the top down, how do you look at the world in terms of the potential problem space?[00:28:44] swyx: Because there are many people out there who are very smart and pick the wrong problem.[00:28:47] Bret: Yeah, that's a great question.[00:28:48] Future of Software Development[00:28:48] Bret: By the way, I would love to talk about the future of software, too, because despite the fact it didn't pick coding, I have a lot of that, but I can talk to I can answer your question, though, you know I think when a technology is as [00:29:00] cool as large language models.[00:29:02] Bret: You just see a lot of people starting from the technology and searching for a problem to solve. And I think it's why you see a lot of tools companies, because as a software engineer, you start building an app or a demo and you, you encounter some pain points. You're like,[00:29:17] swyx: a lot of[00:29:17] Bret: people are experiencing the same pain point.[00:29:19] Bret: What if I make it? That it's just very incremental. And you know, I always like to use the metaphor, like you can sell coffee beans, roasted coffee beans. You can add some value. You took coffee beans and you roasted them and roasted coffee beans largely, you know, are priced relative to the cost of the beans.[00:29:39] Bret: Or you can sell a latte and a latte. Is rarely priced directly like as a percentage of coffee bean prices. In fact, if you buy a latte at the airport, it's a captive audience. So it's a really expensive latte. And there's just a lot that goes into like. How much does a latte cost? And I bring it up because there's a supply chain from growing [00:30:00] coffee beans to roasting coffee beans to like, you know, you could make one at home or you could be in the airport and buy one and the margins of the company selling lattes in the airport is a lot higher than the, you know, people roasting the coffee beans and it's because you've actually solved a much more acute human problem in the airport.[00:30:19] Bret: And, and it's just worth a lot more to that person in that moment. It's kind of the way I think about technology too. It sounds funny to liken it to coffee beans, but you're selling tools on top of a large language model yet in some ways your market is big, but you're probably going to like be price compressed just because you're sort of a piece of infrastructure and then you have open source and all these other things competing with you naturally.[00:30:43] Bret: If you go and solve a really big business problem for somebody, that's actually like a meaningful business problem that AI facilitates, they will value it according to the value of that business problem. And so I actually feel like people should just stop. You're like, no, that's, that's [00:31:00] unfair. If you're searching for an idea of people, I, I love people trying things, even if, I mean, most of the, a lot of the greatest ideas have been things no one believed in.[00:31:07] Bret: So I like, if you're passionate about something, go do it. Like who am I to say, yeah, a hundred percent. Or Gmail, like Paul as far, I mean I, some of it's Laura at this point, but like Gmail is Paul's own email for a long time. , and then I amusingly and Paul can't correct me, I'm pretty sure he sent her in a link and like the first comment was like, this is really neat.[00:31:26] Bret: It would be great. It was not your email, but my own . I don't know if it's a true story. I'm pretty sure it's, yeah, I've read that before. So scratch your own niche. Fine. Like it depends on what your goal is. If you wanna do like a venture backed company, if its a. Passion project, f*****g passion, do it like don't listen to anybody.[00:31:41] Bret: In fact, but if you're trying to start, you know an enduring company, solve an important business problem. And I, and I do think that in the world of agents, the software industries has shifted where you're not just helping people more. People be more productive, but you're actually accomplishing tasks autonomously.[00:31:58] Bret: And as a consequence, I think the [00:32:00] addressable market has just greatly expanded just because software can actually do things now and actually accomplish tasks and how much is coding autocomplete worth. A fair amount. How much is the eventual, I'm certain we'll have it, the software agent that actually writes the code and delivers it to you, that's worth a lot.[00:32:20] Bret: And so, you know, I would just maybe look up from the large language models and start thinking about the economy and, you know, think from first principles. I don't wanna get too far afield, but just think about which parts of the economy. We'll benefit most from this intelligence and which parts can absorb it most easily.[00:32:38] Bret: And what would an agent in this space look like? Who's the customer of it is the technology feasible. And I would just start with these business problems more. And I think, you know, the best companies tend to have great engineers who happen to have great insight into a market. And it's that last part that I think some people.[00:32:56] Bret: Whether or not they have, it's like people start so much in the technology, they [00:33:00] lose the forest for the trees a little bit.[00:33:02] Alessio: How do you think about the model of still selling some sort of software versus selling more package labor? I feel like when people are selling the package labor, it's almost more stateless, you know, like it's easier to swap out if you're just putting an input and getting an output.[00:33:16] Alessio: If you think about coding, if there's no ID, you're just putting a prompt and getting back an app. It doesn't really matter. Who generates the app, you know, you have less of a buy in versus the platform you're building, I'm sure on the backend customers have to like put on their documentation and they have, you know, different workflows that they can tie in what's kind of like the line to draw there versus like going full where you're managed customer support team as a service outsource versus.[00:33:40] Alessio: This is the Sierra platform that you can build on. What was that decision? I'll sort of[00:33:44] Bret: like decouple the question in some ways, which is when you have something that's an agent, who is the person using it and what do they want to do with it? So let's just take your coding agent for a second. I will talk about Sierra as well.[00:33:59] Bret: Who's the [00:34:00] customer of a, an agent that actually produces software? Is it a software engineering manager? Is it a software engineer? And it's there, you know, intern so to speak. I don't know. I mean, we'll figure this out over the next few years. Like what is that? And is it generating code that you then review?[00:34:16] Bret: Is it generating code with a set of unit tests that pass, what is the actual. For lack of a better word contract, like, how do you know that it did what you wanted it to do? And then I would say like the product and the pricing, the packaging model sort of emerged from that. And I don't think the world's figured out.[00:34:33] Bret: I think it'll be different for every agent. You know, in our customer base, we do what's called outcome based pricing. So essentially every time the AI agent. Solves the problem or saves a customer or whatever it might be. There's a pre negotiated rate for that. We do that. Cause it's, we think that that's sort of the correct way agents, you know, should be packaged.[00:34:53] Bret: I look back at the history of like cloud software and notably the introduction of the browser, which led to [00:35:00] software being delivered in a browser, like Salesforce to. Famously invented sort of software as a service, which is both a technical delivery model through the browser, but also a business model, which is you subscribe to it rather than pay for a perpetual license.[00:35:13] Bret: Those two things are somewhat orthogonal, but not really. If you think about the idea of software running in a browser, that's hosted. Data center that you don't own, you sort of needed to change the business model because you don't, you can't really buy a perpetual license or something otherwise like, how do you afford making changes to it?[00:35:31] Bret: So it only worked when you were buying like a new version every year or whatever. So to some degree, but then the business model shift actually changed business as we know it, because now like. Things like Adobe Photoshop. Now you subscribe to rather than purchase. So it ended up where you had a technical shift and a business model shift that were very logically intertwined that actually the business model shift was turned out to be as significant as the technical as the shift.[00:35:59] Bret: And I think with [00:36:00] agents, because they actually accomplish a job, I do think that it doesn't make sense to me that you'd pay for the privilege of like. Using the software like that coding agent, like if it writes really bad code, like fire it, you know, I don't know what the right metaphor is like you should pay for a job.[00:36:17] Bret: Well done in my opinion. I mean, that's how you pay your software engineers, right? And[00:36:20] swyx: and well, not really. We paid to put them on salary and give them options and they vest over time. That's fair.[00:36:26] Bret: But my point is that you don't pay them for how many characters they write, which is sort of the token based, you know, whatever, like, There's a, that famous Apple story where we're like asking for a report of how many lines of code you wrote.[00:36:40] Bret: And one of the engineers showed up with like a negative number cause he had just like done a big refactoring. There was like a big F you to management who didn't understand how software is written. You know, my sense is like the traditional usage based or seat based thing. It's just going to look really antiquated.[00:36:55] Bret: Cause it's like asking your software engineer, how many lines of code did you write today? Like who cares? Like, cause [00:37:00] absolutely no correlation. So my old view is I don't think it's be different in every category, but I do think that that is the, if an agent is doing a job, you should, I think it properly incentivizes the maker of that agent and the customer of, of your pain for the job well done.[00:37:16] Bret: It's not always perfect to measure. It's hard to measure engineering productivity, but you can, you should do something other than how many keys you typed, you know Talk about perverse incentives for AI, right? Like I can write really long functions to do the same thing, right? So broadly speaking, you know, I do think that we're going to see a change in business models of software towards outcomes.[00:37:36] Bret: And I think you'll see a change in delivery models too. And, and, you know, in our customer base you know, we empower our customers to really have their hands on the steering wheel of what the agent does they, they want and need that. But the role is different. You know, at a lot of our customers, the customer experience operations folks have renamed themselves the AI architects, which I think is really cool.[00:37:55] Bret: And, you know, it's like in the early days of the Internet, there's the role of the webmaster. [00:38:00] And I don't know whether your webmaster is not a fashionable, you know, Term, nor is it a job anymore? I just, I don't know. Will they, our tech stand the test of time? Maybe, maybe not. But I do think that again, I like, you know, because everyone listening right now is a software engineer.[00:38:14] Bret: Like what is the form factor of a coding agent? And actually I'll, I'll take a breath. Cause actually I have a bunch of pins on them. Like I wrote a blog post right before Christmas, just on the future of software development. And one of the things that's interesting is like, if you look at the way I use cursor today, as an example, it's inside of.[00:38:31] Bret: A repackaged visual studio code environment. I sometimes use the sort of agentic parts of it, but it's largely, you know, I've sort of gotten a good routine of making it auto complete code in the way I want through tuning it properly when it actually can write. I do wonder what like the future of development environments will look like.[00:38:55] Bret: And to your point on what is a software product, I think it's going to change a lot in [00:39:00] ways that will surprise us. But I always use, I use the metaphor in my blog post of, have you all driven around in a way, Mo around here? Yeah, everyone has. And there are these Jaguars, the really nice cars, but it's funny because it still has a steering wheel, even though there's no one sitting there and the steering wheels like turning and stuff clearly in the future.[00:39:16] Bret: If once we get to that, be more ubiquitous, like why have the steering wheel and also why have all the seats facing forward? Maybe just for car sickness. I don't know, but you could totally rearrange the car. I mean, so much of the car is oriented around the driver, so. It stands to reason to me that like, well, autonomous agents for software engineering run through visual studio code.[00:39:37] Bret: That seems a little bit silly because having a single source code file open one at a time is kind of a goofy form factor for when like the code isn't being written primarily by you, but it begs the question of what's your relationship with that agent. And I think the same is true in our industry of customer experience, which is like.[00:39:55] Bret: Who are the people managing this agent? What are the tools do they need? And they definitely need [00:40:00] tools, but it's probably pretty different than the tools we had before. It's certainly different than training a contact center team. And as software engineers, I think that I would like to see particularly like on the passion project side or research side.[00:40:14] Bret: More innovation in programming languages. I think that we're bringing the cost of writing code down to zero. So the fact that we're still writing Python with AI cracks me up just cause it's like literally was designed to be ergonomic to write, not safe to run or fast to run. I would love to see more innovation and how we verify program correctness.[00:40:37] Bret: I studied for formal verification in college a little bit and. It's not very fashionable because it's really like tedious and slow and doesn't work very well. If a lot of code is being written by a machine, you know, one of the primary values we can provide is verifying that it actually does what we intend that it does.[00:40:56] Bret: I think there should be lots of interesting things in the software development life cycle, like how [00:41:00] we think of testing and everything else, because. If you think about if we have to manually read every line of code that's coming out as machines, it will just rate limit how much the machines can do. The alternative is totally unsafe.[00:41:13] Bret: So I wouldn't want to put code in production that didn't go through proper code review and inspection. So my whole view is like, I actually think there's like an AI native I don't think the coding agents don't work well enough to do this yet, but once they do, what is sort of an AI native software development life cycle and how do you actually.[00:41:31] Bret: Enable the creators of software to produce the highest quality, most robust, fastest software and know that it's correct. And I think that's an incredible opportunity. I mean, how much C code can we rewrite and rust and make it safe so that there's fewer security vulnerabilities. Can we like have more efficient, safer code than ever before?[00:41:53] Bret: And can you have someone who's like that guy in the matrix, you know, like staring at the little green things, like where could you have an operator [00:42:00] of a code generating machine be like superhuman? I think that's a cool vision. And I think too many people are focused on like. Autocomplete, you know, right now, I'm not, I'm not even, I'm guilty as charged.[00:42:10] Bret: I guess in some ways, but I just like, I'd like to see some bolder ideas. And that's why when you were joking, you know, talking about what's the react of whatever, I think we're clearly in a local maximum, you know, metaphor, like sort of conceptual local maximum, obviously it's moving really fast. I think we're moving out of it.[00:42:26] Alessio: Yeah. At the end of 23, I've read this blog post from syntax to semantics. Like if you think about Python. It's taking C and making it more semantic and LLMs are like the ultimate semantic program, right? You can just talk to them and they can generate any type of syntax from your language. But again, the languages that they have to use were made for us, not for them.[00:42:46] Alessio: But the problem is like, as long as you will ever need a human to intervene, you cannot change the language under it. You know what I mean? So I'm curious at what point of automation we'll need to get, we're going to be okay making changes. To the underlying languages, [00:43:00] like the programming languages versus just saying, Hey, you just got to write Python because I understand Python and I'm more important at the end of the day than the model.[00:43:08] Alessio: But I think that will change, but I don't know if it's like two years or five years. I think it's more nuanced actually.[00:43:13] Bret: So I think there's a, some of the more interesting programming languages bring semantics into syntax. So let me, that's a little reductive, but like Rust as an example, Rust is memory safe.[00:43:25] Bret: Statically, and that was a really interesting conceptual, but it's why it's hard to write rust. It's why most people write python instead of rust. I think rust programs are safer and faster than python, probably slower to compile. But like broadly speaking, like given the option, if you didn't have to care about the labor that went into it.[00:43:45] Bret: You should prefer a program written in Rust over a program written in Python, just because it will run more efficiently. It's almost certainly safer, et cetera, et cetera, depending on how you define safe, but most people don't write Rust because it's kind of a pain in the ass. And [00:44:00] the audience of people who can is smaller, but it's sort of better in most, most ways.[00:44:05] Bret: And again, let's say you're making a web service and you didn't have to care about how hard it was to write. If you just got the output of the web service, the rest one would be cheaper to operate. It's certainly cheaper and probably more correct just because there's so much in the static analysis implied by the rest programming language that it probably will have fewer runtime errors and things like that as well.[00:44:25] Bret: So I just give that as an example, because so rust, at least my understanding that came out of the Mozilla team, because. There's lots of security vulnerabilities in the browser and it needs to be really fast. They said, okay, we want to put more of a burden at the authorship time to have fewer issues at runtime.[00:44:43] Bret: And we need the constraint that it has to be done statically because browsers need to be really fast. My sense is if you just think about like the, the needs of a programming language today, where the role of a software engineer is [00:45:00] to use an AI to generate functionality and audit that it does in fact work as intended, maybe functionally, maybe from like a correctness standpoint, some combination thereof, how would you create a programming system that facilitated that?[00:45:15] Bret: And, you know, I bring up Rust is because I think it's a good example of like, I think given a choice of writing in C or Rust, you should choose Rust today. I think most people would say that, even C aficionados, just because. C is largely less safe for very similar, you know, trade offs, you know, for the, the system and now with AI, it's like, okay, well, that just changes the game on writing these things.[00:45:36] Bret: And so like, I just wonder if a combination of programming languages that are more structurally oriented towards the values that we need from an AI generated program, verifiable correctness and all of that. If it's tedious to produce for a person, that maybe doesn't matter. But one thing, like if I asked you, is this rest program memory safe?[00:45:58] Bret: You wouldn't have to read it, you just have [00:46:00] to compile it. So that's interesting. I mean, that's like an, that's one example of a very modest form of formal verification. So I bring that up because I do think you have AI inspect AI, you can have AI reviewed. Do AI code reviews. It would disappoint me if the best we could get was AI reviewing Python and having scaled a few very large.[00:46:21] Bret: Websites that were written on Python. It's just like, you know, expensive and it's like every, trust me, every team who's written a big web service in Python has experimented with like Pi Pi and all these things just to make it slightly more efficient than it naturally is. You don't really have true multi threading anyway.[00:46:36] Bret: It's just like clearly that you do it just because it's convenient to write. And I just feel like we're, I don't want to say it's insane. I just mean. I do think we're at a local maximum. And I would hope that we create a programming system, a combination of programming languages, formal verification, testing, automated code reviews, where you can use AI to generate software in a high scale way and trust it.[00:46:59] Bret: And you're [00:47:00] not limited by your ability to read it necessarily. I don't know exactly what form that would take, but I feel like that would be a pretty cool world to live in.[00:47:08] Alessio: Yeah. We had Chris Lanner on the podcast. He's doing great work with modular. I mean, I love. LVM. Yeah. Basically merging rust in and Python.[00:47:15] Alessio: That's kind of the idea. Should be, but I'm curious is like, for them a big use case was like making it compatible with Python, same APIs so that Python developers could use it. Yeah. And so I, I wonder at what point, well, yeah.[00:47:26] Bret: At least my understanding is they're targeting the data science Yeah. Machine learning crowd, which is all written in Python, so still feels like a local maximum.[00:47:34] Bret: Yeah.[00:47:34] swyx: Yeah, exactly. I'll force you to make a prediction. You know, Python's roughly 30 years old. In 30 years from now, is Rust going to be bigger than Python?[00:47:42] Bret: I don't know this, but just, I don't even know this is a prediction. I just am sort of like saying stuff I hope is true. I would like to see an AI native programming language and programming system, and I use language because I'm not sure language is even the right thing, but I hope in 30 years, there's an AI native way we make [00:48:00] software that is wholly uncorrelated with the current set of programming languages.[00:48:04] Bret: or not uncorrelated, but I think most programming languages today were designed to be efficiently authored by people and some have different trade offs.[00:48:15] Evolution of Programming Languages[00:48:15] Bret: You know, you have Haskell and others that were designed for abstractions for parallelism and things like that. You have programming languages like Python, which are designed to be very easily written, sort of like Perl and Python lineage, which is why data scientists use it.[00:48:31] Bret: It's it can, it has a. Interactive mode, things like that. And I love, I'm a huge Python fan. So despite all my Python trash talk, a huge Python fan wrote at least two of my three companies were exclusively written in Python and then C came out of the birth of Unix and it wasn't the first, but certainly the most prominent first step after assembly language, right?[00:48:54] Bret: Where you had higher level abstractions rather than and going beyond go to, to like abstractions, [00:49:00] like the for loop and the while loop.[00:49:01] The Future of Software Engineering[00:49:01] Bret: So I just think that if the act of writing code is no longer a meaningful human exercise, maybe it will be, I don't know. I'm just saying it sort of feels like maybe it's one of those parts of history that just will sort of like go away, but there's still the role of this offer engineer, like the person actually building the system.[00:49:20] Bret: Right. And. What does a programming system for that form factor look like?[00:49:25] React and Front-End Development[00:49:25] Bret: And I, I just have a, I hope to be just like I mentioned, I remember I was at Facebook in the very early days when, when, what is now react was being created. And I remember when the, it was like released open source I had left by that time and I was just like, this is so f*****g cool.[00:49:42] Bret: Like, you know, to basically model your app independent of the data flowing through it, just made everything easier. And then now. You know, I can create, like there's a lot of the front end software gym play is like a little chaotic for me, to be honest with you. It is like, it's sort of like [00:50:00] abstraction soup right now for me, but like some of those core ideas felt really ergonomic.[00:50:04] Bret: I just wanna, I'm just looking forward to the day when someone comes up with a programming system that feels both really like an aha moment, but completely foreign to me at the same time. Because they created it with sort of like from first principles recognizing that like. Authoring code in an editor is maybe not like the primary like reason why a programming system exists anymore.[00:50:26] Bret: And I think that's like, that would be a very exciting day for me.[00:50:28] The Role of AI in Programming[00:50:28] swyx: Yeah, I would say like the various versions of this discussion have happened at the end of the day, you still need to precisely communicate what you want. As a manager of people, as someone who has done many, many legal contracts, you know how hard that is.[00:50:42] swyx: And then now we have to talk to machines doing that and AIs interpreting what we mean and reading our minds effectively. I don't know how to get across that barrier of translating human intent to instructions. And yes, it can be more declarative, but I don't know if it'll ever Crossover from being [00:51:00] a programming language to something more than that.[00:51:02] Bret: I agree with you. And I actually do think if you look at like a legal contract, you know, the imprecision of the English language, it's like a flaw in the system. How many[00:51:12] swyx: holes there are.[00:51:13] Bret: And I do think that when you're making a mission critical software system, I don't think it should be English language prompts.[00:51:19] Bret: I think that is silly because you want the precision of a a programming language. My point was less about that and more about if the actual act of authoring it, like if you.[00:51:32] Formal Verification in Software[00:51:32] Bret: I'll think of some embedded systems do use formal verification. I know it's very common in like security protocols now so that you can, because the importance of correctness is so great.[00:51:41] Bret: My intellectual exercise is like, why not do that for all software? I mean, probably that's silly just literally to do what we literally do for. These low level security protocols, but the only reason we don't is because it's hard and tedious and hard and tedious are no longer factors. So, like, if I could, I mean, [00:52:00] just think of, like, the silliest app on your phone right now, the idea that that app should be, like, formally verified for its correctness feels laughable right now because, like, God, why would you spend the time on it?[00:52:10] Bret: But if it's zero costs, like, yeah, I guess so. I mean, it never crashed. That's probably good. You know, why not? I just want to, like, set our bars really high. Like. We should make, software has been amazing. Like there's a Mark Andreessen blog post, software is eating the world. And you know, our whole life is, is mediated digitally.[00:52:26] Bret: And that's just increasing with AI. And now we'll have our personal agents talking to the agents on the CRO platform and it's agents all the way down, you know, our core infrastructure is running on these digital systems. We now have like, and we've had a shortage of software developers for my entire life.[00:52:45] Bret: And as a consequence, you know if you look, remember like health care, got healthcare. gov that fiasco security vulnerabilities leading to state actors getting access to critical infrastructure. I'm like. We now have like created this like amazing system that can [00:53:00] like, we can fix this, you know, and I, I just want to, I'm both excited about the productivity gains in the economy, but I just think as software engineers, we should be bolder.[00:53:08] Bret: Like we should have aspirations to fix these systems so that like in general, as you said, as precise as we want to be in the specification of the system. We can make it work correctly now, and I'm being a little bit hand wavy, and I think we need some systems. I think that's where we should set the bar, especially when so much of our life depends on this critical digital infrastructure.[00:53:28] Bret: So I'm I'm just like super optimistic about it. But actually, let's go to w

Intro topic: Lego event space & retail store: https://www.instagram.com/bambeecave News/Links:StackOverflow Question Count Going Down https://gist.github.com/hopeseekr/f522e380e35745bd5bdc3269a9f0b132DeepSeek claims its ‘reasoning' model beats OpenAI's o1 on certain benchmarkshttps://techcrunch.com/2025/01/20/deepseek-claims-its-reasoning-model-beats-openais-o1-on-certain-benchmarks/ Computer Science Papers Every Developer Should Readhttps://newsletter.techworld-with-milan.com/p/computer-science-papers-every-developerNvidia Cosmos - an AI platform to change the future of robots and cars - wins Best of CES 2025https://www.zdnet.com/article/nvidia-signs-largest-car-maker-toyota-to-use-its-self-driving-tech/ Book of the ShowPatrick: Alice's Adventures in a differentiable wonderlandhttps://www.sscardapane.it/alice-book/Jason: A Beautiful Day in the Neighborhood (Hulu/Netflix/etc)Patreon Plug https://www.patreon.com/programmingthrowdown?ty=hTool of the ShowPatrick: Digseumhttps://store.steampowered.com/app/3361470/Digseum/Jason: Sqlitedict - Python dictionaries saved to diskTopic: Project Planning and ManagementWhy?Gathering feedbackIdentifying risksDeciding future headcountDocumenting / discovering dependenciesCritical pathScheduleReduce the bullwhip effectHow it worksSMART goalsspecific, measurable, achievable, relevant, and time-boundMT is most importantGantt ChartsScrumAgileKanbanToolsWhiteboard (the generic IRL one)Post it notesJIRAAsanaOpenProjectDealing with uncertaintyBufferingIssues with recursive paddingProject planning Post-Mortems ★ Support this podcast on Patreon ★

So you're thinking about learning your second programming language? When is the right time? How should you go about learning it? What language should even you pick? If any of these questions sound familiar to you, join in as Eric and Matt talk about Eric's experience in learning Go! Leave us a message at ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠SelfTaughtDevs.net⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Sign up for our ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Patreon⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠! ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Matt's Links⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Eric's Links ⁠⁠⁠

We're experimenting and would love to hear from you!In this episode of 'Discover Daily', we explore Apple's innovative iPhone 17 Air, set to debut in late 2025. This ultra-slim device measures just 5.5mm thick and features cutting-edge technology, including a 6.6-inch ProMotion display, advanced single-camera system, and Apple's first in-house 5G modem. The device represents a significant engineering achievement in smartphone design and positions itself as a compelling mid-range option in Apple's lineup. We also cover a significant legal battle between Oracle and the developer community over the JavaScript trademark. Deno Land's petition to cancel Oracle's trademark, backed by over 14,000 developers including JavaScript creator Brendan Eich, challenges Oracle's control over this fundamental programming language name, potentially setting precedents for trademark rights in open-source software.The episode concludes with an in-depth analysis of the Biden administration's groundbreaking AI-Export Rules, a comprehensive framework that introduces a three-tiered system for global AI technology access. The policy, announced January 2025, establishes strict controls on advanced computing chips while maintaining strategic partnerships with eighteen tier-one allied nations, potentially reshaping the landscape of global AI development.From Perplexity's Discover Feed: https://www.perplexity.ai/page/iphone-air-rumors-vST7FXlNSIGZlzUdPErgHQhttps://www.perplexity.ai/page/the-javascript-trademark-battl-ScY6A16tRY2SKVVNihH8Awhttps://www.perplexity.ai/page/new-us-ai-export-rules-YiRvOtrUQG.kWJBqQqAHVgPerplexity is the fastest and most powerful way to search the web. Perplexity crawls the web and curates the most relevant and up-to-date sources (from academic papers to Reddit threads) to create the perfect response to any question or topic you're interested in. Take the world's knowledge with you anywhere. Available on iOS and Android Join our growing Discord community for the latest updates and exclusive content. Follow us on: Instagram Threads X (Twitter) YouTube Linkedin

Robert Seacord, the Standardization Lead at Woven by Toyota, the convenor of the C standards committee, and author of The CERT® C Coding Standard, Effective C, and Secure Coding in C and C++, speaks with SE Radio host Gavin Henry about What's New in the C Programming Language. They start with a review of the history of C and why it has a standard, and then they discuss what C23 brings and how programmers can take advantage of it. They consider the sectors in which C is most used and whether you should use C to start a brand new project in 2025. Seacord discusses 8 new things that C23 brings, use case examples, must haves, floating point numbers, how automotive systems use C, why C is used there, Rust vs C, compile time checks vs static analysis, all the various safety standards they can use, why you should use the right tool for the job and never trust user input no matter the language.  Brought to you by IEEE Computer Society and IEEE Software magazine.

Or watch the video version on YouTube. Bret is joined by Willem Delbare and Roeland Delrue to discuss Aikido, a security tool consolidation platform designed specifically for smaller teams and solo DevOps practitioners. The discussion explores how Aikido addresses the growing challenges of software supply chain security by bringing together various security tools - from CVE scanning to cloud API analysis - under a single, manageable portal. Unlike enterprise-focused solutions, Aikido targets the needs of smaller teams and individual DevOps engineers who often juggle multiple responsibilities. During the episode, they demonstrate Aikido's capabilities using Bret's sample GitHub organization, and show how teams can implement comprehensive security measures without managing multiple separate tools.Be sure to check out video version of the complete show for demos, from our December 5, 2024 YouTube Live stream.★Topics★Aikido websiteAikido on BlueskyAikido on LinkedInCreators & Guests Cristi Cotovan - Editor Beth Fisher - Producer Bret Fisher - Host Willem Delbare - Guest Roeland Delrue - Guest (00:00) - Intro (06:20) - Aikido Origin Story (10:32) - What Does AutoFix Mean? (13:18) - Security Automation and Developers (21:32) - Lessons from Onboarding Customers (23:10) - Reducing Noise and Alert Fatigue with Aikido (27:30) - Aikido in the CI/CD Process (31:26) - AI Security Integration (32:24) - GitHub Actions and Dependencies as Attack Vector (39:20) - Dependencies in Programming Languages (41:30) - Infrastructure as Code and Cloud Security (48:17) - Runtime Protection with Aikido Zen (54:25) - Agent Involvement in Scanning (57:54) - Tools to Use Alongside Aikido (01:01:16) - Getting Started with Aikido You can also support my free material by subscribing to my YouTube channel and my weekly newsletter at bret.news!Grab the best coupons for my Docker and Kubernetes courses.Join my cloud native DevOps community on Discord.Grab some merch at Bret's Loot BoxHomepage bretfisher.com

I discuss the paper POPLmark Reloaded: Mechanizing Proofs by Logical Relations, which proposes a benchmark problem for mechanizing Programming Language theory.  

The latest episode of Redefining CyberSecurity on ITSPmagazine featured a thought-provoking discussion about integrating human factors into secure software development. Host Sean Martin was joined by Dr. Kelsey Fulton, Assistant Professor at the Colorado School of Mines, and Julie Haney, a computer scientist at the National Institute of Standards and Technology. The conversation explored how human-centered approaches can strengthen secure software practices and address challenges in the development process.A Human-Centered Approach to SecurityDr. Fulton shared how her research focuses on the human factors that impact secure software development. Her journey began during her graduate studies at the University of Maryland, where she was introduced to the intersection of human behavior and security in a course that sparked her interest. Her projects, such as investigating the transition from C to Rust programming languages, underscore the complexity of embedding security into the software development lifecycle.The Current State of Secure DevelopmentOne key takeaway from the discussion was the tension between functionality and security in software development. Developers often prioritize getting a product to market quickly, leading to decisions that sideline security considerations. Dr. Fulton noted that while developers typically have good intentions, they often lack the resources, tools, and organizational support necessary to incorporate security effectively.She highlighted the need for a “security by design” approach, which integrates security practices from the earliest stages of development. Embedding security specialists within development teams can create a cultural shift where security becomes a shared responsibility rather than an afterthought.Challenges in Adoption and EducationDr. Fulton's research reveals significant obstacles to adopting secure practices, including the complexity of tools and the lack of comprehensive education for developers. Even advanced tools like static analyzers and fuzzers are underutilized. A major barrier is developers' perception that security is not their responsibility, compounded by tight deadlines and organizational pressures.Additionally, her research into Rust adoption at companies illuminated technical and organizational challenges. Resistance often stems from the cost and complexity of transitioning existing systems, despite Rust's promise of enhanced security and memory safety.The Future of Human-Centered SecurityLooking ahead, Dr. Fulton emphasized the importance of addressing how developers trust and interact with tools like large language models (LLMs) for code generation. Her team is exploring ways to enhance these tools, ensuring they provide secure code suggestions and help developers recognize vulnerabilities.The episode concluded with a call to action for organizations to support research in this area and cultivate a security-first culture. Dr. Fulton underscored the potential of collaborative efforts between researchers, developers, and companies to improve security outcomes.By focusing on human factors and fostering supportive environments, organizations can significantly advance secure software development practices.____________________________Guests: Dr. Kelsey Fulton, Assistant Professor of Computer Science at the Colorado School of MinesWebsite | https://cs.mines.edu/project/fulton-kelsey/Julie Haney, Computer scientist and Human-Centered Cybersecurity Program Lead, National Institute of Standards and Technology [@NISTcyber]On LinkedIn | https://www.linkedin.com/in/julie-haney-037449119/____________________________Host: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/sean-martin____________________________View This Show's SponsorsImperva | https://itspm.ag/imperva277117988LevelBlue | https://itspm.ag/levelblue266f6cThreatLocker | https://itspm.ag/threatlocker-r974___________________________Watch this and other videos on ITSPmagazine's YouTube ChannelRedefining CyberSecurity Podcast with Sean Martin, CISSP playlist:

The latest episode of Redefining CyberSecurity on ITSPmagazine featured a thought-provoking discussion about integrating human factors into secure software development. Host Sean Martin was joined by Dr. Kelsey Fulton, Assistant Professor at the Colorado School of Mines, and Julie Haney, a computer scientist at the National Institute of Standards and Technology. The conversation explored how human-centered approaches can strengthen secure software practices and address challenges in the development process.A Human-Centered Approach to SecurityDr. Fulton shared how her research focuses on the human factors that impact secure software development. Her journey began during her graduate studies at the University of Maryland, where she was introduced to the intersection of human behavior and security in a course that sparked her interest. Her projects, such as investigating the transition from C to Rust programming languages, underscore the complexity of embedding security into the software development lifecycle.The Current State of Secure DevelopmentOne key takeaway from the discussion was the tension between functionality and security in software development. Developers often prioritize getting a product to market quickly, leading to decisions that sideline security considerations. Dr. Fulton noted that while developers typically have good intentions, they often lack the resources, tools, and organizational support necessary to incorporate security effectively.She highlighted the need for a “security by design” approach, which integrates security practices from the earliest stages of development. Embedding security specialists within development teams can create a cultural shift where security becomes a shared responsibility rather than an afterthought.Challenges in Adoption and EducationDr. Fulton's research reveals significant obstacles to adopting secure practices, including the complexity of tools and the lack of comprehensive education for developers. Even advanced tools like static analyzers and fuzzers are underutilized. A major barrier is developers' perception that security is not their responsibility, compounded by tight deadlines and organizational pressures.Additionally, her research into Rust adoption at companies illuminated technical and organizational challenges. Resistance often stems from the cost and complexity of transitioning existing systems, despite Rust's promise of enhanced security and memory safety.The Future of Human-Centered SecurityLooking ahead, Dr. Fulton emphasized the importance of addressing how developers trust and interact with tools like large language models (LLMs) for code generation. Her team is exploring ways to enhance these tools, ensuring they provide secure code suggestions and help developers recognize vulnerabilities.The episode concluded with a call to action for organizations to support research in this area and cultivate a security-first culture. Dr. Fulton underscored the potential of collaborative efforts between researchers, developers, and companies to improve security outcomes.By focusing on human factors and fostering supportive environments, organizations can significantly advance secure software development practices.____________________________Guests: Dr. Kelsey Fulton, Assistant Professor of Computer Science at the Colorado School of MinesWebsite | https://cs.mines.edu/project/fulton-kelsey/Julie Haney, Computer scientist and Human-Centered Cybersecurity Program Lead, National Institute of Standards and Technology [@NISTcyber]On LinkedIn | https://www.linkedin.com/in/julie-haney-037449119/____________________________Host: Sean Martin, Co-Founder at ITSPmagazine [@ITSPmagazine] and Host of Redefining CyberSecurity Podcast [@RedefiningCyber]On ITSPmagazine | https://www.itspmagazine.com/sean-martin____________________________View This Show's SponsorsImperva | https://itspm.ag/imperva277117988LevelBlue | https://itspm.ag/levelblue266f6cThreatLocker | https://itspm.ag/threatlocker-r974___________________________Watch this and other videos on ITSPmagazine's YouTube ChannelRedefining CyberSecurity Podcast with Sean Martin, CISSP playlist:

Rushi Manche is the Co-Founder of Movement Labs, a pioneering engineer and the visionary architect behind Movement Labs' groundbreaking technology. With a strong background in smart contract engineering and extensive experience in the Ethereum DeFi ecosystem, Rushi brings a wealth of technical expertise and innovative thinking to the Web3 space. His journey in blockchain led him to work closely with Cosmos protocols, notably contributing to the development of a decentralized file storage system. During the buildup of Aptos, Rushi became a core contributor to the ecosystem, particularly within the DeFi scene, where he engineered a leading DEX. This hands-on experience with multiple blockchain platforms equipped Rushi with an unparalleled understanding of the limitations and potential of various technologies.In this conversation, we discuss:- Launching $MOVE- How to launch on all the tier 1 exchanges- What is Move, and how will it compete with the big dawgs- 3 factors of every token launch: airdrop, launch, sentiment- Move vs Aptos & Sui- Community-First engagement- Move-based L2 on Ethereum- Fractal: EVM Interpreter- 2025 roadmap- Move - the next big application-based ecosystem- Fitness could be the killer consumer app - Move To Earn- AI CryptoMovement LabsWebsite: movementlabs.xyzX: @movementlabsxyzTelegram: t.me/movementlabsxyzRushi MancheX: @rushimancheLinkedIn: Rushi Manche ---------------------------------------------------------------------------------  This episode is brought to you by PrimeXBT.  PrimeXBT offers a robust trading system for both beginners and professional traders that demand highly reliable market data and performance. Traders of all experience levels can easily design and customize layouts and widgets to best fit their trading style. PrimeXBT is always offering innovative products and professional trading conditions to all customers.   PrimeXBT is running an exclusive promotion for listeners of the podcast. After making your first deposit, 50% of that first deposit will be credited to your account as a bonus that can be used as additional collateral to open positions.  Code: CRYPTONEWS50  This promotion is available for a month after activation. Click the link below:  PrimeXBT x CRYPTONEWS50

Is coding still worth learning? In this episode of Your AI Injection, Deep Dhillon sits down with Austin Vance, CEO of Focused Labs, to explore the radical future of software development. Austin explains why AI might soon bypass programming languages like Python, generating bytecode or AI-native logic directly. The two discuss how developers today are pairing with AI copilots to navigate legacy systems, optimize frameworks, and build faster -- but what happens when AI handles everything except the requirements? Will human developers move from writing code to directing machines? Tune in to find out if programming languages are on the brink of obsolescence. Learn more about Austin here: https://www.linkedin.com/in/austinbv/and Focused here: https://www.linkedin.com/company/build-with-focused/Check out some more of our related podcast episodes:Expert Tips for AI Implementation and Data Strategy with Paul LewisSpeak Directly to Your Data, No Coding Required with Sarah NagyTransforming Workforce Management with AI and People Analytics with Adam Binnie

Intro topic: Smart homesNews/Links:SpaceX Starship Flight Test Five / Sixhttps://www.youtube.com/watch?v=pIKI7y3DTXkShareDBhttps://github.com/share/sharedbOrion AR Glasseshttps://about.fb.com/news/2024/09/introducing-orion-our-first-true-augmented-reality-glasses/Blade and Sorcery 1.0 is outhttps://www.meta.com/experiences/blade-sorcery-nomad/2031826350263349/Book of the ShowPatrick: The Book that Wouldn't Burn by Mark Lawrencehttps://amzn.to/4fry2XWJason: Masters of Doomhttps://amzn.to/3YxuD3cPatreon Plug https://www.patreon.com/programmingthrowdown?ty=hTool of the ShowPatrick: Balatrohttps://www.playbalatro.com/Jason: Cursor IDEhttps://www.cursor.com/Topic: Working from HomeIntroBackground & WFH experiencesIs it Panacea?Realizing it works better for some than othersInternally MotivatedSchedulingCommunicationsHome SetupDedicated spaceHandling Non-work DistractionsKeyboards, Monitors, Music, … Desk related thingsThe specter of RTO ★ Support this podcast on Patreon ★

When designing systems with high integrity, say for automotive applications, what is the programming language of choice? I believe that's referred to as a loaded question, because there are so many variables involved, and it's a question that's almost impossible to answer. Unfortunately, many developers make a decision for the wrong reasons. To get to the root of the matter, I invited Quentin Ochem, the Chief Product and Revenue Officer at AdaCore, to be my guest on this week's Embedded Executives podcast.

In this episode, I begin discussing the question and history of formalizing results in Programming Languages Theory using interactive theorem provers like Rocq (formerly Coq) and Agda.

Stephen Solka, CTO and co-founder of Standd.io, joins Elixir Wizards Owen and Charles to share the journey of building an AI-native deal intelligence and due diligence platform. Designed to streamline document analysis and text generation for venture capital firms, Standd.io leverages large language models and AI tools to address key customer pain points in document workflows. Stephen explains how Elixir and Phoenix LiveView enabled rapid UI iteration and seamless integration between the front-end and back-end. The conversation also explores the human side of startup life. Stephen reflects on balancing tech debt with customer demands, the value of accelerators in building networks and securing funding, and the challenges of pricing in early-stage startups. He emphasizes the importance of validating ideas with potential customers and learning from the hurdles of growing a business. Tune in for insights on leveraging AI in Elixir, solving real-world problems, and navigating the journey from concept to company. Topics discussed in this episode: The journey from self-taught programmer to CTO The perks of Phoenix LiveView for rapid UI development Integrating front-end and back-end technologies AI tools for code generation How early adopters balance functionality with product polish Validating ideas and understanding customer needs The impact of accelerators on networking and fundraising Approaches to managing pricing strategies for startups Balancing technical debt with feature development The role of telemetry and error reporting in product development Creating collaborative and supportive tech communities Educating users on AI's capabilities and limitations The broader implications of AI tools across industries Links Mentioned Contact Stephen & Julie at Standd: founders@standd.io https://www.standd.io/ https://www.digitalocean.com/community/tutorials/gangs-of-four-gof-design-patterns https://www.thriftbooks.com/w/code-completesteve-mcconnell/248753/item/15057346/ https://aws.amazon.com/sagemaker/ https://www.anthropic.com/ https://getoban.pro/ https://kubernetes.io/ https://www.apollographql.com/ https://aws.amazon.com/startups/accelerators https://accelerate.techstars.com/ https://aider.chat/ https://github.com/Aider-AI/aider https://neovim.io/ https://ui.shadcn.com/ https://tailwindui.com/ https://www.ycombinator.com/ https://www.thriftbooks.com/w/close-to-the-machine-technophilia-and-its-discontentsellen-ullman/392556 Special Guest: Stephen Solka.

Intro topic:  Buying a CarNews/Links:Cognitive Load is what Mattershttps://github.com/zakirullin/cognitive-loadDiffusion models are Real-Time Game Engineshttps://gamengen.github.io/Your Company Needs Junior Devshttps://softwaredoug.com/blog/2024/09/07/your-team-needs-juniorsSeamless Streaming / Fish Speech / LLaMA OmniSeamless: https://huggingface.co/facebook/seamless-streamingFish: https://github.com/fishaudio/fish-speech LLaMA Omni: https://github.com/ictnlp/LLaMA-Omni Book of the ShowPatrick: Thought Emporium Youtubehttps://youtu.be/8X1_HEJk2Hw?si=T8EaHul-QMahyUvQJason: Novel Mindshttps://www.novelminds.ai/Patreon Plug https://www.patreon.com/programmingthrowdown?ty=hTool of the ShowPatrick: Escape Simulatorhttps://pinestudio.com/games/escape-simulator/Jason: Cursor IDEhttps://www.cursor.com/Topic: Vector Databases (~54 min)How computers represent data traditionallyASCII valuesRGB valuesHow traditional compression worksHuffman encoding (tree structure)Lossy example: Fourier Transform & store coefficientsHow embeddings are computedPairwise (contrastive) methodsForward models (self-supervised)Similarity metricsApproximate Nearest Neighbors (ANN)Sub-Linear ANNClusteringSpace Partitioning (e.g. K-D Trees)What a vector database doesPerform nearest-neighbors with many different similarity metricsStore the vectors and the data structures to support sub-linear ANNHandle updates, deletes, rebalancing/reclustering, backups/restoresExamplespgvector: a vector-database plugin for postgresWeaviate, Pinecone Milvus ★ Support this podcast on Patreon ★

Today in the Creator's Lab, Tony Dang joins Elixir Wizards Sundi Myint and Owen Bickford to break down his journey of creating a local-first, offline-ready to-do app using Phoenix LiveView, Svelte, and CRDTs (Conflict-free Replicated Data Types). Tony explains why offline functionality matters and how this feature can transform various apps. He shares insights on different libraries, algorithms, and techniques for building local-first experiences and highlights the advantages of Elixir and Phoenix LiveView. Tony also shares his go-to tools, like Inertia.js for connecting Phoenix backends with JavaScript frontends, and favorite Elixir packages like Oban, Joken, and Hammer, offering a toolkit for anyone building powerful, adaptable applications. Topics discussed in this episode: Tony Dang's background from mechanical engineer to web developer Building an offline-enabled to-do app with Phoenix LiveView and Svelte CRDTs: Conflict-free Replicated Data Types for merging changes offline How to make a LiveView app work offline Sending full state updates vs. incremental updates for performance optimization Inspiring others through open-source projects and community contributions Learning vanilla Phoenix and Channels to understand LiveView better Handling stale CSRF tokens when reconnecting to a LiveView app offline Exploring service workers and browser APIs for managing offline connectivity Balancing the use of JavaScript and Elixir in web development Fostering a supportive and inspiring Elixir community Links mentioned: Working in Elevators: How to build an offline-enabled, real-time todo app (https://www.youtube.com/watch?v=PX9-lq0LL9Q) w/ LiveView, Svelte, & Yjs Tony's Twitter: https://x.com/tonydangblog https://liveview-svelte-pwa.fly.dev/ https://github.com/tonydangblog/liveview-svelte-pwa CRDT: https://en.wikipedia.org/wiki/Conflict-freereplicateddatatype PWA: https://en.wikipedia.org/wiki/Progressivewebapp https://github.com/josevalim/sync https://github.com/sveltejs/svelte https://github.com/woutdp/livesvelte https://github.com/yjs/yjs https://github.com/satoren/yex https://github.com/y-crdt/y-crdt https://linear.app/ https://github.com/automerge/automerge https://hexdocs.pm/phoenix/1.4.0-rc.1/presence.html Vaxine, the Rich CRDT Database for ElixirPhoenix Apps (https://www.youtube.com/watch?v=n2c5eWIfziY) | James Arthur | Code BEAM America 2022 https://github.com/electric-sql/vaxine Hybrid Logical Clocks https://muratbuffalo.blogspot.com/2014/07/hybrid-logical-clocks.html https://en.wikipedia.org/wiki/256(number) CSRF Tokens in LiveView https://hexdocs.pm/phoenixliveview/Phoenix.LiveView.html#getconnectparams/1 https://hexdocs.pm/phoenix/channels.html Authentication with Passkeys (https://www.youtube.com/playlist?list=PL8lFmBcH3vX-JNIgxW3THUy7REthSRFEI) Talk by Tony https://www.meetup.com/dc-elixir/ https://github.com/rails/rails https://github.com/facebook/react-native https://github.com/vuejs https://github.com/laravel/laravel https://hexdocs.pm/phoenixliveview/js-interop.html https://github.com/inertiajs https://github.com/inertiajs/inertia-phoenix https://savvycal.com/ https://github.com/wojtekmach/req https://github.com/oban-bg/oban https://github.com/joken-elixir/joken https://github.com/ExHammer/hammer Special Guest: Tony Dang.

Deb Nicholson, executive director of the Python Software Foundation, attributes Python's popularity to its minimal syntactical complexity, which appeals to beginners and seasoned developers alike. Python allows flexibility for those exploring coding without a specific focus, unlike purpose-built languages. Since her leadership began in 2022, Nicholson has overseen the foundation's role in managing Python's fiscal and operational needs, including the package index that hosts over half a million add-ons. This open ecosystem enables contributions from large corporations and individual developers while demanding vigilant security measures.Nicholson envisions Python's future advancements, particularly in improving multi-threading and expanding usage in mobile development. She acknowledges Python's critical role in AI and data science but remains cautious about AI's pervasive application, likening it to a temporary trend. On open source in the enterprise, Nicholson critiques companies profiting from open-source tools while adopting restrictive licenses. Instead, she admires models like Red Hat's, which leverage open source sustainably without compromising accessibility or innovation.Learn more from The New Stack about Python: Python 3.13: Blazing New Trails in Performance and ScaleThe Top 5 Python Packages and What They DoPython Mulls a Change in Version NumberingJoin our community of newsletter subscribers to stay on top of the news and at the top of your game.

C++'s Borg-like mission continues, and some thoughts on Rails 8.1. Plus, there is a little trouble in Microsoft Paradise. And why Chris finally paid for an LLM.

Rust has maintained its place among the top 15 programming languages and has been the most admired language for nine consecutive years. In a New Stack Makers podcast, Joel Marcey, director of technology at the Rust Foundation, discussed the language's growing importance, including initiatives to improve its security, performance, and adoption in various domains. While Rust is widely used in systems and backend programming, it's also gaining traction in embedded systems, safety-critical applications, game development, and even the Linux kernel.Marcey highlighted Rust's strengths as a safe and fast systems language, noting its use on the web through WebAssembly (Wasm), though adoption there is still early. He also addressed Rust vs. Go, explaining that Rust excels in performance-critical applications. Marcey discussed recent updates, such as Rust 1.81, and project goals for 2024, which include a new edition and async improvements.He also touched on government interest in Rust, including DARPA's initiative to convert C code to Rust, and the Rust Security Initiative, aimed at maintaining the language's strong security reputation.Learn more from The New Stack about Rust Could Rust be the Future of JavaScript Infrastructure?Rust Growing Fastest, But JavaScript Reigns SupremeRust vs. Zig in Reality: A (Somewhat) Friendly DebateJoin our community of newsletter subscribers to stay on top of the news and at the top of your game. 

The Vault is a morning show hosted on Twitter Spaces and YouTube Live on Tuesdays, Wednesdays, and Thursdays at 11:30 am EST. The show focuses on multi-chain communities, emerging protocols, NFTFi, DeFi, Gaming, and, most importantly, collecting digital assets.Adam McBride: https://twitter.com/adamamcbrideJake Gallen: https://twitter.com/jakegallen_Chris Devitte: https://twitter.com/chris_devvEmblem Vault: https://twitter.com/EmblemVault

“I didn't see it coming.” I had to admit that to myself a few times recently.Over the last couple of weeks, I've been experiencing several issues with Podscan that only came to pass because I didn't really have any observability on my system. At least that's what I know now.Today, let me share my early-stage learnings about system observability in this distributed, data-centric SaaS of mine. Even if you don't have a software business or don't operate with millions of data feeds every single day, there's still something insightful in here that I will, not just likely, but guaranteed, take into my future business efforts.This episode is sponsored by Podscan.fmThe blog post: https://thebootstrappedfounder.com/observability-in-software-businesses/The podcast episode: https://tbf.fm/episodes/348-observability-in-software-businessesCheck out Podscan to get alerts when you're mentioned on podcasts: https://podscan.fmSend me a voicemail on Podline: https://podline.fm/arvidYou'll find my weekly article on my blog: https://thebootstrappedfounder.comPodcast: https://thebootstrappedfounder.com/podcastNewsletter: https://thebootstrappedfounder.com/newsletterMy book Zero to Sold: https://zerotosold.com/My book The Embedded Entrepreneur: https://embeddedentrepreneur.com/My course Find Your Following: https://findyourfollowing.comHere are a few tools I use. Using my affiliate links will support my work at no additional cost to you.- Notion (which I use to organize, write, coordinate, and archive my podcast + newsletter): https://affiliate.notion.so/465mv1536drx- Riverside.fm (that's what I recorded this episode with): https://riverside.fm/?via=arvid- TweetHunter (for speedy scheduling and writing Tweets): http://tweethunter.io/?via=arvid- HypeFury (for massive Twitter analytics and scheduling): https://hypefury.com/?via=arvid60- AudioPen (for taking voice notes and getting amazing summaries): https://audiopen.ai/?aff=PXErZ- Descript (for word-based video editing, subtitles, and clips): https://www.descript.com/?lmref=3cf39Q- ConvertKit (for email lists, newsletters, even finding sponsors): https://convertkit.com?lmref=bN9CZw

I'm always interested in what factors shape the design of a programming language. This week we're taking a look at a language that's wholly shaped by its need to support a very specific kind of program - audio processing. Anything from creating a simple echo sound effect, to building an entire digital instrument based on a 17th-century harpsichord.The language in question is Faust, and this week we're joined by Romain Michon, who works on and teaches Faust, as we look at how it's designed, what kind of programmers it's for, and how it does the job of turning audio-pipeline definitions into executable code.And one of the surprising parts of that compilation strategy is the decision to have it compile to multiple targets, from the expected ones like C and Rust, to the exotic destination of FPGAs (Field Programmable Gate Arrays). FPGAs are like reprogrammable circuit boards, and Romain dives into Faust's attempts to go from a high-level description of an audio program, all the way down to instructions that tell a chip exactly how it should wire itself.So rather aptly for a technology podcast, we start this week with what your ear can hear and go all the way down to logic gates and circuit boards…–Try Faust in the Browser: https://faustide.grame.fr/Faust Online Course: https://www.kadenze.com/courses/real-time-audio-signal-processing-in-faust/infoFPGAs: https://en.wikipedia.org/wiki/Field-programmable_gate_arrayVHDL: https://en.wikipedia.org/wiki/VHDLVerilog: https://en.wikipedia.org/wiki/VerilogGrame: https://www.grame.fr/The (Strawberry Jam) Gramophone: https://www.grame.fr/articles/gramophoneGramophone Workshops: https://www.grame.fr/evenements/atelier-gramophones-65ca16b19fec4Support Developer Voices on Patreon: https://patreon.com/DeveloperVoicesSupport Developer Voices on YouTube: https://www.youtube.com/@developervoices/joinKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins

James Morse: Software Engineer at CiscoSystem Administrator to DevOpsDifference between DevOps and MLOpsGetting Started with DevOpsLuke Marsden: CEO of Helix MLHow to start a business at 15 years oldBTRFS vs ZFSMLOps: the intersection of software, DevOps and AIFine-tuning AI on the CloudSome advice for folks interested in ML OpsYuval Fernbach: CTO MLOps & JFrogStarting QuarkGoing from a jupyter notebook to productionML Supply ChainGetting started in Machine LearningStephen Chin: VP of DevRel at Neo4JDeveloper Relations: The JobWhat is a Large Language Model?Knowledge graphs and the Linkage ModelHow to Use Graph databases in EnterpriseHow to get into ML Ops ★ Support this podcast on Patreon ★

Fuzzing network traffic in OpenWRT, parsing problems lead to GitLab auth bypass, more fuzzing finds vulns in a JPEG parser, and more! Show Notes: https://securityweekly.com/asw-300

AI is revolutionizing the way I work as a solopreneur. So why not share exactly how I use it?You'll hear how I use AI tools for everything from coding to marketing, and how they've become my secret weapon for punching above my weight. I also get into the nitty-gritty of the challenges and limitations of AI, and how I navigate them. If you're curious about how AI can supercharge your solo business, this episode's got you covered.And stick around for my thoughts on the future of AI in software development - I think you'll find it pretty exciting!This episode is sponsored by Podscan.fmThe blog post: https://thebootstrappedfounder.com/the-ai-powered-solopreneur/The podcast episode: https://tbf.fm/episodes/347-the-ai-powered-solopreneurCheck out Podscan to get alerts when you're mentioned on podcasts: https://podscan.fmSend me a voicemail on Podline: https://podline.fm/arvidYou'll find my weekly article on my blog: https://thebootstrappedfounder.comPodcast: https://thebootstrappedfounder.com/podcastNewsletter: https://thebootstrappedfounder.com/newsletterMy book Zero to Sold: https://zerotosold.com/My book The Embedded Entrepreneur: https://embeddedentrepreneur.com/My course Find Your Following: https://findyourfollowing.comHere are a few tools I use. Using my affiliate links will support my work at no additional cost to you.- Notion (which I use to organize, write, coordinate, and archive my podcast + newsletter): https://affiliate.notion.so/465mv1536drx- Riverside.fm (that's what I recorded this episode with): https://riverside.fm/?via=arvid- TweetHunter (for speedy scheduling and writing Tweets): http://tweethunter.io/?via=arvid- HypeFury (for massive Twitter analytics and scheduling): https://hypefury.com/?via=arvid60- AudioPen (for taking voice notes and getting amazing summaries): https://audiopen.ai/?aff=PXErZ- Descript (for word-based video editing, subtitles, and clips): https://www.descript.com/?lmref=3cf39Q- ConvertKit (for email lists, newsletters, even finding sponsors): https://convertkit.com?lmref=bN9CZw

Sr. Software Engineer Kat Morgan has been in the IaC and software space for a long time and she has opinions! Join us as we talk about the shifting landscape of Infrastructure as Code (IaC), AI, Programming Languages (cough cough Python) and how Orchestration is changing! 00:00 - Intro 03:20 - Kat's mad libs idea

175: Resume WritingIntro topic:  DSLR Photography vs Camera PhoneNews/Links:Free Internet while flying by abusing edits to your profile namehttps://robertheaton.com/pyskywifi/Making Animated Characters with AI Arthttps://www.youtube.com/watch?v=zSN76gb_Z28On 10x Engineershttps://stackoverflow.blog/2024/06/19/the-real-10x-developer-makes-their-whole-team-better/The Beauty and Challenges of AI-Generated Artistic Gymnasticshttps://www.youtube.com/watch?v=YwJIYj3hPAUBook of the ShowPatrick: The Three Body Problem by Cixin Liuhttps://amzn.to/3xNEoRBJason: The Checklist Manifestohttps://amzn.to/3W2JjpMPatreon Plug https://www.patreon.com/programmingthrowdown?ty=hTool of the ShowPatrick: Super Mario Bros. Wonder (Nintendo Switch)https://amzn.to/3S9VJLfJason: Amazon Qhttps://marketplace.visualstudio.com/items?itemName=AmazonWebServices.amazon-q-vscodeTopic: Resume Writing (Courtesy of Matthew C.)Why have a resume?Many jobs require it to get into the considerationToday many are screened for keywords automaticallyLog for future youWhat is a resume?One-page descriptionKey accomplishments & experiencesComparison to CVReferencesHow to write a good resume?Do'sInclude your github if it has good contributionsBe specific (dates, locations, skills)Isolate your specific contributionsBe accurate/honestBe conciseBe ready to discuss any point you have on the resumeList hobbies/activities/extracurricularsDon'tsHave mistakes (especially dates)Use images (most companies use text extraction)Use it as a design portfolioPut social qualities (e.gs. hard-working, motivated, friendly)Use fancy templates/toolsResourcesManager Tools: How to scan resumes https://www.manager-tools.com/2016/05/how-scan-resume-part-1 Google docsLatex/Lyx for CVsHow to think about your career and how it impacts your future resume writing (career planning)Technologies and architectures more than specifics of project detailsHow various choices may age over time ★ Support this podcast on Patreon ★

Discerning and Defining a product manager Role is S.10 E.2 n.142 of the FSG Messaging and Optics Podcast, Wait What Really OK hosted by Messaging and Optics Strategist Loren Weisman. Derrick is the guest on this episode of Wait What Really OK. Together Loren and Derrick dig in to the ins, outs, ups and downs of Product Managers. In this episode, Derrick helps with the discerning and defining when it comes to an effective product manager as well as some red flags to watch out for and many of the attributes to look for. This podcast is raw, real and true. Done in one take, a little EQ and up… Proud of the flubs, the ums and the uhs. This was unscripted and in the moment.  Derrick did not have the questions in advance. Derrick Boudwin is a Qualified Director of Product Engineering with over 15 years experience leading international cross-functional teams, using people-centric strategies to develop software resulting in successful, patented, and disruptive products. Derrick is also versed in the Programming Languages of Python, Bash, Visual Basic, Powershell, SQL, Ruby, Java as well as being familiar with Tools and Technologies that include AWS, GCP, Azure, Tensorflow, Docker, Ansible, Terraform, Jenkins, CircleCI, Git, OpenCV, Pivotal, Jira, and ConfluenceTo talk to Derrick about any or all things Product Manager related or to get some help in your product manager search or assistance in interviewing or reviewing your candidates, email: Derrick@DerrickBoudwin.com *Loren Weisman is a Messaging and Optics Strategist. starting as a session/ghost drummer and then music producer, loren has 700 album credits across major and indie labels as drummer and producer. He then shifted to TV production with credits for ABC, NBC, FOX, CBS, TLC and more including reality shows, infomercials, movies and documentaries. Loren wrote three internationally published and distributed books, including Wiley and Sons, “Music Business for Dummies”, as well as GreenLeaf's “The Artists Guide to Success in the Music Business.” https:/lorenweisman.com/ * © 2024 Loren Weisman / Fish Stewarding Group All Rights Reserved ® ℗ *

Cooper Scanlon, Co-founder of Movement Labs, dropped out of Vanderbilt after his journey led to the blockchain space and he realized that formal education wasn't the key to his success and he enjoyed building a SPACDAO Vehicle more. This decision led to him pioneering the first yield aggregator leveraging Move and eventually envisioning and creating Movement Labs.Fostering cross-disciplinary collaborations, championing Web3 initiatives, and drawing from his experiences, Cooper brings a unique blend of financial & technical expertise and economic system insights to Movement Labs, steering and leading its strategic and cultural direction.In this conversation, we discuss:- The Move programming language- Using web3 tech to create your own change- "Building The Parthenon"- Battle of Olympus Hackathon- Rewarding community engagement in web3- Launching testnet and securing $160M in Total Value Locked (TVL)- Raising $38M from Binance Labs- Writing cheques for new teams in the Move / Movement Labs ecosystem- Incubating a community from scratch- Living in NYC vs. SFMovement LabsWebsite: movementlabs.xyzX: @movementlabsxyzTelegram: t.me/movementlabsxyzCooper ScanlonX: @coopsmoves  ---------------------------------------------------------------------------------  This episode is brought to you by PrimeXBT.  PrimeXBT offers a robust trading system for both beginners and professional traders that demand highly reliable market data and performance. Traders of all experience levels can easily design and customize layouts and widgets to best fit their trading style. PrimeXBT is always offering innovative products and professional trading conditions to all customers.   PrimeXBT is running an exclusive promotion for listeners of the podcast. After making your first deposit, 50% of that first deposit will be credited to your account as a bonus that can be used as additional collateral to open positions.  Code: CRYPTONEWS50  This promotion is available for a month after activation. Click the link below:  PrimeXBT x CRYPTONEWS50

In today's episode, we bring Adam Argyle, a CSS Dev Rel at Google, content creator, co-host at CSS Podcast, Bad At CSS Podcast and host of GUI Challenges. He's also the creator of a bunch of tools and utilities for the front-end. We're going to touch on a lot of hot topics, regarding the difficulty and power of CSS, how programmers most of the time underestimate and dismiss it as something trivial when in reality it's one of the hardest things to master in the programming world. We also go over AI, the barriers between designers and developers and a bunch of other topics. Learn back-end development - https://www.boot.dev Listen on your favorite podcast player: https://www.backendbanter.fm Adam's Website: https://nerdy.dev/ Adam's X/Twitter: https://x.com/argyleink Adam on Chrome For Developers: https://chromeextensionsdocs.appspot.com/authors/argyle/ The CSS Podcast: https://thecsspodcast.libsyn.com/ Bad at CSS Podcast: https://badatcss.com/ Timestamps: 00:00 Intro 00:51 CSS Wizard has entered the chat 02:37 HTML and CSS are not programming languages 07:44 There's a case for complex things using CSS 10:28 CSS is declarative by nature 17:58 Writing CSS is a pain 20:43 AI isn't a threat to CSS 21:19 Breaking barriers between designers and developers 26:33 Getting to an entry-level competency on the backend is a bit more difficult when compared to the frontend 31:37 Adam's backstory 33:40 Knowing everything 34:56 The majority of the complexity lives on the frontend a lot of the times 38:48 South Park Reality 39:49 BFF vs BOF (Backend for frontend vs Backend of the Frontend) 47:03 CSS is typed in the browser 51:28 Take on why are there so many mormons and ex-mormons in the webdev and tech influencer scene? 54:08 Where to find Adam

A language's AST—it's abstract syntax tree—is nearly always a hidden implementation detail. It's not treated as part of the language, but merely the intermediate step between parsing and compiling. But this week's guest aims to flip that relationship on its head... Peter Saxton joins me to talk about EYG - an AST-first language that defines the fundamental capabilities first, and then stretches out from there to surface syntax and final execution. The result is something that can teach us a lot about how a typed, functional programming language works; how an extensible effects system works; and could make writing a new programming language as easy as defining the syntax you want, and parsing that into EYG's AST.--EYG Homepage: https://github.com/crowdhailer/eyg-langTinyGo: https://tinygo.org/Become a Supporter on Patreon: https://patreon.com/DeveloperVoicesBecome a Supporter on YouTube: https://www.youtube.com/@developervoices/joinKris on Mastodon: http://mastodon.social/@krisajenkinsKris on LinkedIn: https://www.linkedin.com/in/krisjenkins/Kris on Twitter: https://twitter.com/krisajenkins

Many devs dream of one day writing their own operating system. Ideally in their favorite language: Rust. For many of us, this dream remains just that: a dream.Jeremy Soller from System76, however, didn't just contribute kernel code for Pop!_OS, but also started his own operating system, RedoxOS, which is completely written in Rust. One might get the impression that he likes to tinker with low-level code!In this episode of Rust in Production, Jeremy talks about his journey. From getting hired as a kernel developer at Denver-based company System76 after looking at the job ad for 1 month and finally applying, to being the maintainer of not one but two operating systems, additional system tools, and the Rust-based Cosmic desktop. We'll talk about why it's hard to write correct C code even for exceptional developers like Jeremy and why Rust is so great for refactoring and sharing code across different levels of abstraction.

Wolf Vollprecht, the CEO and founder of Prefix.dev, speaks with host Gregory M. Kapfhammer about how to implement Python tools, such as package managers, in the Rust programming language. They discuss the challenges associated with building Python infrastructure tooling in Python and explore how using the Rust programming language addresses these concerns. They also explore the implementation details of Rust-based tooling for the Python ecosystem, focusing on the cross-platform Pixi package management tool, which enables developers to easily and efficiently install libraries and applications in a reproducible fashion. Brought to you by IEEE Computer Society and IEEE Software magazine.

Intro topic:  Social Media Auto Responder LLMNews/Links:Amazon releases Amazon Qhttps://press.aboutamazon.com/2024/4/aws-announces-general-availability-of-amazon-q-the-most-capable-generative-ai-powered-assistant-for-accelerating-software-development-and-leveraging-companies-internal-dataCheap RiscV “Super Cluster” from BitluniDIY 256-Core RISC-V super computerhttps://www.youtube.com/watch?v=-4d3PgEXhdYCH32V203Phi 3 Vision Releasedhttps://azure.microsoft.com/en-us/blog/new-models-added-to-the-phi-3-family-available-on-microsoft-azure/OllamaChatGPT 4ohttps://openai.com/index/hello-gpt-4o/Book of the ShowPatrick: MyFirstMillion Podcasthttps://www.mfmpod.com/Jason: A Path Towards Autonomous Machine Intelligencehttps://openreview.net/pdf?id=BZ5a1r-kVsfPatreon https://www.patreon.com/programmingthrowdown?ty=hTool of the ShowPatrick: Dave the Diverhttps://store.steampowered.com/app/1868140/DAVE_THE_DIVER/Jason: Turing Completehttps://store.steampowered.com/app/1444480/Turing_Complete/ Topic: DevOpsWhat is DevOpsDevOps vs SREWhy DevOps is importantEngineering time is expensiveOutages can hurt company metrics & reputationBuild & Testing InfrastructureBazel & Build/Test IdempotencyBuild/Test FarmsBuildBarnGithub ActionsJenkinsInfrastructure as codeTerraformBlue Green DeploymentContinuous Everything!Continuous IntegrationContinuous DeploymentHow to Measure DevOpsBuild TimesRelease cadenceBug tracking / round trip timesEngineer SurveysTime spent doing what you enjoyDevOps Horror Stories ★ Support this podcast on Patreon ★

In this episode of "Screaming in the Cloud," Corey Quinn is joined by Rachel Stephens, a Senior Analyst at RedMonk, for an engaging conversation about the profound impact of AI on software development. Rachel provides her expert insights on programming language trends and the shifts in the tech landscape driven by AI. They look into how AI has reshaped coding practices by automating mundane tasks and offering real-time assistance, altering how developers work. Furthermore, Corey and Rachel examine the economic and practical challenges of incorporating AI into business operations, aiming to strip away the hype and highlight AI technology's capabilities and constraints.Show Highlights: (00:00) - Introducing Rachel Stephens, Senior Analyst at RedMonk(00:28) - The Humorous Nemesis Backstory(03:42) - AI, focusing on its broad impact and current trends in technology(04:54) - Corey discusses practical applications of AI in his work(06:00) - Rachel discusses how AI tools have revolutionized her workflow(08:12) - RedMonk's approach to tracking language rankings(10:29) - Public vs. Internal Use of Programming Languages(13:09) - Rachel and Corey discuss how AI coding assistants are improving coding consistency and efficiency(15:55) - Corey challenges the purpose  of language rankings (20:51) - AI tools affecting traditional data sources like Stack Overflow (26:28) - The challenges of measuring productivity in the AI era(29:21) - The macroeconomic impacts on tech employment and the role of AI in workforce management(36:33) - Rachel and Corry share their personal uses and preferences for AI tools(39:25) - Closing Remarks and where to reach RachelAbout Rachel: Rachel Stephens is a Senior Analyst with RedMonk, a developer-focused industry analyst firm. She focuses on helping clients understand and contextualize technology adoption trends, particularly from the lens of the practitioner. Her research covers a broad range of developer and infrastructure products., Rachel Stephens is a Senior Analyst with RedMonk, a developer-focused industry analyst firm. She focuses on helping clients understand and contextualize technology adoption trends, particularly from the lens of the practitioner. Her research covers a broad range of developer and infrastructure products.Links Referenced: RedMonk: https://redmonk.com/Rachel Stephens LinkedIn: https://www.linkedin.com/in/rachelstephens/* Sponsor Prowler: https://prowler.com

173: Mocking and Unit TestsIntro topic:  HeadphonesNews/Links:Texas A&M University Physics Festivalhttps://physicsfestival.tamu.edu/Rust vs Cpp at GoogleLars Bergstrom (Google Director of Engineering): Rust teams at Google are as productive as the ones using Go and 2x those using Cpphttps://youtu.be/6mZRWFQRvmw?t=27012Is Cosine Similarity Really About Similarityhttps://arxiv.org/abs/2403.05440Xz utils supply chain attackAndres Freund at Microsofthttps://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world/Book of the ShowPatrick:80/20 Running by Matt Fitzgeraldhttps://amzn.to/3xyEKLoJason: A Movie Making Nerdhttps://amzn.to/49ycDJjPatreon Plug https://www.patreon.com/programmingthrowdown?ty=hTool of the ShowPatrick: Shapez Android: https://play.google.com/store/apps/details?id=com.playdigious.shapez&hl=en_US&gl=USShapez iOS: https://apps.apple.com/us/app/shapez-factory-game/id6450830779Jason: Dwarf Fortresshttps://store.steampowered.com/app/975370/Dwarf_Fortress/Topic: Mocking and Unit TestsWhat are Unit TestsBalance between utility, maintenance, and coverageUnit Test: testing small functionsRegression Test: Testing larger functionsSystem Test: End-to-end testing of programsWhat are mocks & fakesWhen to use mock vs. fakeMocking libraries in various languagesPython: https://docs.python.org/3/library/unittest.mock.htmlJava: https://github.com/mockito/mockitoC++:  https://github.com/google/googletest ★ Support this podcast on Patreon ★

Bio: nf (aka enneff aka Andrew) lives on the east coast of Australia.   As a programmer, he has built Open Source Software at Google Australia for the last 14 years. Originally part of the team that built the Go programming language (go.dev), he went on to co-create the Upspin storage system (upspin.io), and lead the team behind Open Source Insights (deps.dev).    As a musician he uploads clips to Instagram and sometimes produces dreamy IDM tunes. His new single 'Andromeda' is out now on streaming services. Summary: In this conversation, Andrew discusses his background as a programmer and his work on the programming language Go. He also talks about his involvement in securing supply chain issues and his role on the board of a wildlife hospital. The conversation then shifts to the topic of developing programming languages and the process involved. Andrew explains the evolution of programming languages from machine code to more abstract concepts and the role of compilers. The conversation also touches on the impact of AI on programming and the limitations of language models in writing code. The discussion concludes with a conversation about the ethical implications of using data to train AI models. The conversation explores the power requirements and environmental costs of compute farms, the potential for AI-generated music, the role of AI in the creative process, the importance of the artist in music, the ethical considerations of using AI-generated content, the impact of technology on society and capitalism, and the potential pitfalls of AI. enneff links Mr. Bill's Links Chapters: 00:00 Introduction and Background 05:23 The Development of Programming Languages 25:43 Ethical Implications of Using Data to Train AI Models 31:19 The Power Requirements and Environmental Costs of Compute Farms 32:45 Exploring the Potential of AI-Generated Music 38:22 The Role of the Artist in Music Creation 43:59 Ethical Considerations of AI-Generated Content 49:48 The Impact of Technology on Society and Capitalism 53:19 The Pitfalls of AI and the Need for Human Connection

172: Transformers and Large Language ModelsIntro topic: Is WFH actually WFC?News/Links:Falsehoods Junior Developers Believe about Becoming Seniorhttps://vadimkravcenko.com/shorts/falsehoods-junior-developers-believe-about-becoming-senior/Pure PursuitTutorial with python code: https://wiki.purduesigbots.com/software/control-algorithms/basic-pure-pursuit Video example: https://www.youtube.com/watch?v=qYR7mmcwT2w PID without a PHDhttps://www.wescottdesign.com/articles/pid/pidWithoutAPhd.pdfGoogle releases Gemmahttps://blog.google/technology/developers/gemma-open-models/Book of the ShowPatrick: The Eye of the World by Robert Jordan (Wheel of Time)https://amzn.to/3uEhg6vJason: How to Make a Video Game All By Yourselfhttps://amzn.to/3UZtP7bPatreon Plug https://www.patreon.com/programmingthrowdown?ty=hTool of the ShowPatrick: Stadia Controller Wifi to Bluetooth Unlockhttps://stadia.google.com/controller/index_en_US.htmlJason: FUSE and SSHFShttps://www.digitalocean.com/community/tutorials/how-to-use-sshfs-to-mount-remote-file-systems-over-sshTopic: Transformers and Large Language ModelsHow neural networks store informationLatent variablesTransformersEncoders & DecodersAttention LayersHistoryRNNVanishing Gradient ProblemLSTMShort term (gradient explodes), Long term (gradient vanishes)Differentiable algebraKey-Query-ValueSelf AttentionSelf-Supervised Learning & Forward ModelsHuman FeedbackReinforcement Learning from Human FeedbackDirect Policy Optimization (Pairwise Ranking) ★ Support this podcast on Patreon ★

Leo Treadwell, a visionary who has developed an organic intelligence language model, shares his story, his insights, and his tips on how to use AI and programming language to heal yourself and the world. Treadwell is the founder of the Organic Intelligence Language Model, a system that uses artificial intelligence and natural language to understand and reprogram the human mind. He describes how used this system to heal himself from a life-threatening illness and to create a successful business and a happy family. In this episode, we cover topics such as: • How the human mind works like a computer program, with pre-cognitive commitments and emotional responses encoded in syntax. • How to use numbers for creativity and problem-solving, by focusing on what you want to create or solve, asking the right questions, making agreements, and taking action. • How to be aware of the manipulation of thoughts and beliefs, and how to reclaim your sovereignty and freedom. • How to use language to program your thoughts and emotions, and how to rewrite your life story using human nature and computer language. • How to act on climate change and other global issues, by bypassing the limbic system and operating from choice, pleasure, and potential. • How to balance your masculine and feminine energies in the digital age, and how to connect with the natural law and values that govern the universe. • How to discover the hidden connections and patterns that exist in nature, mathematics, and philosophy, and how they relate to your perception and reality. If you want to learn more about Leo Treadwell and his organic intelligence language model, visit his website or follow him on social media.